Возможно ли и рекомендуется ли наличие многопоточного Kafka Consumer для каждого раздела, если да, какой-либо образец фрагмента?

Мы используем версию Kafka 0.9, и большое количество сообщений отправляется в определенный раздел в теме kafka. И таких разделов в этой теме несколько. У нас есть один потребитель, назначенный на раздел в рамках этой темы, и мы поддерживаем смещение вручную в разделе темы во внешнем хранилище данных. Я хотел знать, если мы начнем получать действительно большое количество сообщений в разделе темы, возможно ли, чтобы потребитель имел дело с разделом темы, чтобы быть многопоточным. Потому что может оказаться невозможным, чтобы экземпляр потребителя, назначенный разделу, смог завершить обработку всех записей за желаемый промежуток времени. Возможен ли такой многопоточный потребитель с перегородкой? Это рекомендуется? Также, если ответ ДА, то как несколько потоков могут управлять смещением, потому что все эти потоки имеют дело с сообщениями в одном разделе. Доступен какой-нибудь образец фрагмента?

Обратите внимание: я спрашиваю о «потребителе, имеющем дело с одним разделом внутри темы», я не смотрю на группу потребителей для темы, разделенной на разделы в ней.


person sc so    schedule 20.01.2016    source источник
comment
почему не группа? Какой клиент вы используете?   -  person BAE    schedule 26.01.2016


Ответы (1)


Что вы можете сделать, так это иметь 1 поток, обрабатывающий потребление сообщений для этого раздела, и группу рабочих, обрабатывающих эти сообщения. Есть несколько проблем, с которыми вы сталкиваетесь с этим решением (например, процесс сообщений может быть не в порядке), а также сбои и повторные попытки, которые вам нужно обрабатывать отдельно, потому что фиксация смещения будет выполнена потребителем, когда (1) он передает сообщения рабочим или (2) рабочие должны будут уведомить потребителя, когда обработка завершена, чтобы потребитель мог сохранить список (упорядоченный по смещению asc), и смещение будет зафиксировано только тогда, когда его следующее смещение после последнее зафиксированное смещение (и удалено из списка). У этого решения есть обратная сторона: может быть несколько смещений, ожидающих фиксации, потому что есть медленный рабочий (или тяжелое сообщение), и если потребитель выйдет из строя в следующий раз, вы будете повторно обрабатывать сообщения (в любом случае для этого есть обходные пути).

Надеюсь, это поможет!

person Nautilus    schedule 27.01.2016