分布式事务（七）：分布式事务总结

基础知识回顾

事务的基本概念以及本地事务特征。

CAP、BASE理论的概念。

2PC、TCC、可靠消息最终一致性、最大努力通知。

不同分布式事务类型的应用场景分析。

RocketMQ事务消息机制。

Seata与传统XA原理上的差别。

分布式事务对比分析

在学习各种分布式事务的解决方案后，我们了解到各种方案的优缺点：

• 2PC最大的诟病是一个阻塞协议。RM在执行分支事务后需要等待TM的决定，此时服务会阻塞并锁定资源。由于其阻塞机制和最差时间复杂度较高，因此这种设计不能适应随着事务涉及的服务数量增加而扩展的需要，很难用于并发较高以及子事务生命周期较长的分布式服务中。
• 如果拿TCC事务的处理流程与2PC作比较，2PC通常都是在跨库的DB层面，而TCC则在应用层的处理，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据操作的颗粒度，使得降低锁冲突、提交吞吐量成为可能。而不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的原因实现不同的回滚策略。典型的使用场景，登录之后送优惠券。
• 可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。引入消息机制后，同步的事务操作变为基于消息执行的异步操作，避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。典型的使用场景：注册送积分、登录送优惠券等。
• 最大努力通知是分布式事务中要求最低的一种，适用于一些最终一致性时间敏感度较低的业务；允许发起通知方处理业务失败，在接收通知方收到通知后积极进行失败处理，无论发起通知方如何处理结果都不会影响到接收通知方的后续处理；发起通知方需要提供查询执行情况接口，用于接收通知方校对结果。典型的使用场景：银行通知、支付结果通知等。

	2PC	TCC	可靠消息最终一致性	最大努力通知
一致性	强一致性	最终一致性	最终一致性	最终一致性
吞吐量	低	中	高	高
实现复杂度	易	难	中	易

总结

• 在条件允许的情况下，我们尽可能选择本地事务单数据源，因为它减少了网络交互带来的性能损耗，且避免了数据弱一致性带来的种种问题。若某系统频繁且不合理的使用分布式事务，应首先从整体设计角度观察服务的拆分是否合理，是否高内聚低耦合？是否颗粒度太小？分布式事务一直是业界难题，因为网络的不确定性，而且我们习惯于拿分布式事务与单机事务ACID作对比。
• 无论是数据库层面的XA、还是应用层面的TCC、可靠消息、最大努力通知等方案，都没有完美解决分布式事务的问题，它们不过是各自在性能、一致性、可用性等方面作取舍，寻求某些场景下偏好的权衡。