Comments 5
Отличная статья, спасибо)
Прорабатывался ли как-то вопрос с несколькими инстансами сервиса Outbox? Поскольку сообщения из БД вычитываются шедулером, рано или поздно два инстанса прочитают и отправят одно сообщение
Спасибо за отзыв)
Пока я проводил тестирование стартера только на единичных инстансах, поэтому с такой проблемой не сталкивался, но скорее всего при нынешней реализации каждый инстанс будет забирать все сообщения сразу, если у них синхронизируются шедулеры. Я изучу вопрос и подумаю, как это можно реализовать
Между подсистемами, передающих сообщения, используйте буфер исходящих сообщений на случай отказа инфраструктуры, передающей сообщения. Буфер входящих сообщений не нужен потому, что брокер сообщений и есть буфер.
Смысл такой же был?
Вы правы насчёт брокера как буфера - это его основная суть, и в этом плане Inbox действительно может казаться лишним звеном.
Но я добавил его не как "ещё один буфер", а скорее как слой контроля на стороне самого сервиса. С его помощью проще разруливать дубли (которые гарантированы при at-least-once), следить за порядком событий и хранить историю обработки для отладки или аудита. Это больше про гарантию работы, чем про необходимость.
Но помимо использования брокеров я буду писать поддержку для REST и реактивного программирования, где гарантированного буфера в лице брокеров нет. Там Inbox становится необходимостью, если мы хотим гарантировать, что ни одно событие не потеряется.
Спасибо, что заглянули в детали!
Избавляемся от потерянных событий в микросервисах — как я написал свой Spring Starter для Outbox/Inbox