#apache-kafka
Вопрос:
У меня есть бизнес, в котором я хочу, чтобы тысячи производителей писали сообщения, которые будут потребляться тысячами соответствующих потребителей. Сообщение каждого производителя предназначено ровно для одного потребителя.
Рассмотрим основные концепции здесь и здесь: похоже, что у каждой пары потребитель-производитель должна быть своя тема. Правильно ли это понимание? Я также изучил группы потребителей, но, похоже, они больше подходят для распараллеливания потребления.
Прямо сейчас у меня есть несколько пар производитель-потребитель, разделяющих очень мало тем, но из-за этого (я думаю) мне приходится читать много сообщений в потребителе и отфильтровывать их для сообщений конкретного производителя по ключу. Поскольку моя система масштабируется, это может занять много времени. Кроме того, в случае, если мне придется удалить контрольную точку, это будет еще более проблематично, так как она начнет считываться с самого начала.
Является ли создание тысяч тем решением для этого? Или есть какой-либо другой способ использовать такие понятия, как разделы, группы потребителей и т.д.? Как производители, так и потребители являются потоковыми/пакетными приложениями spark. Спасибо.
Ответ №1:
Сообщение каждого производителя предназначено ровно для одного потребителя
Предполагая, что вы фиксируете смещения и не допускаете повторных попыток, это ожидаемое поведение всех потребителей Кафки (или, скорее, групп потребителей)
похоже, у каждой пары потребитель-производитель должна быть своя тема
Не совсем. Как вы сказали, у вас много-много отношений с клиентами. Вам не нужно заранее иметь известную пару; производитель может отправлять данные без ожидаемого потребителя, тогда любое приложение(приложения) потребителя в будущем должно иметь возможность подписаться на эту тему для интересующих их данных.
обмен очень немногими темами, но из-за этого (я думаю) мне приходится читать много сообщений у потребителя и фильтровать их по ключу для сообщений конкретного производителя. Поскольку моя система масштабируется, это может занять много времени
Потребление заняло бы линейно больше времени при более высокой производительности, да, и разделение-это способ решения этой проблемы. Кроме того, вам нужна более быстрая сеть и обработка. Вам все равно нужно потреблять и десериализовывать данные для фильтрации, так что фильтр здесь не является узким местом.
Является ли создание тысяч тем решением для этого?
В конечном счете это зависит от ваших данных, но я предполагаю, что нет.
Комментарии:
1. «Потребление заняло бы линейно больше времени при более высокой производительности» — проблема в том, что если у меня есть 1000 производителей, пишущих на одну и ту же тему, то одному потребителю нужно прочитать всю тему (за последние 7 дней), а затем отфильтровать ее до конкретных сообщений. так что это делает фильтрацию узким местом, не так ли? ( Если есть контрольная точка (потоковая передача spark), я понимаю, что она будет считываться только с этого смещения, но если будет представлен новый потребитель, он должен начинаться с начала темы)
2. Количество производителей не имеет значения; важно, с какой скоростью они производят. И неясно, как это является узким местом, если фильтру не нужно использовать внешний длительный процесс, поскольку проверки/условия равенства будут O(1) постоянным временем, а потребление только O(n) линейное время.