Кафка - лучшие практики в случае медленной обработки потребителем. Как добиться большего параллелизма? - PullRequest
Новая
       15

Кафка - лучшие практики в случае медленной обработки потребителем. Как добиться большего параллелизма?

1 голос
/ 06 июня 2019

Мне известно, что максимальное количество активных потребителей в группе потребителей - это количество разделов темы.

Какова наилучшая практика в случае потребителей с медленной обработкой?Как добиться большего параллелизма?

Пример: тема с 6 разделами и тысячами сообщений в секунду, создаваемая продюсерами.У меня в группе не более 6 потребителей.Учтите, что обработка этих сообщений сложна, и потребители намного медленнее, чем производители.В результате потребители всегда отстают от последнего смещения, и отставание увеличивается.

В традиционной системе MQ мы просто добавляем все больше и больше потребителей, чтобы оставаться в курсе.

Какдостичь этого с Kafka, так как общее количество потребителей в группе не превышает количество разделов?Должен ли я:

  • Настроить тему так, чтобы в ней было больше разделов, позволяющих увеличить число потребителей на группу?
  • Направить сообщение от потребителя в традиционную очередь MQ (но потерять порядок)?

Какая практика лучше всего подходит для этой ситуации?

1 Ответ

2 голосов
/ 06 июня 2019

В Кафке разделы являются единицей параллелизма.

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

Во-первых, вы должны подумать о том, чтобы иметь больше разделов. 6 разделов относительно малы, вы можете легко иметь 60, 120 или даже больше разделов (и соответствующее количество потребителей). Внезапно объем работы каждого потребителя значительно сокращается.

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

Я не уверен, как маршрутизация сообщений через MQ Queue действительно помогла бы в этом сценарии. Если вы по-прежнему читаете медленнее, чем записываете, объем данных в очереди будет расти, пока у вас не останется свободного места на диске.

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

...