Кейс: два сервиса читали одну партицию Kafka, потому что group.id совпал

Два независимых сервиса скопировали конфиг consumer'а из одного онбординг-шаблона. group.id остался тем же — просто никто не поменял строку после копипаста.

Kafka не проверяет, из какого деплоя пришёл consumer. group.id — это идентификатор группы across всего кластера, а не namespace конкретного сервиса. Оба consumer'а присоединились к одной группе, и партиции разделились между ними по обычному протоколу ребалансировки.

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

Map props = Map.of( ConsumerConfig.GROUP_ID_CONFIG, "notifications" );

Нашли через kafka-consumer-groups --describe: у одной группы оказалось два разных client.id от двух разных приложений. Спросят, как Kafka распределяет партиции между consumer'ами одной группы и почему увеличение числа consumer'ов сверх числа партиций ничего не ускоряет.

group.id — это глобальный идентификатор в масштабе кластера, а не деталь конфигурации одного сервиса. Совпадение — это баг, не совпадение.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки