分布式事物解决方案

目前采用的三种解决方案:
1、定期校队
2、TCC

Try: 尝试执行业务
完成所有业务检查（一致性）
预留必须业务资源（准隔离性）

Confirm: 确认执行业务
真正执行业务
不作任何业务检查
只使用Try阶段预留的业务资源
Confirm操作满足幂等性

Cancel: 取消执行业务
释放Try阶段预留的业务资源
Cancel操作满足幂等生

3、基于可靠消息
可靠消息
实现：

业务活动的主动方，在完成业务处理的同一个本地事务中，记录消息数据
业务处理事务提交后、通过实时消息通知业务被动方，实时通知成功后删除消息数据
消息恢复系统定期找到未成功发送的消息，交给实时消息服务补发送
约束：

被动方的处理结果不影响主动方的处理
被动方的消息处理操作是幂等操作
成本：

可靠消息系统建设成本
消息数据CRUD成本
适用范围

对最终一致性时间敏感度较高
降低业务被动方实现成本

实现方式2：

业务处理在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送
业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送消息
业务处理在业务事务回滚后，向实时消息服务取消发送
消息状态确认系统定期找到未确认发送或回溯的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效。
成本

一次消息发送需要两次请求
业务处理服务需实现消息状态回查接口
优点：
消息数据独立存储、独立伸缩
降低业务系统与消息系统间的耦合


CAP定理
对于共享数据系统，只能同时拥有以下三项中的两个：
Consistency(一致性): 所有 用户看到一致的数据
Availability(可用性): 对数据更新具备高可用性
Tolerance to Network Partition(分区容忍性): 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择


分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力！