java - session 事务消费者或生产者中的消息代理异常处理

Question

我想使用 SAGA我的 Spring Boot 微服务中的模式。例如，在客户订单中，当订单创建时，会产生一个类似 OrderCreatedEvent 的事件，然后在客户微服务中 OrderCreatedEvent 上的监听器更新客户信用并产生 CreditUpdateEvent 和...。

我使用 session 事务处理 JmsTemplate 来生成事件。在 JmsTemplate 的 javadoc 中表示 JMS 事务在主事务之后提交:

This has the effect of a local JMS transaction being managed alongside the main transaction (which might be a native JDBC transaction), with the JMS transaction committing right after the main transaction.

现在我的问题是如何处理以下情况:

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

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

Answer 1

SAGA提示问题:

There are also the following issues to address:

...

• In order to be reliable, a service must atomically update its database and publish an event. It cannot use the traditional mechanism of a distributed transaction that spans the database and the message broker. Instead, it must use one of the patterns listed below.

...

The following patterns are ways to atomically update state and publish events:

• Event sourcing
• Application events
• Database triggers
• Transaction log tailing

Event Sourcing在此列表中很特别，因为它会彻底改变您的系统存储和处理数据的方式。通常，系统只存储实体的当前状态。一些系统添加了对具有有效期和/或bitemporal data的历史状态的明确支持。 .

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

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

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

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