Действительно, с августа 2025 Bitnami переместили все образы в bitnami legacy, где они больше не получают обновления. Статья будет обновлена. Спасибо за фидбек!
Если вы добавляете консьюмеров без групп на топик, то партиции не распределяются. Каждый консьюмер читает все сообщения. Если же с группами, то в рамках одной группы будет распределение партиций.
Теперь давайте рассмотрим ваш кейс с 3 партициями:
Если 1 консьюмер, то он читает все партиции.
Если 2 консьюмера, то один читает две партиции, другой — одну.
Если 3 консьюмера, то каждый читает по одной.
Ещё предлагаю для большего понимания рассмотреть случай, когда консьюмеров в группе больше, чем партиций. В этом случае "лишние" консьюмеры будут простаивать.
Если хотите, чтобы разными сервисами обрабатывались одни и те же сообщения, надо все инстансы в рамках одного сервиса засунуть в одну группу. Так надо сделать для каждого интересующего вас сервиса.
Вторая часть вопроса несколько более сложная. Попытаюсь адекватно объяснить:
Оффсеты напрямую не сопоставляются с консьюмерами. Видите ли, какая ситуация, в топике, ответственном за оффсеты, хранятся сообщения следующего вида:
Ключ — <group_id, topic, partition>
Значение — <commited_offset, metadata>
Это нам даёт возможности для перебалансировки, так как нет жётской связи между оффсетом и конкретным инстансом.
В вашем кейсе с упавшим единственным консьюмером будет примерно следующее:
Kafka переведёт группу в состояние перебалансировки.
Контроллер кластера смаппит сообщение из offser-топика на текущий активный консьюмер.
Как следствие, активный консьюмер начнёт читать с последнего закоммиченного оффсета. То есть никаких потерь не будет, так как мёртвый брокер не мог закоммитить оффсеты для новых сообщений. На всякий случай отмечу, что коммит в Kafka — это некий процесс сохранения оффсета консьюмером.
И в этом случае настройка latest применена не будет, так как кафка смаппит оффсет на консьюмера, а эта настройка срабатывает, как вы, надеюсь, помните, когда Kafka не находит оффсет для консьюмера.
Все будет хорошо. Консьюмеры в одной группе не знают о консьюмерах в другой. Чтение будет происходить независимо.
На конкретное сообщение, как мне известно, настроить нельзя. Можно только настроить на топик. О том, как конкретно настроить, используя Spring Boot, я рассказал в своей свежей практической статье. Рекомендую к прочтению :)
Мы создаём новую группу не для того, чтобы разгрузить первую. Мы это делаем для того, чтобы эта самая новая группа имела доступ к тем же самым сообщениям, но выполняла другую логику. То есть для независимого чтения одних и тех же данных. Для разгрузки мы увеличиваем количество консьюмеров в рамках одной группы. Тогда уже между ними распределяются партиции и каждый читает свою часть данных.
Согласен с вами. Действительно, слегка запнулся в начале. Поправил статью. Теперь в начале задаю правильный контекст (называю Kafka журналом). Но дальше провожу аналогии с сообщениями, чтобы безболезненно ввести читателя в курс дела.
Здесь интересен практический опыт и субьективное мнение конкретного человека
Буквально все примеры в этой статье взяты из моего недавнего пет-проекта. Ну, за исключением сервиса метрик. В проекте я его не делал. Если не верите, добро пожаловать на гитхаб. В профиле есть ссылка.
Её мы будем рассматривать в следующей практической статье. Там посмотрим на каждую из стратегий. Рассмотрим способы борьбы с дубликатами с помощью механизма идемпотентности. Будет интересно!
С Kafka сообщением действительно получилось очень не очень. Про ключ хотел рассказать в следующей статье. Но из-за этого дал неверное понимание в этой. Про то, что можно в тело поместить любые байты, которые не обязательно могут быть Map, честно скажу, не знал.
С порядком сообщений внутри партиции тоже хотел разобраться в следующий раз. И про перераспределение партиций тоже накосячил. Имелось в виду, что перевыберет лидера.
Хах. Да, стиль ответов похож, не спорю. Особенно начало и конец. Но я просто хочу быть вежливым с читателями. А в наше время это ассоциируется с LLM-ками :)
RedPanda штука классная. Написана на плюсах, а не на Java и буст в производительности реально ощутим. Апишка совместима с Kafka полностью. В этой статье хотел прояснить лишь базовые моменты, связанные с Kafka. А с кроликом сравнил, чтоб показать различия между обычной очередью сообщений и журналом. Ещё RedPanda достаточно молодая и экосистема не такая широкая. Возможно, в следующих статьях и на неё посмотрим.
Отличные вопросы! Давайте разберёмся на конкретных примерах.
MQTT нужен для датчиков, телефонов, умных устройств. Пример: температура с датчика -> включить кондиционер. Он очень лёгкий и работает при условиях постоянной потери связи
RabbitMQ для задач между сервисами. Пример: покупатель сделал заказ -> количество товара на складе уменьшилось. Он гарантирует, что сообщение точно дойдёт.
Kafka для хранения всей истории сообщений, что были в системе. Пример: все действия пользователя для аналитики. Она хранит все, много отделов могут просматривать одни и те же данные.
То есть MQTT больше для мира IoT, а RabbitMQ и Kafka для бекенд разработки.
Обновил статью, исправив некоторые недочёты.
Лучше поздно, чем никогда :)
Старался :)
Обновил статью.
Используем
confluentinc/cp-kafkaвместо Bitnami (который переехал в legacy без обновлений).Действительно, с августа 2025 Bitnami переместили все образы в bitnami legacy, где они больше не получают обновления. Статья будет обновлена. Спасибо за фидбек!
Рад помочь!
Ответил на ваши вопросы во второй части :)
Ну поехали :)
Если вы добавляете консьюмеров без групп на топик, то партиции не распределяются. Каждый консьюмер читает все сообщения. Если же с группами, то в рамках одной группы будет распределение партиций.
Теперь давайте рассмотрим ваш кейс с 3 партициями:
Если 1 консьюмер, то он читает все партиции.
Если 2 консьюмера, то один читает две партиции, другой — одну.
Если 3 консьюмера, то каждый читает по одной.
Ещё предлагаю для большего понимания рассмотреть случай, когда консьюмеров в группе больше, чем партиций. В этом случае "лишние" консьюмеры будут простаивать.
Если хотите, чтобы разными сервисами обрабатывались одни и те же сообщения, надо все инстансы в рамках одного сервиса засунуть в одну группу. Так надо сделать для каждого интересующего вас сервиса.
Вторая часть вопроса несколько более сложная. Попытаюсь адекватно объяснить:
Оффсеты напрямую не сопоставляются с консьюмерами. Видите ли, какая ситуация, в топике, ответственном за оффсеты, хранятся сообщения следующего вида:
Ключ —
<group_id, topic, partition>Значение —
<commited_offset, metadata>Это нам даёт возможности для перебалансировки, так как нет жётской связи между оффсетом и конкретным инстансом.
В вашем кейсе с упавшим единственным консьюмером будет примерно следующее:
Kafka переведёт группу в состояние перебалансировки.
Контроллер кластера смаппит сообщение из offser-топика на текущий активный консьюмер.
Как следствие, активный консьюмер начнёт читать с последнего закоммиченного оффсета. То есть никаких потерь не будет, так как мёртвый брокер не мог закоммитить оффсеты для новых сообщений. На всякий случай отмечу, что коммит в Kafka — это некий процесс сохранения оффсета консьюмером.
И в этом случае настройка
latestприменена не будет, так как кафка смаппит оффсет на консьюмера, а эта настройка срабатывает, как вы, надеюсь, помните, когда Kafka не находит оффсет для консьюмера.Надеюсь, нигде не накосячил в объяснениях :)
Обновил статью.
Всё-таки решил дать гарантии доставки здесь, ибо в теоретической статье была бы слишком большая теоретическая вставка :)
Это понятно. Надо же чем-то заплатить за удобство :)
А вообще я говорил конкретно про отказоустойчивость в кластере.
Рад слышать, спасибо!
Я планирую обновить достаточно сильно эту статью. Выкладывал вечером, подуставший :)
Добавлю новый сервис, исправлю некоторые архитектурные косяки. И вставлю осмысленный ключ в примере.
Вам спасибо, что прочитали!
Все будет хорошо. Консьюмеры в одной группе не знают о консьюмерах в другой. Чтение будет происходить независимо.
На конкретное сообщение, как мне известно, настроить нельзя. Можно только настроить на топик. О том, как конкретно настроить, используя Spring Boot, я рассказал в своей свежей практической статье. Рекомендую к прочтению :)
Никак не поможет :)
Мы создаём новую группу не для того, чтобы разгрузить первую. Мы это делаем для того, чтобы эта самая новая группа имела доступ к тем же самым сообщениям, но выполняла другую логику. То есть для независимого чтения одних и тех же данных. Для разгрузки мы увеличиваем количество консьюмеров в рамках одной группы. Тогда уже между ними распределяются партиции и каждый читает свою часть данных.
Согласен с вами. Действительно, слегка запнулся в начале. Поправил статью. Теперь в начале задаю правильный контекст (называю Kafka журналом). Но дальше провожу аналогии с сообщениями, чтобы безболезненно ввести читателя в курс дела.
Спасибо!
Буквально все примеры в этой статье взяты из моего недавнего пет-проекта. Ну, за исключением сервиса метрик. В проекте я его не делал. Если не верите, добро пожаловать на гитхаб. В профиле есть ссылка.
Это очень интересная тема :)
Её мы будем рассматривать в следующей практической статье. Там посмотрим на каждую из стратегий. Рассмотрим способы борьбы с дубликатами с помощью механизма идемпотентности. Будет интересно!
Поправил проблемные разделы
Ценю конструктивную критику, спасибо :)
С Kafka сообщением действительно получилось очень не очень. Про ключ хотел рассказать в следующей статье. Но из-за этого дал неверное понимание в этой. Про то, что можно в тело поместить любые байты, которые не обязательно могут быть Map, честно скажу, не знал.
С порядком сообщений внутри партиции тоже хотел разобраться в следующий раз. И про перераспределение партиций тоже накосячил. Имелось в виду, что перевыберет лидера.
В общем, да, есть куда стремиться
Хах. Да, стиль ответов похож, не спорю. Особенно начало и конец. Но я просто хочу быть вежливым с читателями. А в наше время это ассоциируется с LLM-ками :)
Классный момент!
RedPanda штука классная. Написана на плюсах, а не на Java и буст в производительности реально ощутим. Апишка совместима с Kafka полностью. В этой статье хотел прояснить лишь базовые моменты, связанные с Kafka. А с кроликом сравнил, чтоб показать различия между обычной очередью сообщений и журналом. Ещё RedPanda достаточно молодая и экосистема не такая широкая. Возможно, в следующих статьях и на неё посмотрим.
Спасибо вам за упоминание этой технологии :)
Отличные вопросы! Давайте разберёмся на конкретных примерах.
MQTT нужен для датчиков, телефонов, умных устройств. Пример: температура с датчика -> включить кондиционер. Он очень лёгкий и работает при условиях постоянной потери связи
RabbitMQ для задач между сервисами. Пример: покупатель сделал заказ -> количество товара на складе уменьшилось. Он гарантирует, что сообщение точно дойдёт.
Kafka для хранения всей истории сообщений, что были в системе. Пример: все действия пользователя для аналитики. Она хранит все, много отделов могут просматривать одни и те же данные.
То есть MQTT больше для мира IoT, а RabbitMQ и Kafka для бекенд разработки.
Спасибо за вопросы! Надеюсь, вам стало понятнее!