Почему Kafka недостаточно: гарантированная доставка сообщений в распределённых системах

[Mrrabbit_1]

Интересно, а вы рассматривали вариант с идемпотентными продюсерами + дедупликацией на стороне потребителя?

[Gromilo]

Инбокс делает дедупликацию в предложенной схеме.

А что за идемпотентные продюсеры?

[mr_green773]

Идемпотентный продюсер решает только одну задачу — предотвращает дублирование записей в Kafka при повторной отправке.
Он гарантирует, что одно и то же сообщение не будет записано в топик дважды, даже если продюсер повторно отправит его из-за сетевого сбоя. Это работает только внутри Kafka.

Идемпотентный продюсер не решает проблему согласованности между бизнес-операцией и публикацией события:
если сервис успел сохранить заказ в БД, но упал до отправки сообщения в брокер — событие потеряется, и другие сервисы об этом заказе не узнают.

[shirmanov]

В примере приведен консьюмер для события, который принимает сообщение из топика, дёргает save репозитория и делает acknowledge для сообщения. Допускаем, что перед ack упало, значит сообщение не обработано, и после восстановления будет обработано повторно. Операция репозитория неидемпотентная, что и приводит к проблеме.

Предлагается принимать сообщения в Inbox. В обработчике для инбокса операция записи в инбокс уже идемпотентная, что позволяет возникающую проблему избежать.

Далее представим как изменится обработчик сообщения, который теперь берет сообщение из инбокса вместо кафки. В нем после вызова репозитория будет acknowledge в инбоксе. И аналогично существует вероятность падения между вызовами репозитория и ack инбокса. Т.е. инбокс не позволил уйти от заявленной проблемы.

[mr_green773]

Спасибо за комментарий. В нашей реализации inbox используется событийная модель. Т.е. берется из inbox -> в транзакции выполняется бизнес операция и изменение статуса у сообщения.
Сама статья больше сфокусирована на том, что Apache Kafka не даёт гарантии доставки на уровне всей системы и где именно эти гарантии теряются.
Если будет интересно, могу отдельно разобрать реализацию Outbox/Inbox с учётом идемпотентности и границ транзакций.

[shirmanov]

Конечно, давайте посмотрим на реализацию.