Обработка исключений брокера сообщений в сеансе-потребителе или производителе

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

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

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

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

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

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


spring-boot java microservices jms saga
person mohammad_1m2    schedule 01.11.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

...

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

...

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

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

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

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

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

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

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

person Illya Kysil    schedule 10.11.2018

arrow_upward
0
arrow_downward

С помощью SAGA вы хотите разделить или переупорядочить шаги транзакции (tx) на 3 этапа:

  1. Tx шагов, для которых вы можете иметь компенсирующее действие. Для каждого T1..N у вас есть C1..N
  2. Шаги передачи, которые нельзя компенсировать. Если они терпят неудачу, вы запускаете ранее определенные C1..N
  3. Повторяемые шаги Tx, которые всегда успешны.

САГА - это не КИСЛОТА, а только ACD. Вам нужно реализовать изоляцию, чтобы предотвратить грязное чтение. Обычно с замком.

Почему САГА? Чтобы избежать синхронного связывания времени выполнения и доступности заливки. Вы ждете, пока последний участник совершит фиксацию.

Это довольно высокая цена.

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

person Marian Venin    schedule 29.06.2020