Странно. По идее пакет org.apache.avro.* должен подтянуться транзитивно. Если вы ставили зависимость, о которой я писал выше, то должно работать. Можете проверить дерево зависимостей Maven, вдруг какие конфликты версий
Точно сказать не могу, так как всё будет зависеть от степени загруженности. Со своей стороны я постараюсь выпустить новую статью как можно скорее, но при этом сделать так качественно, как смогу. Ориентировочно, понадобится 2-3 недели (а может и меньше).
Благодарю за дополнение и извиняюсь за поздний ответ.
Про Protobuf рассказать в общих чертах, в целом, можно было. Но в данной статье я делал акцент именно на Avro. Обязательно в дальнейшем рассмотрю и Protobuf.
Дело в том, что без 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 бина предпочтительнее из-за лучшей тестируемости и разделения ответственности между командами. Обновлю статью с этими уточнениями. Спасибо за фидбек!
Странно. По идее пакет org.apache.avro.* должен подтянуться транзитивно. Если вы ставили зависимость, о которой я писал выше, то должно работать. Можете проверить дерево зависимостей Maven, вдруг какие конфликты версий
Да, вообще это так.
Но мы в наши сервисы добавляли зависимость:
Она транзитивно подтягивает ту зависимость, о которой вы говорите. Соответственно, её можно вручную не указывать
Всегда пожалуйста!
Действительно, да. Что-то закружился и не рассмотрел. Допишу практ. применение режимов в эту статью обязательно.
Спасибо за фидбек!
Огромное спасибо за такие слова! Именно ради этого я и начал всю серию.
Оставайтесь на связи, дальше будет ещё интереснее!
Всегда пожалуйста!
Точно сказать не могу, так как всё будет зависеть от степени загруженности. Со своей стороны я постараюсь выпустить новую статью как можно скорее, но при этом сделать так качественно, как смогу. Ориентировочно, понадобится 2-3 недели (а может и меньше).
Благодарю за дополнение и извиняюсь за поздний ответ.
Про Protobuf рассказать в общих чертах, в целом, можно было. Но в данной статье я делал акцент именно на Avro. Обязательно в дальнейшем рассмотрю и Protobuf.
DLQ подробно рассматривал в предыдущей статье (https://habr.com/ru/articles/989608/).
Добрый день!
Значительно обновил статью. Вырезал ненужную информацию, добавил больше деталей, постарался объяснить всё более понятно
Всегда пожалуйста!
Да. Если используется 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 бина предпочтительнее из-за лучшей тестируемости и разделения ответственности между командами. Обновлю статью с этими уточнениями. Спасибо за фидбек!