Comments 11
Я не понимаю концепт, можете объяснить?
Есть schema registry, при сериализации/десериализации мы сверяем схему с той что в реестре, и если нет соответствия - падаем. Окей.
Изменили тип поля с int на string, запушили в реестр. Сериализация/десериализация сообщений падают из за того что несовместимы со схемой.
Обновили producer чтобы сериализовывал в соответствии с актуальной схемой. Consumer продолжает падать.
Обновили consumer, чтобы десериализовывал в соотв с актуальной схемой. Падать перестало.
Упавшие сообщения остаются в dlq и никогда оттуда не вернутся сами по себе.
В целом, то же самое случилось бы с авро, или без него: пока consumer/producer не синхронизируются все будет лететь в dlq, с той или другой стороны.
Если оно не решает проблему миграций, то какую проблему тогда оно решает?
Та же схема могла бы спокойненько себе лежать где нить в confluence.
Дело в том, что без Avro продюсер в какой-то момент может начать слать другую структуру и об этом никто не узнает до падения консьюмера. С Avro и Schema Registry реестр не примет схему ещё на этапе регистрации, до того, как начнут лететь сообщения. То есть проблемное сообщение даже не будет отправлено.
Avro это не про миграции. Это скорее про раннее обнаружение ошибок несовместимости структуры. Миграции же требуют координации в любом случае. Ну это если вы под миграциями имеете в виду опасные изменения (то есть те, которые конфликтуют с предыдущими схемами). Безопасные же изменения Avro + Schema Registry разрешают без проблем.
до того, как начнут лететь сообщения
в реальном мире это означает что сообщение с неактуальной схемой осядет в outbox/inbox, и никогда оттуда не выйдет пока ты его не смигрируешь и после какой то retry механизм не заберет смигрированное сообщение и не отправит в синкованные ноды.
принял, большое спасибо!
Написал статью, как и обещал - спасибо, Легенда!
Так как Kafka уже давно поддерживает не только Avro, но и ProtoBuf, на мой взгляд, зря хотя бы не упомянули последний.
К тому же у ProtoBuf есть ряд преимуществ перед Avro. Например, если некоторым подписчикам интересны только незначительное количество полей в сообщениях топика, то ProtoBuf будет выглядеть предпочтительней.
Так же, IMHO, зря не упомянули о dlq (dead letter queue), в который подписчик может постить сообщения с ошибками десериализации.
А что значит "поддерживает"? В кафку можно любой набор байт отправить, тут не нужна поддержка какого-то определенного формата.
А что значит "поддерживает"?
Это значит, что Schema Registry поддерживает только Avro, Protobuf и JSON
В кафку можно любой набор байт отправить
Можно, но валидировать схему будете тогда самостоятельно, а от целого ряда компонентов Confluent и Debezium придётся отказаться.
Писать самому аналоги Debezium CDC Source и Sink - ещё то удовольствие.
Kafka для начинающих: Apache Avro и Schema Registry (теория)