Обработка исключений в посреднике сообщений в сеансе, в котором выполняется потребитель или производитель

Question

Я хочу использовать шаблон SAGA в своих микросервисах Spring Boot. Например, для клиента, при создании заказа, создается событие типа OrderCreatedEvent, а затем в микросервисе клиента слушатель на OrderCreatedEvent Обновляет кредит клиента и производит CreditUpdateEvent и ....

Я использую сеанс транзакции JmsTemplate для создания события. В javadoc JmsTemplate сказано, что транзакция JMS зафиксирована после основной транзакции:

Это приводит к тому, что локальная транзакция JMS управляется вместе с основной транзакцией (которая может быть собственной транзакцией JDBC), а транзакция JMS фиксируется сразу после основной транзакции.

Теперь у меня вопрос, как мне справиться со сценарием, приведенным ниже:

Основная зафиксированная транзакция (например, подтвержденный заказ подтвержден) и системе не удалось зафиксировать транзакцию JMS (по любой причине).

Я хочу использовать SAGA вместо двухфазного принятия, но я думаю, что просто SAGA перенесет проблему с заказа и обслуживания клиентов на службу заказов и JMS-провайдера.

Answer 1

SAGA намекает на проблему:

Есть также следующие проблемы для решения:

...

• Чтобы быть надежным, служба должна атомарно обновить свою базу данных и опубликовать событие. Он не может использовать традиционный механизм распределенной транзакции, который охватывает базу данных и брокер сообщений. Вместо этого он должен использовать один из шаблонов, перечисленных ниже.

...

Следующие шаблоны являются способами атомарного обновления состояния и публикации событий:

• Источник событий
• События приложения
• Триггеры базы данных
• Журнал транзакций

Event Sourcing является особенным в этом списке, поскольку он вносит радикальные изменения в то, как ваша система хранит и обрабатывает данные. Обычно системы хранят только текущее состояние объектов. Некоторые системы добавляют явную поддержку исторических состояний с периодами действия и / или битемпоральных данных .

Системы, основанные на Event Sourcing, хранят последовательность событий, а не состояние объекта, таким образом, чтобы он мог восстановить состояние по событиям. Поддерживается только один транзакционный ресурс - хранилище событий, поэтому нет необходимости координировать транзакции.

Другие шаблоны в списке позволяют избежать проблемы координации транзакций, требуя, чтобы код источника событий фиксировал все изменения - как состояния объектов, так и события (как объекты) - в одном хранилище данных. Затем реализуется выделенный, но отдельный механизм - издатель событий, который извлекает события из хранилища данных и публикует их для потребителей событий.

Издателю событий потребуется отслеживать опубликованные / неопубликованные события, что обычно возвращает проблему согласованных транзакций. Такова была идемпотентность потребителей событий. Издатель событий будет воспроизводить события с последней известной позиции, в то время как потребители будут игнорировать дубликаты.

Вы также можете обратить вспять активные / пассивные аспекты производителя событий и потребителей событий. Источник событий сохраняет состояние объектов и события (как объекты) в одном хранилище данных и предоставляет конечную точку, которая позволяет потребителю событий получать доступ к потокам событий. Каждый потребитель событий отслеживает обработанные / необработанные события - что он должен делать в любом случае по соображениям идемпотентности - но только для потоков событий, которые его интересуют. Действительно хорошее объяснение этого подхода дано в книге ОТДЫХ на практике - главы 7 и 8.