Ребалансировка группы

Соберём механику в одну цепочку. У каждой группы консьюмеров есть координатор — брокер, который ведёт членство: кто в группе, кто жив, кто как подписан. Ребаланс стартует, когда координатор видит изменение состава: новый член прислал JoinGroup, старый умер по таймауту сессии, член вышел, изменилась подписка или число партиций топика. Дальше координатор собирает всех живых членов, назначает одного лидером группы — не лидером партиции, а лидером именно группы, — и тот распределяет партиции между членами по выбранной стратегии. Результат фиксируется новой генерацией группы: номер поколения растёт на каждом ребалансе, и все участники знают, что внутреннее состояние прошлого поколения устарело. Номер поколения — не счётчик для красоты: он едет в каждом коммите оффсетов, и брокер отклоняет коммит от устаревшего поколения с ошибкой IllegalGeneration — «призрак» прошлой раздачи может ещё успеть прочитать пару сообщений, но подтвердить их новый владелец партиции уже не позволит. Отсюда свойства, которые важно прочувствовать: ребаланс — событие всей группы, а не одной партиции; партиции, которые не переезжают, всё равно проходят через новую генерацию; и на время раздачи чтение приостанавливается. Триггеры делятся на плановые — деплой и скейлинг — и внеплановые: падение пода, сетевые разрывы, таймауты. Плановые лечатся архитектурой процесса, внеплановые — таймерами группы, до которых дойдёт очередь.

kafka-go предлагает три стратегии, и переговоры между членами идут по имени протокола, а не по типу Go-структуры. RangeGroupBalancer представляется именем «range», RoundRobinGroupBalancer — «roundrobin»; третий вариант, RackAffinityGroupBalancer, требует настройки rack и решает отдельную задачу привязки читателей к стойкам. Раздача у простых двух разная. Range режет непрерывные диапазоны: шесть партиций на трёх членов дают первому партиции ноль и один, второму два и три, третьему четыре и пять. RoundRobin крутит по кругу: на той же шестёрке и тройке первый член получает ноль и три, второй — один и четыре, третий — два и пять. Разница проявляется на мультитопиковых группах и на неравномерных потоках: range сохраняет диапазоны, roundrobin перемешивает. Выбор делается переговорами: leader группы берёт первую стратегию из списка, которую поддерживают все члены, — поэтому приоритетный порядок в GroupBalancers значим, а разнородные клиенты в одной группе могут незаметно откатить вас на общий знаменатель. Практический совет: для однотопиковой группы выбор почти не важен, для мультитопиковой — тестируйте обе стратегии на своих числах, а не на чужих скриншотах.

Жизнью группы управляют три таймера, и путать их — классическая ошибка. HeartbeatInterval задаёт частоту пульсов: член группы по умолчанию рапортует координатору каждые три секунды, что жив. SessionTimeout — срок, после которого тишина без пульсов считается смертью: тридцать секунд по умолчанию; если пульсов нет дольше, координатор выкидывает члена и стартует ребаланс. RebalanceTimeout — другое измерение: сколько координатор готов ждать перерегистрации живых членов на уже начавшемся ребалансе, тоже тридцать секунд по умолчанию; медленный консьюмер, который не успел вернуться за срок, вылетает из новой генерации. Есть и четвёртая ручка, JoinGroupBackoff: пауза в пять секунд перед повторной попыткой входа после неудачи — она спасает от шторма присоединений при кратковременном сбое брокера. Настройка — баланс: короткие таймеры быстрее замечают смерть и быстрее пересобираются, но чаще выкидывают живых членов, у которых была пауза в сборке мусора или в сети. Дефолты разумны для сервисных потоков; менять их стоит по измеренному времени обработки и профилю пауз, а не потому, что тридцать секунд звучит долго.

У ребаланса в kafka-go нет колбэка — в отличие от Java-клиента с его rebalance listeners, ваш код не получает вызов «партиции забрали» или «партиции выдали». Это осознанная простота: во время перетасовки ReadMessage просто ждёт дольше обычного, а после неё продолжает с новым набором партиций. Что остаётся программисту: Logger reader'а, счётчик Rebalances в Stats и мониторинг лага — они дают полную картину постфактум. Подвисания на ребалансе распознаются по почерку: чтение стоит у всех членов группы разом — ребаланс; стоит у одного и лаг растёт по его партициям — завис член группы, и скоро его выкинет по SessionTimeout. Практика длинных обработок: пульсы идут в фоне внутри reader, поэтому долгая обработка одного сообщения сама по себе пульсы не глушит; риск в другом — если обработка переживает начавшийся ребаланс, партиция может переехать до коммита, и работа повторится у нового владельца. О будущем: sticky-стратегия, уменьшающая переезды, есть в протоколе и в других клиентах, но в kafka-go v0.4.49 её нет — следите за changelog, а не пишите свою.

Полностью убрать ребалансы нельзя — можно сделать их редкими, короткими и нестрашными. Редкими: стабильный размер группы, деплои по расписанию, не меняющие состав чаще необходимого, и никаких рестартов по крону без причины. Короткими: здоровые члены, которые быстро перерегистрируются, — таймеры по умолчанию рассчитаны на обычное приложение, и если ваш обработчик тратит полминуты на вход, проблема не в таймере. Нестрашными: дедупликация на потребителе, коммиты по дисциплине из восьмого урока и идемпотентные обработчики — тогда переезд партиции стоит вам переобработки хвоста, а не инцидента. Отдельно про скейлинг: добавление члена в группу с шестью партициями и шестью членами ничего не ускорит — седьмой простаивает; масштабируйте вместе с числом партиций, о чём пятый урок говорил со стороны ключей. И последнее: kafka rebalance — это не только клиентская история, у брокера есть свои пороги и лимиты группы; но в рамках go-кода вы управляете списком стратегий, таймерами и дисциплиной коммитов — этого достаточно, чтобы жить в ладу с перетасовками.