Очереди в Кафке
В 2025 году в Kafka начиная с версии 4.0 появился новый тип групп — share groups, которые обеспечивают работу с сообщениями как в очередях, а не в виде лога (как это обычно в Kafka).
Сообщения в Kafka логически распределены по топикам (например, orders, checks). Топик разбиты на партиции. Именно партиция является физической группировкой сообщений. Про топики, партиции, продюсеров и консьюмер группы у меня есть серия постов.
Consumer groups и привычные паттерны работы остались, просто появилась альтернатива в виде share groups.
Основные различия между share group и consumer group:
➡️ Совместное чтение из одной партиции
Внутри consumer группы одну партицию может читать только один консьюмер.
В share group консьюмеры совместно читают из партиций, то есть одна партиция может быть назначена нескольким консьюмерам одновременно. Kafka сама динамически распределяет доступные сообщения из партиций между консьюмерами так, чтобы балансировать нагрузку.
➡️ Количество консьюмеров в share group может превышать количество партиций в топике.
В случае с consumer groups, если мы хотим сильнее масштабироваться, нужно увеличить количество партиций. Если для топика с 3 партициями мы поднимем 4 консьюмера, то 4-й будет простаивать (пока кто-то из 3-х не отвалится). Поэтому число партиций определяет максимальный параллелизм, с которым мы можем обрабатывать сообщения. Но уменьшить их потом нельзя, плюс топик может быть другой команды.
В случае с share group мы можем поднять много консьюмеров, чтобы обработать нагрузку в пике.
➡️ Порядок сообщений не сохраняется
В партиции сообщения лежат по порядку. Но поскольку из одной и той же партиции в share группе могут читать два и более консьюмера, они могут обработать сообщения не по порядку.
Продолжение ⬇️
В 2025 году в Kafka начиная с версии 4.0 появился новый тип групп — share groups, которые обеспечивают работу с сообщениями как в очередях, а не в виде лога (как это обычно в Kafka).
Совсем кратко: в share groups несколько консьюмеров читают одну партицию, поэтому не сохраняется порядок доставки, зато удобно масштабировать.
Сообщения в Kafka логически распределены по топикам (например, orders, checks). Топик разбиты на партиции. Именно партиция является физической группировкой сообщений. Про топики, партиции, продюсеров и консьюмер группы у меня есть серия постов.
Consumer groups и привычные паттерны работы остались, просто появилась альтернатива в виде share groups.
Основные различия между share group и consumer group:
➡️ Совместное чтение из одной партиции
Внутри consumer группы одну партицию может читать только один консьюмер.
В share group консьюмеры совместно читают из партиций, то есть одна партиция может быть назначена нескольким консьюмерам одновременно. Kafka сама динамически распределяет доступные сообщения из партиций между консьюмерами так, чтобы балансировать нагрузку.
➡️ Количество консьюмеров в share group может превышать количество партиций в топике.
В случае с consumer groups, если мы хотим сильнее масштабироваться, нужно увеличить количество партиций. Если для топика с 3 партициями мы поднимем 4 консьюмера, то 4-й будет простаивать (пока кто-то из 3-х не отвалится). Поэтому число партиций определяет максимальный параллелизм, с которым мы можем обрабатывать сообщения. Но уменьшить их потом нельзя, плюс топик может быть другой команды.
В случае с share group мы можем поднять много консьюмеров, чтобы обработать нагрузку в пике.
➡️ Порядок сообщений не сохраняется
В партиции сообщения лежат по порядку. Но поскольку из одной и той же партиции в share группе могут читать два и более консьюмера, они могут обработать сообщения не по порядку.
Пример:
Два консьюмера в share group читают топик с одной партицией. Первый консьюмер получает записи с offset 100 по 109 включительно и падает. В это же время второй консьюмер получает, обрабатывает и подтверждает записи 110–119. Затем второй консьюмер получает необработанные первым записи 100–109, обрабатывает и подтверждает. Все сообщения обработаны, но порядок обработки не сохранен.
Продолжение ⬇️