Динамическое и статическое членство потребителей Apache Kafka

ребалансировка потребителей Apache Kafka, группы потребителей Kafka, Kafka примеры курсы обучение, Школа Больших Данных Учебный Центр Коммерсант

Чем group.instance.id отличается от group.id, зачем нужен member.id, каковы преимущества статического членства в группе потребителей перед динамическим и какие механизмы Kafka обеспечивают ребалансировку клиентских приложений.

Еще раз про группы потребителей Apache Kafka

Напомним, группы потребителей в Apache Kafka нужны для логического объединения нескольких потребителей с целью повышения надежности потоковой системы. В один момент времени только один потребитель из всей группы с одинаковым group.id фактически получает данные раздела топика Kafka. Это обеспечивает отказоустойчивость потоковой системы. Например, если возникнет сбой на активном потребителе, и он перестанет отправлять координатору группы heartbeat-сигнал, произойдет перебалансировка потребителей и активным станет другой. При этом вся потоковая система из приложений-продюсеров, Kafka и приложений-потребителей продолжит работать. Чтобы избежать дублирования данных, т.е. не получать все сообщения с самого начала, конфигурацию потребителя auto.offset.reset следует установить в значение latest вместо earliest. Подробнее об этом мы писали здесь и здесь.

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

  • когда к группе присоединяется новый потребитель, брокер узнает об этом;
  • далее брокер меняет состояние группы потребителей с RUNNING на PREPARE_REBALANCE;
  • как только группа потребителей отреагирует на изменение состояния подготовки к ребалансировке, брокер меняет состояние на COMPLETING_REBALANCE;
  • после выполнения ребансировки состояние снова восстанавливается до RUNNING.

Чтобы выполнить этот процесс брокер отслеживает параметр member.id, который обеспечивает уникальную идентификацию каждого члена группы потребителей.

Ребалансировка потребителей Kafka
Ребалансировка потребителей Kafka

При динамическом членстве в момент ребалансировки, когда новый потребитель отправляет запрос на присоединение к группе со специальным пока неизвестным идентификатором UNKNOWN_MEMBER_ID. Благодаря этому брокер идентифицирует потребителя как нового члена группы и генерирует для него новый идентификатор члена группы.

Во время перезапуска клиента это происходит для всех членов группы, т.к. при отправке запроса на присоединение к группе включается UNKNOWN_MEMBER_ID. Значение member.id не сохраняется, и запускается ребалансировка, поскольку брокер идентифицирует всех потребителей как новых. Таким образом, member.id управляется брокером Kafka, тогда как group.instance.id настраивается на стороне приложения-потребителя.

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

Потребитель со статическим членством — это потребитель с настроенным group.instance.id в дополнение к его member.id, управляемому брокером. Параметр group.instance.id сохраняет уникальность потребителя при перебалансировке. Поэтому даже при перезагрузке потребителя из группы со статическим членством брокер узнает его по значению group.instance.id и не будет назначать новое членство. Это позволяет избежать повторной ребалансировки и отставания скорости потребления от скорости публикации.

Хотя процесс перебалансировки занимает немного времени (от нескольких секунд до минуты), все потребители на этот период приостанавливают обработку данных. Но приложения-продюсеры продолжают отправлять данные в топик Kafka. В результате этого момент обработки события потребителем отстает от момента, когда это событие произошло в реальном мире на стороне продюсера. Продолжительность ребалансировки зависит от количества разделов, т.к. каждый потребитель, должен отозвать, а затем восстановить связь с координатором для назначения разделов. Чем больше разделов, тем больше времени на это понадобится.

Таким образом, статическое членство потребителей значительно ускоряет последовательные обновления и делает тяжеловесные stateful-приложения более эффективными. Поскольку идентификаторы потребителей в группе сохраняется в group.instance.id, им не нужно выполнять повторную балансировку при удалении и повторном присоединении. А единственная задержка ребалансировки будет связана с перезапуском узла.

Для реализации статического членства в группе потребителей, надо задать значение group.instance.id в конфигурации приложения-потребителя.

В заключение отметим, что group.instance.id отличается от group.id. Параметр group.id является идентификатором группы и определяет, к какой группе принадлежит потребитель. А group.instance.id должен быть разным для каждого члена группы потребителей, поскольку он идентифицирует экземпляр потребителя как члена группы. Брокер Kafka сопоставляет group.instance.id с каждым member.id, чтобы обеспечить уникальную идентификацию каждого потребителя. В этом случае свойство member.id служит дополнительной проверкой для статического членства.

Узнайте больше про администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://www.confluent.io/blog/dynamic-vs-static-kafka-consumer-rebalancing/
  2. https://www.verica.io/blog/understanding-kafkas-consumer-group-rebalancing/

Поиск по сайту