会话事务消费者或生产者中的消息代理异常处理

moh*_*1m2 7 java jms saga spring-boot microservices

我想在我的Spring Boot微服务中使用SAGA模式.例如,按客户的顺序,当订单创建时,生成的事件OrderCreatedEvent,然后在客户微服务中,监听器上OrderCreatedEvent更新客户信用并生成CreditUpdateEvent和....

我使用会话事务JmsTemplate来生成事件.在javadoc中JmsTemplate 说JMS事务在主事务之后提交:

这具有本地JMS事务与主事务(可能是本机JDBC事务)一起管理的效果,JMS事务在主事务之后立即提交.

现在我的问题是如何处理以下场景:

提交的主事务(例如,订单已提交已提交)和系统无法提交JMS事务(出于任何原因).

我想使用SAGA而不是两阶段提交,但我认为只是SAGA将问题从订单和客户服务转移到订单服务和JMS提供商.

Ill*_*sil 1

SAGA提示了这个问题:

还有以下问题需要解决:

...

  • 为了可靠,服务必须自动更新其数据库发布事件。它无法使用跨数据库和消息代理的分布式事务的传统机制。相反,它必须使用下面列出的模式之一。

...

以下模式是自动更新状态和发布事件的方法:

  • 事件溯源
  • 应用事件
  • 数据库触发器
  • 事务日志拖尾

事件溯源在此列表中很特殊,因为它给系统存储和处理数据的方式带来了根本性的变化。通常,系统仅存储实体的当前状态。一些系统添加了对具有有效期和/或双时态数据的历史状态的显式支持。

基于事件溯源的系统存储事件序列而不是实体状态,其方式允许从事件重建状态。只需维护一种事务资源 - 事件存储 - 因此无需协调事务。

列表中的其他模式通过要求事件生成器代码将所有更改(实体状态和事件(作为实体))提交到单个数据存储来避免事务协调问题。然后,实现一个专用但独立的机制 - 事件发布者 - 从数据存储中获取事件并将其发布给事件使用者。

事件发布者需要跟踪已发布/未发布的事件,这通常会带来协调事务的问题。这就是事件消费者的幂等性暴露出来的地方。事件发布者将从最后一个已知位置重播事件,而消费者将忽略重复事件。

您还可以反转事件生产者和事件消费者的主动/被动方面。事件生产者将实体状态和事件(作为实体)存储到单个数据存储中,并提供允许事件使用者访问事件流的端点。每个事件使用者都会跟踪已处理/未处理的事件(出于幂等性原因,它无论如何都需要这样做),但仅限于它感兴趣的事件流。《REST in Practice 》一书的第 7 章和第 8 章对这种方法给出了很好的解释。