分布式事务实施方案总结

一、术语介绍

TX协议：应用或者应用服务器与事务管理器的接口
XA协议：全局事务管理器与资源管理器的接口。
两阶段提交协议（Two-phase Commit，2PC）
BASE理论：BA指的是基本业务可用性，支持分区失败，S表示柔性状态，也就是允许短时间内不同步，E表示最终一致性，数据最终是一致的，但是实时是不一致的。
CAP定理：对于共享数据系统，最多只能同时拥有CAP其中的两个
幂等操作：重复调用多次产生的业务结果与调用一次产生的结果相同
TCC操作：Try阶段，尝试执行业务，完成所有业务的检查，实现一致性；预留必须的业务资源，实现准隔离性。Confirm阶段：真正的去执行业务，不做任何检查，仅适用Try阶段预留的业务资源，Confirm操作还要满足幂等性。Cancel阶段：取消执行业务，释放Try阶段预留的业务资源，Cancel操作要满足幂等性。
可补偿操作：Do阶段：真正的执行业务处理，业务处理结果外部可见。Compensate阶段：抵消或者部分撤销正向业务操作的业务结果，补偿操作满足幂等性。
柔性事务有两个特性：基本可用和柔性状态。所谓基本可用是指分布式系统出现故障的时候允许损失一部分的可用性。柔性状态是指允许系统存在中间状态，这个中间状态不会影响系统整体的可用性。

二、设计思路

       根据CAP定理，大规模的分布式系统时会遇到三个特性一致性、可用性、分区容错，而一个分布式系统最多只能满足其中的2项。系统采取柔性事务方案，即不保证事务在过程中的强一致性，实际上由于消息传递带来的不可靠性，分布式事务过程中的强一致性也是不可靠的。转而求其次的将重点放在局部一致性和最终一致性上，同时确认一致性的延迟方案和补偿策略。同时参考二阶段提交的业务整体预留+业务确认和XA支持的预提交+整体确认策略，避免整体一致性带来的性能开销，采用局部预提交+局部确认+整体监控的方案。单个应用的事务一致性有应用自身的事务机制管理，整体事务一致性有消息管理服务器整体确认，事务之间必须满足确认，验证，回滚等策略。到此为止，X/Open提供的DTP模型完整提现。

三、整体方案

每个应用包含一个独立的RM和TM，RM负责资源管理，TM作为子事务管理器，
事务管理器：

     事务管理器负责自身事务管理，和父级事务通信，配合全局事务进行回滚等功能。事务管理器至少包括注册事务，获取事务ID，上报事务状态，全局回滚策略，以及必要的重试机制。

资源管理器：

     服务中间消息和业务消息存储。

应用：

      业务的独立执行单位，应用组件与通过事务管理器和通信资源管理器同步事务状态，业务执行只受和资源管理器的交互影响，需要实现自身的等待和重试机制，等待和重试期间，其他业务不受阻塞事务的影响。

通信资源管理器：

      分配全局事务ID，参与的事务通过全局事务ID进行，事务管理需要实现等待和回滚机制，在有限等待后开启事务回滚；通信资源管理器需要实现事务追溯机制，人工干预情况下可以通过通信资源管理器追溯事务执行情况，通信资源管理器需要实现人工干预功能，必要情况下可以人工干预任意应用节点的执行状态。

总结：
      通过对几个分布式事务方案的理解，发现主要局限点在于事务整体执行的制约，我个人觉得分布式事务场景中，整体同步执行无法实现，因为整体同步执行需要靠消息传递控制，而消息传递具有不可靠性，所以事务整体同步执行无法做到。退而求齐全的方案应该是有限度的容忍事务延迟执行，保证局部事务一致性的前提下保持事务整体一致性。当然由于个人理解局限方案存在不足地方还请见谅，毕竟在次一天之前我一直坚信分布式场景下谈事务是一个悖论；以及保证事务一致性唯一的验证途径就是去数据源验证。

参考资料：
https://www.cnblogs.com/bluemiaomiao/p/11216380.html
http://www.tianshouzhi.com/api/tutorials/distributed_transaction/383
https://pubs.opengroup.org/onlinepubs/9294999599/toc.pdf
https://pubs.opengroup.org/onlinepubs/009680699/toc.pdf