Прослушивание нескольких тем на одного потребителя

Question

Я недавно начал работать над Apache Кафкой. Одна вещь, которую я постоянно наблюдаю в разных блогах, это то, что несколько тем настроены для одного и того же слушателя.

Мой вопрос: это хорошая практика? Допустим, мы получаем 100 сообщений как таковых c по каждой теме c. Сообщение от каждого topi c требует различной настройки. И сообщение от. Отдельные темы попали в соответствующие таблицы. Пример: сообщение из theme1 отправляется в topic_1 таблицу.

Это приложение Spring Boot, над которым я работаю. Также я хотел бы знать, с какими еще проблемами я могу столкнуться в будущем.

Обновление: пример кода

@KafkaListener(topics = "#{'${kafka-consumer.topics}'.split(',')}", groupId = "${kafka-consumer.groupId}")
    public void consume(KafkaConsumer<String, String> record) {
        int count = 0;
        ConsumerRecords<String, String> records = record.poll(1000);
        for (ConsumerRecord<String, String> data : records) {
            System.out.println(data.value());
            count++;
        }
        //record.listTopics()
        if(count > 0){
            record.commitAsync();
        }

    }

Answer 1

Мой вопрос такой: это хорошая практика?

Это зависит от варианта использования. В вашем примере, где topi c соотносится с таблицей, у вас, вероятно, должен быть потребитель на topi c, потому что если ваш потребитель потребляет много разных тем, то потребление замедлится. Потребление менее эффективно, чем производство, поэтому наиболее распространенным вариантом использования является разделение вашей топии c на несколько разделов и получение нескольких потребителей на каждую топи c.

Было бы целесообразно использовать несколько тем, если они были связаны между собой. В одном случае использования Confluent написал официальный документ о том, где они реплицируют данные между центрами обработки данных, а темам предшествует идентификатор центра обработки данных. Потребители затем используют все темы с совпадающими именами, но с разными идентификаторами центров обработки данных.

Answer 2

это не хорошая практика! потому что это резко снижает уровень потребления по понятным причинам ...

, но в некоторых случаях вам придется использовать его, если у вас есть много производителей, которые могут динамически порождать, и вы хотите сохранить потребление данных от каждого из них, и в то же время имеют возможность отправлять данные на указанное c устройство

например

множество датчиков, каждый из которых отправляет на свой собственный топи c с таким идентификатором, как outgoing/12445646 и таким

, потребитель данных со всех этих датчиков будет прослушивать outgoing/* topi c, но все равно сможет отправлять сообщение непосредственно этому датчику на канале, например incoming/12445646

отдельный исходящий канал может быть очень полезен в случае управления трафиком c, когда можно порождать выделенных потребителей для каналов с высокой пропускной способностью и аналогичных сценариев ios или иметь дело со спецификацией c устройство без воздействия на остальные