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提供商.
SAGA提示了这个问题:
还有以下问题需要解决:
...
- 为了可靠,服务必须自动更新其数据库并发布事件。它无法使用跨数据库和消息代理的分布式事务的传统机制。相反,它必须使用下面列出的模式之一。
...
以下模式是自动更新状态和发布事件的方法:
- 事件溯源
- 应用事件
- 数据库触发器
- 事务日志拖尾
事件溯源在此列表中很特殊,因为它给系统存储和处理数据的方式带来了根本性的变化。通常,系统仅存储实体的当前状态。一些系统添加了对具有有效期和/或双时态数据的历史状态的显式支持。
基于事件溯源的系统存储事件序列而不是实体状态,其方式允许从事件重建状态。只需维护一种事务资源 - 事件存储 - 因此无需协调事务。
列表中的其他模式通过要求事件生成器代码将所有更改(实体状态和事件(作为实体))提交到单个数据存储来避免事务协调问题。然后,实现一个专用但独立的机制 - 事件发布者 - 从数据存储中获取事件并将其发布给事件使用者。
事件发布者需要跟踪已发布/未发布的事件,这通常会带来协调事务的问题。这就是事件消费者的幂等性暴露出来的地方。事件发布者将从最后一个已知位置重播事件,而消费者将忽略重复事件。
您还可以反转事件生产者和事件消费者的主动/被动方面。事件生产者将实体状态和事件(作为实体)存储到单个数据存储中,并提供允许事件使用者访问事件流的端点。每个事件使用者都会跟踪已处理/未处理的事件(出于幂等性原因,它无论如何都需要这样做),但仅限于它感兴趣的事件流。《REST in Practice 》一书的第 7 章和第 8 章对这种方法给出了很好的解释。
归档时间: |
|
查看次数: |
224 次 |
最近记录: |