Дело в том, что без Avro продюсер в какой-то момент может начать слать другую структуру и об этом никто не узнает до падения консьюмера. С Avro и Schema Registry реестр не примет схему ещё на этапе регистрации, до того, как начнут лететь сообщения. То есть проблемное сообщение даже не будет отправлено.
Avro это не про миграции. Это скорее про раннее обнаружение ошибок несовместимости структуры. Миграции же требуют координации в любом случае. Ну это если вы под миграциями имеете в виду опасные изменения (то есть те, которые конфликтуют с предыдущими схемами). Безопасные же изменения Avro + Schema Registry разрешают без проблем.
В большинстве систем транзакции Kafka не нужны. Чаще всего проще и надёжнее использовать тех же самых идемпотентных консьюмеров. В статье как раз разобраны сценарии, где транзакции действительно оправданы (если очень уж нужна атомарность), и почему во многих случаях от них больше вреда, чем пользы.
При использовании StatefulSet в Kubernetes (или других решений со стабильными идентификаторами) каждый pod имеет постоянное имя, которое сохраняется между перезапусками (например, my-service-0, my-service-1 и т.д.). В таком сценарии можно использовать transactional.id в виде префикса, основанного на имени pod’а (например, ${POD_NAME}), что позволяет избежать как накопления незавершённых транзакций, так и проблем с fencing.
В статье я сфокусировался на базовой настройке Spring Boot и не углублялся в детали deployment'а — всё-таки добавлю это уточнение в статью.
Имеете право не согласиться. Выбор зависит от контекста. С позиции SOLID вы полностью правы. Когда я писал "костыльно", я имел в виду "решение, которое создаёт больше сложности, чем решает проблему" для нашего учебного проекта. А "чище" относилось к тому, что мы пишем меньше кода и создаём меньше сущностей (что оптимально для небольших проектов). Для крупных проектов 2 бина предпочтительнее из-за лучшей тестируемости и разделения ответственности между командами. Обновлю статью с этими уточнениями. Спасибо за фидбек!
Действительно, с августа 2025 Bitnami переместили все образы в bitnami legacy, где они больше не получают обновления. Статья будет обновлена. Спасибо за фидбек!
Добрый день!
Значительно обновил статью. Вырезал ненужную информацию, добавил больше деталей, постарался объяснить всё более понятно
Всегда пожалуйста!
Да. Если используется Outbox Pattern, то так и будет. Вы правы!
Дело в том, что без Avro продюсер в какой-то момент может начать слать другую структуру и об этом никто не узнает до падения консьюмера. С Avro и Schema Registry реестр не примет схему ещё на этапе регистрации, до того, как начнут лететь сообщения. То есть проблемное сообщение даже не будет отправлено.
Avro это не про миграции. Это скорее про раннее обнаружение ошибок несовместимости структуры. Миграции же требуют координации в любом случае. Ну это если вы под миграциями имеете в виду опасные изменения (то есть те, которые конфликтуют с предыдущими схемами). Безопасные же изменения Avro + Schema Registry разрешают без проблем.
Всегда пожалуйста!
Рад, что статья оказалась полезной!
Всегда пожалуйста! И спасибо за дополнение!
Вы, безусловно, правы. Уверен, что читателям будет полезно прочитать ваш комментарий.
Совершенно верно. Мониторинг – интересная, но достаточно большая тема. Может, как-нибудь рассмотрим и это.
В большинстве систем транзакции Kafka не нужны. Чаще всего проще и надёжнее использовать тех же самых идемпотентных консьюмеров. В статье как раз разобраны сценарии, где транзакции действительно оправданы (если очень уж нужна атомарность), и почему во многих случаях от них больше вреда, чем пользы.
Спасибо за комментарий!
На самом деле да, это правда.
При использовании
StatefulSetв Kubernetes (или других решений со стабильными идентификаторами) каждый pod имеет постоянное имя, которое сохраняется между перезапусками (например,my-service-0,my-service-1и т.д.). В таком сценарии можно использоватьtransactional.idв виде префикса, основанного на имени pod’а (например,${POD_NAME}), что позволяет избежать как накопления незавершённых транзакций, так и проблем с fencing.В статье я сфокусировался на базовой настройке Spring Boot и не углублялся в детали deployment'а — всё-таки добавлю это уточнение в статью.
Вам ещё раз спасибо!
Да, лучше прописать это явно
Всегда пожалуйста!
Эту тему как раз буду разбирать в следующей статье.
Рад, что вам нравится!
Приветствую! Рад, что вам нравится!
Avro планировал в скором времени рассмотреть. Кастомную имплементацию думал опустить, но раз уж интересно, то обязательно посмотрим.
Имеете право не согласиться. Выбор зависит от контекста. С позиции SOLID вы полностью правы. Когда я писал "костыльно", я имел в виду "решение, которое создаёт больше сложности, чем решает проблему" для нашего учебного проекта. А "чище" относилось к тому, что мы пишем меньше кода и создаём меньше сущностей (что оптимально для небольших проектов). Для крупных проектов 2 бина предпочтительнее из-за лучшей тестируемости и разделения ответственности между командами. Обновлю статью с этими уточнениями. Спасибо за фидбек!
Обновил статью, исправив некоторые недочёты.
Лучше поздно, чем никогда :)
Старался :)
Обновил статью.
Используем
confluentinc/cp-kafkaвместо Bitnami (который переехал в legacy без обновлений).Действительно, с августа 2025 Bitnami переместили все образы в bitnami legacy, где они больше не получают обновления. Статья будет обновлена. Спасибо за фидбек!
Рад помочь!
Ответил на ваши вопросы во второй части :)