Кафка должна число потребительских потоков равным количеству разделов темы - PullRequest
2 голосов
/ 01 ноября 2019

Представьте, что вы определили, что хотите использовать ровно 8 пользовательских потоков для своего приложения.

Будет ли какая-либо разница в обработке, если для темы Kafka будет настроено 8 разделов против 16 разделов?

В первом случае каждый поток назначается одному разделу с двумя данными, а во втором случае каждый поток назначается двум разделам с половиной данных в каждом. Мне кажется, что между этими двумя настройками нет никакой разницы.

1 Ответ

0 голосов
/ 01 ноября 2019

Я считаю, что на стороне потребителя может быть разница, если ваши потоки не ограничены процессором (а сеть не загружена). Предполагая бесконечные данные на брокере Kafka или отстающем потребителе, поскольку каждый поток потребляет два раздела во втором примере, брокер kafka может отправить больше данных, чем если бы каждому потоку был назначен только один раздел. Kafka имеет ограничение на максимальное количество байтов, которое может быть получено за выборку (replica.fetch.max.bytes в конфигурации), поэтому, если вы удвоите количество разделов, вы можете увеличить емкость, предполагая, что данные доступны.

КогдаПри правильной настройке и в идеальных условиях Kafka будет обслуживать данные из кэша страниц, поэтому он может передавать данные потребителям, и в 90% случаев узким местом будет количество разделов / доступный ЦП на стороне потребителя. В общем, чем больше у вас разделов, тем быстрее вы можете использовать Kafka до тех пор, пока вы не будете ограничены ЦП или пропускной способностью для потребителя, и в этот момент не будет иметь значения, если у вас будет больше или меньше разделов, так как вы потребляете данныетак или иначе, так быстро, как вы можете.

Еще одна вещь, которую следует принять во внимание, - это то, что может быть больше потребительских коммитов, отправляемых обратно брокерам, поскольку теперь существует больше разделов, что означает некоторые дополнительные издержки / перекрестные помехи вкластер. Вероятно, это не 2-кратные коммиты, но, вероятно, больше, чем 1-кратные коммиты из первого сценария.

Важно помнить, что, когда это возможно, выполнять фактическую обработку сообщений на вашем потребителе вне потока. . То есть не обрабатывает входящие сообщения в том же потоке, который использует / опрашивает Kafka. Сначала это может сработать, но вы начнете сталкиваться с проблемами, если ваша обработка занимает больше времени, есть задержка, огромное увеличение объема на входящей стороне и т. Д. Когда это возможно, выбрасывайте входящие сообщения в очередь и позволяйте другимПоток беспокоится об их обработке / разборе.

Наконец, вы не хотите доводить это до крайности и настраивать 1000 разделов, если вам не нужно. Каждый раздел требует накладных расходов на коммиты, znokeeper znodes, время перебалансировки потребителя, время запуска и т. Д. Итак, я бы посоветовал сравнить различные сценарии и посмотреть, что работает лучше для вас. В общем, в прошлом у меня хорошо работало что-то из 2-4 разделов на поток пользователя, даже при очень высокой загрузке сообщений (темы с 50K + сообщений в секунду, каждый ~ 1KB).

...