Как распределяются партиции топика Kafka между консьюмерами в группе, если консьюмеров меньше чем партиций

Что проверяют

Знает ли кандидат, что партиция это единица параллелизма и внутри группы она отдаётся ровно одному консьюмеру. Дальше проверяют понимание ребаланса и того, где на самом деле упирается пропускная способность.

Как отвечать

Внутри одной группы партиция назначается ровно одному консьюмеру. Обратное неверно: один консьюмер спокойно держит несколько партиций.

Ситуация из вопроса штатная: при 6 партициях и 2 консьюмерах каждый получит по 3. Ничего не теряется и не простаивает, просто параллелизм ограничен числом процессов, и если один не успевает, растёт лаг по его партициям.

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

Кто раскладывает: координатор группы на брокере запускает ребаланс, а конкретное распределение считает assignor на стороне клиента.

• RangeAssignor режет партиции диапазонами по каждому топику отдельно, из-за чего при нескольких топиках перекашивает нагрузку на первых консьюмеров;
• RoundRobinAssignor раскладывает по кругу и распределяет ровнее;
• StickyAssignor и CooperativeStickyAssignor стараются сохранить прежние назначения при ребалансе, кооперативный делает это инкрементально, не останавливая чтение всей группы.

Ребаланс запускают: вход или выход консьюмера, потеря хартбита по session.timeout.ms, превышение max.poll.interval.ms (обработка батча затянулась), изменение числа партиций. В старом eager-протоколе на время ребаланса вся группа перестаёт читать, отсюда требование не залипать в обработке между вызовами poll.

Что ещё стоит сказать:

• порядок гарантируется только внутри партиции. Сообщения с одним ключом попадают в одну партицию, значит порядок по ключу сохранён, но при изменении числа партиций раскладка ключей ломается;
• перекос ключей опаснее арифметики: если ключом стал id крупного клиента, его партиция становится горячей и тормозит группу независимо от того, сколько консьюмеров запущено;
• число партиций закладывают с запасом: увеличить можно, уменьшить нельзя;
• group.instance.id (static membership) избавляет от ребаланса при обычном рестарте пода;
• смотреть надо records-lag-max по партициям, а не суммарный лаг.

Где спотыкаются

Говорят, что при нехватке консьюмеров часть партиций остаётся непрочитанной, или наоборот, что несколько консьюмеров одной группы могут читать одну партицию параллельно. Ещё забывают про потолок: лишние инстансы сверх числа партиций просто простаивают.