分布式事务精华总结篇

奈学教育

-     总述     -

咱们前面分别对分布式事务的几个分支：XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇，讲对前面的内容查缺补漏和总结，最后对市面的一些开源框架做一些介绍。

-     查缺补漏     -

1. 补偿型事务
柔性事务分补偿型事务和通知型事务。但对补偿型事务没有进行详细介绍，那什么是补偿型事务呢，在Atomikos 公司Guy Pardon的论文《Business_Activities》中有这样的描述： 大致含义是，"补偿是一个独立的支持ACID特性的本地事务，用于在逻辑上取消了先前ACID交互的影响。对于一个长事务来说，基于补偿的方法可将事务资源锁定时间保持在最低程度，从而避免了事务资源长期占用等缺点。”。

2.TCC事务模型补充
咱们前面文章说了不推荐TCC，并且认为Seata的AT模式从理论上来说更像是Saga的变种，而非TCC的变种。目前有很多资料自行将TCC分了几个分支：

• 通用型TCC：标准TCC模型实现，从业务服务需要提供try、confirm、cancel
  
• 补偿性TCC：子服务只需要提供 Do 和 Compensate 两个接口
  
• 异步确保型 TCC：主服务是可靠消息服务，而子服务则通过消息服务解耦，作为消息服务的消费端，异步地执行。可靠消息服务需要提供 Try、Confirm、Cancel 三个接口。Try 接口只负责持久化记录存储消息数据；Confirm 接口确认发送，这时才开始真正的投递消息；Cancel 接口取消发送，删除消息数据。
  
  

原始论文《Life beyond Distributed Transactions》和 Atomikos 官网上并没有类似的划分，这些划分其实是一些公司在内部实践中，自行提出的概念。但是并未找到比较大的公司进行背书。所以其实咱们从论文上去看：

• 补偿性TCC并未提供Try接口，其实已经更接近Saga了，反而应该认为是Saga的变种。
  
• 异步确保型 TCC中 子服务不需要提供try、confirm、cancel三个接口，称为TCC貌似也不合适，从本质上其实事务消息的一种可靠投递方式而已。
  
  

3. Saga 事务模型补充
咱们说过Saga设计必须遵循允许空补偿、保持幂等性、防止资源悬挂三个策略，因为Saga事务不保证隔离性，在极端情况下可能由于脏写无法完成回滚操作。比如举一个极端的例子, 分布式事务内先给用户A充值, 然后给用户B扣减余额, 如果在给A用户充值成功, 在事务提交以前, A用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了。这就是缺乏隔离性造成的典型的问题, 实践中一般的应对方法是：

• 业务流程设计时遵循“宁可长款, 不可短款”的原则, 长款意思是客户少了钱机构多了钱, 以机构信誉可以给客户退款, 反之则是短款, 少的钱可能追不回来了。所以在业务流程设计上一定是先扣款。
  
• 有些业务场景可以允许让业务最终成功, 在回滚不了的情况下可以继续重试完成后面的流程, 所以要求Saga除了提供“回滚”能力还需要提供“向前”恢复上下文继续执行的能力, 让业务最终执行成功, 达到最终一致性的目的。
  
  

Saga 实现分两种，一种是Saga 状态机实现，一种是Saga AOP Proxy实现，但是前文缺少对比，补充如下：





Saga 状态机实现，在关于参与者服务编排实现又有集中式和协同式两种分支，他们的对比详情如下：

18633769561

11111111111111111