在亿级流量架构之分布式事务解决方案对比中, 已经简单阐明了从本机事务到分布式事务的演变过程, 文章的最后简单说明了TCC事务, 这儿将会深入了解TCC事务是原理, 以及理论支持, 最后会用Demo举例实现。
XA协议
在上面提到的文章中, 分布式事务直接讲二阶段提交, 思维逻辑有些断层, 但是那毕竟是比较解决方案, 在这儿从理论上推导分布式事务的根基, 也就是为什么要二阶段提交。
在单体应用中, 往往由自己来保证事务的一致性, 但是分布式中, 涉及到跨网络调用就难以保证, 从理论上讲两台机器理论上无法达到一致的状态, 所以专门从服务角色上将事务操作抽象出一个服务用来协调事务, 叫做协调者, 或者说事务管理者。由全局事务管理器管理和协调的事务，可以跨越多个资源(如数据库或JMS队列)和进程。全局事务管理器一般使用 XA 二阶段提交协议与数据库进行交互。
而XA协议, 就是事务管理者与各个服务模块(也叫服务者、资源管理者)之间的通讯遵守的协议就是XA协议, 简单来说就是规范了接口, 这个协议由X/Open组织提出, 是分布式事务的规范。 XA规范主要定义了全局事务管理器(TM)和局部资源管理器(RM)之间的接口。除此之外, XA接口是双向的系统接口，在事务管理器 （TM）以及一个或多个资源管理器（RM）之 间形成通信桥梁,如上图。
二阶段提交协议
二阶段协议,一句话说就是, 先进行一个复杂度低的询问操作, 看看各个服务模块(也叫参与者、资源管理者、RM)是否可以进行事务操作, 一方面检验网络是否通畅, 另一方面看看对应的资源是否被占用 , 如果可以得到的回应是所有的服务可以进行事务操作, 那么这时候再通知所有服务提交事务。详细的说, 二阶段提交(2PC：Two-Phase Commit), 该协议将一个分布式的事务过程拆分成两个阶段： 投票 和 事务提交 。为了让整个数据库集群能够正常的运行，该协议指定了一个 协调者(事务管理器) 单点，用于协调整个数据库集群各节点的运行。为了简化描述，我们将数据库集群中的各个节点称为 参与者(也叫服务者, 资源管理者) 。
第一阶段：投票
该阶段的主要目的在于打探数据库集群中的各个参与者是否能够正常的执行事务，具体步骤如下：
- 协调者向所有的参与者发送事务执行请求，并等待参与者反馈事务执行结果；
- 事务参与者收到请求之后，执行事务但不提交，并记录事务日志；
- 参与者将自己事务执行情况反馈给协调者，同时阻塞等待协调者的后续指令。
第二阶段：事务提交
在经过第一阶段协调者的询盘之后，各个参与者会回复自己事务的执行情况，这时候存在 3 种可能性：
- 所有的参与者都回复能够正常执行事务。
- 一个或多个参与者回复事务执行失败。
- 协调者等待超时。
对于第 1 种情况，协调者将向所有的参与者发出提交事务的通知，具体步骤如下：
- 协调者向各个参与者发送 commit 通知，请求提交事务；
- 参与者收到事务提交通知之后执行 commit 操作，然后释放占有的资源；
- 参与者向协调者返回事务 commit 结果信息。
除此之外, 还有2种情况, 囿于篇幅, 详情参考: 亿级流量架构之分布式事务思路及方法后面的二阶段提交协议
今天要聊的TCC就是二阶段提交的具体事务实现。
LCN
详情参考:官网(中文版)
有了前面的XA协议以及二阶段提交的知识, 就不难理解LCN框架了, 这个框架可以理解成就是上面所说的协调者, 不生产事务, 只负责协调事务。5.0以后框架兼容了LCN、TCC、TXC三种事务模式。
LCN中各个字母依次代表:锁定事务单元（lock）、确认事务模块状态(confirm)、通知事务(notify)。
在一个分布式系统下存在多个模块协调来完成一次业务。那么就存在一次业务事务下可能横跨多种数据源节点的可能。TX-LCN目的是解决这样的问题。
例如存在服务模块A 、B、 C。A模块是mysql作为数据源的服务，B模块是基于redis作为数据源的服务，C模块是基于mongo作为数据源的服务。若需要解决他们的事务一致性就需要针对不同的节点采用不同的方案，并且统一协调完成分布式事务的处理。
在LCN中, 协调者称之为TxManager , 参与者称之为 TxClient, TxManager作为分布式事务的控制方, 事务发起方或者参与方都由TxClient端来控制决定。
时序图(来源官网):
LCN核心步骤
- 创建事务组
是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。 - 加入事务组
添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。 - 通知事务组
是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。
TCC
详情参考: Github(中文版)
TCC事务机制相对于二阶段提交，其特征在于它不依赖资源管理器(RM)对XA协议的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务, 将事务分成 Try 和 Confirm/ Cancel两个阶段。
三种操作作用: Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。
整体流程如图
Try 从执行阶段来看，与传统事务机制(二阶段提交)中业务逻辑相同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑。TCC机制将传统事务机制(2PC)中的业务逻辑一分为二:
拆分后保留的部分为初步操作（Try）；
而分离出的部分即为验证操作（Confirm/cancel），被延迟到事务提交阶段执行。
三阶段主要特点:
| Try 阶段 | Confirm阶段 | Cancel阶段 | |
|---|---|---|---|
| 主要含义 | 尝试执行业务 | 确认执行业务 | 取消执行业务 |
| 执行操作 | 完成所有业务检查( 一致性 ) | 不做任务业务检查 | 释放 Try 阶段预留的业务资源 |
| 预留必须业务资源( 准隔离性 ) | Confirm 操作满足幂等性 | Cancel 操作满足幂等性 | |
| 真正执行业务 |