Как использовать управление схемами kafka и Avro для прерывания изменений

Question

Управление схемами kafka с помощью avro дает нам гибкость для обратной совместимости, но как нам справиться с критическими изменениями в схеме?

Предположим, что производитель А публикует сообщения M для потребителя C

предположим, что в сообщении M произошли критические изменения в его схеме (например, поле имени теперь разделено на first_name и last_name), и у нас есть новая схема M-New

Сейчас мы разворачиваем продюсера A-New и Consumer C-New

проблема в том, что до завершения процесса развертывания у нас может быть опубликовано сообщение M-new для производителя A-new, где Consumer C (старый) получит M-new, и из-за этого мы можем потерять сообщение.

Таким образом, единственный способ сделать это - синхронизировать развертывание новых производителей и потребителей, что увеличивает накладные расходы

есть предложения, как с этим справиться?

Answer 1

например, поле имени теперь разделено на first_name и last_name

Определение Avro "обратно совместимой" схемы не позволило вам добавить эти новые поля без 1) сохранения старогополе имени 2) добавление значений по умолчанию к новым полям - https://docs.confluent.io/current/schema-registry/avro.html

Если ваши Потребители сначала обновят свою схему, они увидят поле старого имени, продолжая отправляться старыми производителями, а также интерпретируя значения по умолчанию дляновые поля, пока производители не обновят и не начнут отправлять новые поля

Если производители обновятся первыми, то потребители никогда не увидят новые поля, поэтому производители все равно должны отправить поле имени или выбрать отправку мусоразначение, которое начнет преднамеренно нарушать потребителей (например, сделать поле пустым для начала, но никогда не отправлять пустое значение, затем начать отправку пустого значения, в то время как потребители предполагают, что оно не может быть пустым)

В любом случае, я чувствуюкак ваша логика обработки записей должна определить, какие поля доступны ине NULL или их значения по умолчанию.

Но , сравните это с JSON или любой простой строкой (например, CSV), и у вас нет гарантии того, какие поля должны быть там, если ониnullable, или какие они типы (дата является строкой или длинной?), поэтому вы не можете гарантировать, на какие объекты ваши клиенты будут внутренне отображать сообщения для обработки ... Это большее преимущество Avro, чем я нахожу, чем правила совместимости

Лично я считаю, что принудительная совместимость FULL_TRANSITIVE в реестре работает лучше всего, когда между вашими пользователями Kafka практически отсутствует связь

Answer 2

Легким способом было бы иметь длительный срок хранения для ваших тем. Тогда вы просто создаете новую тему для критических изменений. Все потребители могут перейти к новой теме в течение срока хранения без потери сообщений.