分布式事务常用的解决方案及优缺点
全局事务（DTP模型） --标准的分布式事务
全局事务（DTP模型） --XA协议
mysql oracle 都是实现了XA协议
两阶段提交（Two Phase Commit）
J2EE平台中分布式事务的实现
标准分布式事务解决方案的利弊
- 优点：
严格的ACID - 缺点：
效率非常低（微服务架构不太适用）- 全局事务下，全局事务管理器（TM） 通过XA接口适用两阶段提交协议（2PC） 与资源层（如数据库）进行交互。使用全局事务，数据被Lock的时间跨越整个事务，直到全局事务结束
- 2PC是反可伸缩模式，在数据处理过程中，参与者需要一直持有资源直到整个分布式事务的结束。这样，当业务规模越来越大的情况下，2PC的局限性就越来越明显，系统可伸缩性就会变得很差
- 与本地事务相比，XA协议的系统开销很大，因而应当珍重考虑是否确实需要分布式事务。而且只有支持XA协议的资源才能参与分布式事务
Base理论
CAP定理
例如：zookeeper是cp（一致性和分区容错性），Eureka是ap（可用性和分区容错性）
柔性事务
- 两阶段类型
- 补偿性
- 异步确保性
- 最大努力通知性
柔性事务中的服务模式（接口）
- 可查询操作
- 幂等操作
- TCC操作
- 可补偿操作
服务模式是柔性事务流程中的特殊操作的实现（实现上对应业务服务要提供相应模式的功能接口），还不算是某一种柔性事务解决方案
几种常见的柔性事务解决方案
可靠消息最终一致性（异步确保型）
- 实现
业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送。业务处理服务在业务事务处理后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送
- 消息
业务处理服务在业务事务回滚后，向实时消息服务取消发送。消息状态确认系统定期找到未确认发送或者回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或者消息内容确定该消息是否有效
- 约束
被动方的处理结果不影响主动方的处理结果，被动方的消息处理操作是幂等操作
- 成本
可靠消息服务建设成本
一次消息发送需要两次确认，业务处理服务需要实现消息状态回查接口
- 优点，适用范围
消息数据独立存储，独立伸缩，降低业务系统与消息系统间的耦合
对最终一致性时间敏感度较高，降低业务被动方实现成本
- 用到的服务模式
可查询操作，幂等操作
- 方案特点
兼容所有实现JMS标准中间件
确保业务数据可靠性前提下，实现业务数据的最终一致性（理想状态下基本是准实时一致的）
- 行业应用
支付宝，ebay，去哪儿，携程。。。
TCC（两阶段，补偿性）
- 实现
一个完成的业务活动由一个主业务与若干从业务服务组成
主业务服务负责发起并完成整个业务活动
从业务提供TCC型业务操作
业务活动管理器控制业务活动的一致性，它等级业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务员活动取消时调用所有TCC型操作的cancel操作
- 成本
实现TCC操作的成本
业务活动结束时confirm或cancel操作执行成本
业务活动的日志成本
- 适用范围
强隔离性，严格一致性要求的业务活动
适用于执行时间较短的业务，（比如处理账户，收费等业务）
- 用到的服务模式
TCC操作，幂等操作，可补偿操作，可查询操作
- 方案特点
不与具体的服务框架耦合（在RPC架构中通用）
位于业务服务层，而非资源层
可以灵活选择业务资源的锁定粒度
TCC里对每个服务资源的操作都是本地事务，数据被lock的时间短，可扩展性好（可以说是为独立部署的SOA服务而设计的）
- 行业应用
支付宝XTS(蚂蚁金融云的分布式事务服务DTS)
最大努力通知（定期校对）
- 实现
业务活动的主动方，在完成业务处理之后，向业务活动的被动方发送消息，允许消息丢失业
务活动的被动方根据定时策略，向业务活动主动方查询，恢复丢失的业务消息
- 约束
被动方的处理结果不影响主动方的处理结果
- 成本
业务查询与校对系统的建设成本
- 适用范围
对业务最终一致性的时间敏感度低
跨企业的业务活动
- 用到的服务模式
可查询操作
- 方案特点
业务活动的主动方在完成业务处理后，向业务活动被动范发送通知消息（允许消息丢失）
主动方可以设置时间阶梯型通知规则，在通知失败后按规则重复通知，直到通知N次后不再通知
主动方提供小队校对查询接口给被动方按需校对查询，用于恢复丢失的业务消息
- 行业应用案例
银行通知 商户通知等（各大交易业务平台间的商户通知：多次通知，查询校对，对账文件等）
总结
常用的分布式事务解决方案
- 刚性事务
全局事务（标准的分布式事务）
- 柔性事务
可靠消息最终一致性（异步确保型）
TCC（两阶段，补偿性）
最大努力通知（定期校对）
纯补偿性