Может ли группа потребителей запомнить, на какие темы она подписана?

Я новичок в Kafka, и я пытаюсь создать функциональность подписки на несколько продуктов. Допустим, есть N производителей, называемых P1, P2, P3... и M, количество потребителей C1, C2, C3.

Теперь C1 нужно подписаться на P1, P2, а в какой-то момент ему также нужно подписаться на P3. Следовательно, C1 имеет динамический список тем, на которые ему необходимо подписаться.

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

Есть ли способ, при котором в kafka потребитель высокого уровня может помнить темы, на которые он подписан, и слушать их при появлении, вместо того, чтобы мы указывали имена всех тем, на которые он был подписан в прошлом.


apache-kafka kafka-consumer-api
person Vineeth Mohan    schedule 16.02.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Кроме того, динамическое изменение темы (и раздела) в потребительских клиентах не является тривиальной задачей. AFAIK Kafka не предназначен для такого использования.

Лучшим вариантом было бы использовать специальное поле сообщения, которое сообщало бы вашим клиентам-потребителям, предназначено ли сообщение для них или нет. Таким образом, вы можете использовать специальные темы для сообщений, которые не требуют такого динамического характера (чтобы избежать этой проверки для всех сообщений, если это возможно), и отдельную тему, в которой вы будете смешивать все сообщения, которые требуют этого.

person Marko Bonaci    schedule 16.02.2016