分布式事务解决方案 - TFdream/blog GitHub Wiki
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
分布式系统的特性
对分布式系统有过研究的读者，可能听说过“CAP定律”、“Base理论”等，非常巧的是，化学理论中ACID是酸、Base恰好是碱。这里笔者不对这些概念做过多的解释，有兴趣的读者可以查看相关参考资料。CAP定律如下图：
在分布式系统中，同时满足“CAP定律”中的“一致性”、“可用性”和“分区容错性”三者是不可能的，这比现实中找对象需同时满足“高、富、帅”或“白、富、美”更加困难。在互联网领域的绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。
1. 两阶段提交
2. TCC(Try-Confirm-Cancel)
TCC，是基于补偿型事务的AP系统的一种实现，具有最终一致性。
对比与前面提到的两阶段提交法, 有两大优势：
- TCC能够对分布式事务中的各个资源进行分别锁定，分别提交与释放，例如，假设有AB两个操作，假设A操作耗时短，那么A就能较快的完成自身的try-confirm-cancel流程，释放资源，无需等待B操作。如果事后出现问题, 追加执行补偿性事务即可。
- TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作)，也就是各服务之间可以在一定程度上”异步并行”执行。
适用场景
- 严格一致性
- 执行时间短
- 实时性要求高
举例：红包、收付款业务。
3. 异步确保型
通过将一系列同步的事务操作变为基于消息执行的异步操作， 避免了分布式事务中的同步阻塞操作的影响。
需要额外说明的一点，就是事务消息投递到MQ订阅方后，并不一定能够成功执行。需要MQ订阅方主动给予消费反馈（ack）：
适用场景
- 执行周期较长
- 实时性要求不高
例如：
- 跨行转账/汇款业务(两个服务分别在不同的银行中)
- 退货/退款业务
- 财务，账单统计业务(先发送到消息中间件, 然后进行批量记账)
4. 最大努力通知型
这是分布式事务中要求最低的一种，也可以通过消息中间件实现，与前面异步确保型操作不同的一点是，在消息由MQ Server投递到消费者之后，允许在达到最大重试次数之后正常结束事务。
适用场景
交易结果消息的通知等。