在亿级流量架构之分布式事务解决方案对比中, 已经简单阐明了从本机事务到分布式事务的演变过程, 文章的最后简单说明了TCC事务, 这儿将会深入了解TCC事务是原理, 以及理论支持, 最后会用Demo举例实现。
XA协议
在上面提到的文章中, 分布式事务直接将二阶段提交, 思维逻辑有些断层, 但是那毕竟是比较解决方案, 在这儿从理论上推导分布式事务的根基, 也就是为什么要二阶段提交。
在单体应用中, 往往由自己来保证事务的一致性, 但是分布式中, 涉及到跨网络调用就难以保证, 从理论上讲两台机器理论上无法达到一致的状态, 所以专门从服务角色上将事务操作抽象出一个服务用来协调事务, 叫做协调者, 或者说事务管理者。由全局事务管理器管理和协调的事务,可以跨越多个资源(如数据库或JMS队列)和进程。全局事务管理器一般使用 XA 二阶段提交协议与数据库进行交互。
而XA协议, 就是事务管理者与各个服务模块(也叫服务者、资源管理者)之间的通讯遵守的协议就是XA协议, 简单来说就是规范了接口, 这个协议由X/Open组织提出, 是分布式事务的规范。 XA规范主要定义了全局事务管理器(TM)和局部资源管理器(RM)之间的接口。除此之外, XA接口是双向的系统接口,在事务管理器 (TM)以及一个或多个资源管理器(RM)之 间形成通信桥梁,如上图。
二阶段提交协议
二阶段协议,一句话说就是, 先进行一个复杂度低的询问操作, 看看各个服务模块(也叫参与者、资源管理者、RM)是否可以进行事务操作, 一方面检验网络是否通畅, 另一方面看看对应的资源是否被占用 , 如果可以得到的回应是所有的服务可以进行事务操作, 那么这时候再通知所有服务提交事务。详细地说, 二阶段提交(2PC:Two-Phase Commit), 该协议将一个分布式的事务过程拆分成两个阶段: 投票 和 事务提交 。为了让整个数据库集群能够正常的运行,该协议指定了一个 协调者(事务管理器) 单点,用于协调整个数据库集群各节点的运行。为了简化描述,我们将数据库集群中的各个节点称为 参与者(也叫服务者, 资源管理者) 。
第一阶段:投票
该阶段的主要目的在于打探数据库集群中的各个参与者是否能够正常的执行事务,具体步骤如下:
- 协调者向所有的参与者发送事务执行请求,并等待参与者反馈事务执行结果;