都成功或者都失败是事务目标，实际中往往会采用最终一致、最大努力一致和不一致时人工介入策略。

评估事务，通常会根据业务特点，考虑对于事务相关业务之间所需的时效性、依赖联系因素，框定事务可用方案，并结合事务实现代价综合评定选择事务方案。

事务特点分析：时效性与依赖联系

分析事务的时效性和依赖联系非常重要，而且往往从业务角度一分析就一目了然。需要及时性的场景就不赘述了，简单说一个准实时的场景，比如下单，下完单后需要通知对应人员处理订单，假设，我们需要存储订单，并且存储订单通知信息到对应的处理人消息列表中。此时，我们只需要保证订单存储成功的同时，消息列表也会存储成功，中间允许存在短暂的延时，这种场景就只要达到最终一致即可。

具体事务方案

在讨论事务具体方案前，再补充一点信息，大多数情况下，其实是可以降低事务的颗粒度，即节省事务时间。锁当然是越小越好，比如在进行事务操作前，尽量将所需的依赖信息、数据封装处理等提前处理完毕，还有事务锁定的范围能到具体某个资源id、用户、时间、业务状态等更小范围就控制锁定在这个小范围，这样执行事务期间，可以减少事务消耗的时间和事务影响的范围，以节省事务的资源消耗，提高系统的吞吐率。

接下里就可以讨论事务具体可用的方案，实际中采用的方案主要有：

本地事务

最简单的就是本地事务，利用存储的事务支持，直接进行。这种方式最简单也最省心，当然如果单事务涉及到的资源特别多，也不一定是最优方案，可能采用后面的一些方案，进行事务拆分、巧用事件机制，虽然总体的资源可能增加，但是单粒度减小了反而可能得到更高的吞吐率，而且有时候系统的职责也会更清晰，扩展能力更强。

分布式事务

这里不再赘述2PC、3PC、XA、TCC模型了，这些网上资料都很全，资源消耗、维护成本、引入第三方中间件等事务成本也有详尽的讨论，本文就重点聊事务消息、消息中间件和本地消息表。

这三种类型都是基于消息中间件，而消息中间件几乎是系统标配，而使用消息中间件也有降低复杂度、解耦的好处，因此也是在业务场景允许的情况下首选，当然优先顺序从维护事务成本来说一般是消息中间件、本地消息表，最后事务消息。

消息中间件：即请求到达后，不处理任何业务，直接发送消息，消息发送成功则直接返回。这种方式最简单，但仅限于纯异步场景，给用户返回时未执行任何操作，此时，只能告诉用户，你的请求已经提交成功了，至于结果，等执行完了才知道。

本地消息表：相当于将消息发送记录和主业务支持放在同一个本地事务中，然后触发消息发送，本地也实现一个线程定期扫描消息发送表中待发送的记录，进行二次触发。保证主业务执行成功，且最终消息一定能发送成功。这样既给用户一个有效的业务执行状态，又将事务简化了，前面提到的存储订单+通知到处理人的场景就非常适合。

事务消息：实质是让消息中间件来最终负责事务状态的确认，业务执行前先发事务消息，执行完成后确认消息发送。当业务未及时或正确确认消息发送时，由消息中间件来跟踪业务执行的结果。这里对于业务执行也有一定的要求，避免长时间业务执行过程中，收到消息中间件确认信息时，给到业务执行失败的假象。

借助消息队列，实际消息消费和者事务消息确认结果，都存在消息监控问题：

• 消息无法正常消费：消息发送成功后，接收消息执行业务的服务需要注意因为数据、代码错误等原因执行失败的情况，此时就需要监控消息的消费情况。这种情况可以订阅MQ的死信，通过死信来进行报警，人工处理后进行消息回放。
• 消费延迟：有时消息因为消息产生过快、消费端处理慢、消息队列数或消费者不够导致消息积压，使得有时间限制的业务及时将业务处理完成。此时，可以监控消息队列的消费积压情况，可以采取限流、优化消费者代码处理逻辑、适当增加消息队列中topic队列数、根据队列数增加消费者数量等手段避免消息长期积压。
• 事务消息确认超时：事务消息的确实也是有时间、次数限制的，比如RocketMQ 在达到上限时，则会简单在日志中打印一条事务消息执行异常的日志，此时就需要监控消息队列日志，及时报警，人工介入处理。

还有一个是消息重新投递的时间和次数限制，前面探讨中已提到消息次数限制可以通过死信来二次处理，重新投递时间的问题，则需要通过综合手段来解决，比如根据业务情况调整异常投递的时间间隔，消费者端对于消息处理失败一定时间的特殊报警逻辑。还有一种情况是，比如使用有限资源来进行处理，该资源紧张，但又需要在释放后及时重新响应，则可以考虑确认上条消息，再次重新发送一条一样的消息重新进入消息队列的方法，即忙碌时重新末尾排队。

总结

实际过程中事务的解决需要根据业务的特定来进行方案选择，而且也可能是一个长事务采用多种方案结合的方案，利用消息中间件是一种有效的降低复杂度和提升可维护性的方案，单采取该方案实现有明显的副作用，一是延迟，二是消息监控问题。