分布式事务解决方案对比分析
1.一致性，吞吐量，复杂度对比
| 2PC | 3PC | TCC | 可靠消息 | 最大努力通知 | SAGA |
|---|
| 一致性 | 强一致 | 强一致 | 最终一致 | 最终一致 | 最终一致 | | 吞吐量 | 低 | 低 | 中 | 高 | 高 | | 实现复杂度 | 容易 | 中 | 难 | 中 | 容易 |
2.分布式事务大致归类
- 基于2PC实现的分布式事务。
- 基于事务消息的分布式事务。
- 基于TCC实现的分布式事务(业务层2PC)。
- 基于SAGA实现的分布式事务。
- 基于补偿实现的分布式事务，如seata的AT。
- 基于最大努力通知的事务。
3.分布式解决方案适用理解
1.XA(2PC)
XA方案太依赖数据库了，性能没法得到保证，而且都要求强一致了，把这重任交给分布式事务，是不是不太合适，可以改造业务成单机事务，耗时虽然可能多些，但是效益是永久的，单机事务效率得到保证，同时还能得到重构经验和踩坑经验，之后设计就可以更敏感的规避分布式事务。
适用场景
- 如果业务并发度真的不高，事务又需要支持回滚，数据库也能支持XA协议，又不想开发太多代码，那么这时候就选XA方案吧。
- 适用于执行时间确定的短事务，在高并发的性能至上场景中，XA不适合。
2.可靠消息最终一致性方案
同步转异步，服务还解耦，性能有保证
适用场景
- 适用于分布式事务的提交或回滚只取决于事务发起方的业务需求，其他数据源的数据变更跟随发起方进行的业务场景。
- 对于实时性要求不高，主业务逻辑无需外部数据变更协助来完成的最终一致性事务。
- 适合执行周期长，实时性要求不高，同时业务上不需要回滚的场景。
- 适用于异步业务处理场景。
3.基于补偿实现的分布式事务(AT)
事务的提交，不单单只依赖事务发起者，还得由其他服务一起保证时，比如订单扣款服务，订单服务下了订单，然后调用扣款服务，此时扣款服务得保证用户账户是有钱的，这笔交易才算成功完成，就不适用于消息事务方案了，毕竟不论是先扣钱再发送消息去创建订单，还是先创建订单再发送消息去扣钱，前者网络出问题，会导致用户钱扣了，订单缺迟迟查不到，后者很可能订单都创建了，然后发现钱不够，消息事务一般都是通过重试保证数据一致，基本不提供回滚操作，此时数据不一致的情况就产生了。
适用场景
- 事务消息方案满足不了，又要求编码少的场景。
- 事务的成功由多个服务一起保证，同时每个服务都需要补偿机制的场景。
- 允许数据有脏读的场景，比如发现订单创建了，然后因为钱不够又被取消了的情况。
- 并发量不高的场景。
4.TCC
如果以上AT方案满足不了，比如说不允许用户看到订单还未完成，账户钱就被扣了的场景，实时性、一致性要求比较高，简单的理解就是不允许出现数据脏读的情况。
可以把TCC理解成是业务层2PC方案，适用场景广，但是大部分情况可以先不考虑，因为代码开发量可能很多，无形中引入新方案反而增加了开发成本，不过如果和钱有关的，还是可以考虑引入的，得保证在资金上不会出现问题。
适用场景
- 实时性、一致性要求高，需要根据其他服务结果来决定业务走向。
- 不允许出现脏读的情况，数据一致性要求高。
- 业务需要实现用户无感知的回滚场景。
- 资金交易类业务。
5.基于SAGA实现的分布式事务
可以把SAGA可以看做一个异步的、利用队列实现的补偿事务，该方案缺少隔离性，会出现中间状态，简单的可以理解为脏读。
适用场景
- 事务链路较长，耗时较久，可以允许用户看到中间状态，便于观察每个子事务的执行情况。
- 需要补偿机制
- 不需要返回事务发起方执行结果的场景，要么一路重试走到成功，要么一路回退回归初始状态。
- 事务的参与者有第三方公司的系统，无法进行改造和提供TCC 要求的接口，就可以考虑引入Saga模式，此时只要第三方系统接口返回执行失败，事务链路往回的补偿操作都是本系统能够提供的。
- 只需要保证最终一致性的场景。
6.最大努力通知型事务(非可靠消息+定期校对)
最大努力通知方案不把结果成功的压力全部依赖给发起通知方，发起通知方会尽最大的努力将业务处理结果通知给接收通知方，但是不保证消息一定会被接收通知方收到，此时需要接收通知方主动来主动查询业务处理结果，尽最大可能保证一致性。
适用场景
- 业务对最终一致性时间敏感度低，同时接收通知方的处理结果不影响发起通知方的场景。
- 充值类业务，短信类业务。
4.分布式解决方案选型建议
- 如果业务场景要求强一致性，那么最好尽量避免分散业务在不同服务中，尽量采用本地事务，尽量避免使用强一致性事务解决方案。
- 选型参考优先级：单机事务 》消息事务方案 》AT 》TCC 》SAGA
- 有些业务情况为了更好的性能可以采用混合事务方案，比如订单，账户，积分，订单的提交成功依赖账户，但是不依赖于积分，所以订单和账户可以用TCC补偿事务，订单和积分可以用消息事务方案。
- 如果业务要求强一致，同时又是分布式部署情况，那么就采用TCC方案，别采用2PC方案，性能太低了，无法保证后续是否还要改造，不如一开始就把时间花的在刀刃上。
?
|