分布式事务:XA,2PC,3PC,TCC

一.分布式事务产生原因

1.原本的数据是单库单表存储，随着业务的不断扩大数据量不断增多，单库性能支撑不了数据的更新与访问。为了解决数据库上的瓶颈，将数据库进行水平拆分，原来一个库里的事务操作，现在变成了 跨数据库的事务操作。

2.随着业务不断增长，将业务中不同模块服务拆分成 微服务后，同时调用多个微服务所产生的跨服务分布式事务问题。

 

二.分布式事务中的各个概念

在学习分布式事务中会在很多的地方看到很多概念，看的也是令人一头雾水，不知道其中的关系。接下来进行全面的介绍。

首先，X/OPEN是一个组织

1.X/Open DTP模型

X/Open DTP(Distributed Transaction Process)是一个分布式事务模型。这个模型主要使用了两段提交(2PC - Two-Phase-Commit)来保证分布式事务的完整性。在这个模型里面，有三个角色：

    AP: Application，应用程序。也就是业务层。哪些操作属于一个事务，就是AP定义的。

    TM: Transaction Manager，事务管理器。接收AP的事务请求，对全局事务进行管理，管理事务分支状态，协调RM的处理，通知RM哪些操作属于哪些全局事务以及事务分支等等。这个也是整个事务调度模型的核心部分。

    RM：Resource Manager，资源管理器。一般是数据库，也可以是其他的资源管理器，如消息队列(如JMS数据源)，文件系统等。

2.XA协议(XA Specification)

是X/OPEN 提出的分布式事务处理规范。XA则规范了TM与RM之间的通信接口，在TM与多个RM之间形成一个双向通信桥梁，从而在多个数据库资源下保证ACID四个特性。目前知名的数据库，如Oracle, DB2,mysql等，都是实现了XA接口的，都可以作为RM。

XA是数据库的分布式事务，强一致性，在整个过程中，数据一张锁住状态，即从prepare到commit、rollback的整个过程中，TM一直把持折数据库的锁，如果有其他人要修改数据库的该条数据，就必须等待锁的释放，存在长事务风险。

以下的函数使事务管理器可以对资源管理器进行的操作：
1）xa_open,xa_close：建立和关闭与资源管理器的连接。
2）xa_start,xa_end：开始和结束一个本地事务。
3）xa_prepare,xa_commit,xa_rollback：预提交、提交和回滚一个本地事务。
4）xa_recover：回滚一个已进行预提交的事务。
5）ax_开头的函数使资源管理器可以动态地在事务管理器中进行注册，并可以对XID(TRANSACTION IDS)进行操作。
6）ax_reg,ax_unreg；允许一个资源管理器在一个TMS(TRANSACTION MANAGER SERVER)中动态注册或撤消注册。

 

XA各个阶段的Mysql处理流程

 

3.TCC

TCC是业务的分布式事务，最终一致性，不会出现长事务的锁风险，try是本地事务，锁定资源后就提交事务，confirm／cancel也是本地事务，可以直接提交事务，所以多个短事务不会出现长事务的风险。

 

三.分布式事务理论基础

1.两阶段提交（Two-phase Commit，2PC）

是XA用于在全局事务中协调多个资源的机制

顾名思义，两阶段提交在处理分布式事务时分为两个阶段：voting（投票阶段，有的地方会叫做prepare阶段）和commit阶段。

2pc中存在两个角色，事务协调者（seata、atomikos、lcn）和事务参与者，事务参与者通常是指应用的数据库。

两阶段提交协议解决的是分布式数据库数据强一致性问题

缺陷：

• 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
• 单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者 宕机导致的参与者处于阻塞状态的问题）
• 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。

2PC的比喻：

 

 

2.三阶段提交（3PC）

三阶段提交协议在协调者和参与者中都引入 超时机制，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。三阶段提交的三个阶段分别为：can_commit，pre_commit，do_commit。

在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者abort请求时，会在等待超时之后，继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时， 由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。 ）

 

2PC和3PC的区别：

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞， 因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

 

3.TCC（Try-Confirm-Cancel）

Try阶段：

    完成所有业务检查（一致性），预留业务资源(准隔离性)

Confirm阶段：

    确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源。要满足幂等性。

Cancel阶段：

    取消Try阶段预留的业务资源。

TCC与XA两阶段提交有着异曲同工之妙，下图列出了二者之间的对比  

1) 在阶段1：

    在XA中，各个RM准备提交各自的事务分支，事实上就是准备提交资源的更新操作(insert、delete、update等)；

    而在TCC中，是主业务活动请求(try)各个从业务服务预留资源。

2) 在阶段2：

    XA根据第一阶段每个RM是否都prepare成功，判断是要提交还是回滚。如果都prepare成功，那么就commit每个事务分支，反之则rollback每个事务分支。

    TCC中，如果在第一阶段所有业务资源都预留成功，那么confirm各个从业务服务，否则取消(cancel)所有从业务服务的资源预留请求。

TCC两阶段提交与XA两阶段提交的区别是：

    XA是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，一直会持有资源的锁。

       XA事务中的两阶段提交内部过程是对开发者屏蔽的，开发者从代码层面是感知不到这个过程的。而事务管理器在两阶段提交过程中，从prepare到commit/rollback过程中，资源实际上一直都是被加锁的。如果有其他人需要更新这两条记录，那么就必须等待锁释放。

    TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

 

     TCC中的两阶段提交并没有对开发者完全屏蔽，也就是说从代码层面，开发者是可以感受到两阶段提交的存在。try、confirm/cancel在执行过程中，一般都会开启各自的本地事务，来保证方法内部业务逻辑的ACID特性。其中：

    1、try过程的本地事务，是保证资源预留的业务逻辑的正确性。

    2、confirm/cancel执行的本地事务逻辑确认/取消预留资源，以保证最终一致性，也就是所谓的补偿型事务(Compensation-Based Transactions)。由于是多个独立的本地事务，因此不会对资源一直加锁。

 

另外，这里提到confirm/cancel执行的本地事务是 补偿性事务：

补偿是一个独立的支持ACID特性的本地事务，用于在逻辑上取消服务提供者上一个ACID事务造成的影响，对于一个长事务(long-running transaction)，与其实现一个巨大的分布式ACID事务，不如使用基于补偿性的方案，把每一次服务调用当做一个较短的本地ACID事务来处理，执行完就立即提交

 

4.TCC事务模型 VS DTP事务模型

比较一下TCC事务模型和DTP事务模型，如下所示：

这两张图看起来差别较大，实际上很多地方是类似的!

1、TCC模型中的主业务服务 相当于 DTP模型中的AP，TCC模型中的从业务服务 相当于 DTP模型中的RM

      在DTP模型中，应用AP操作多个资源管理器RM上的资源；而在TCC模型中，是主业务服务操作多个从业务服务上的资源。例如航班预定案例中，美团App就是主业务服务，而川航和东航就是从业务服务，主业务服务需要使用从业务服务上的机票资源。不同的是DTP模型中的资源提供者是类似于Mysql这种关系型数据库，而TCC模型中资源的提供者是其他业务服务。

2、TCC模型中，从业务服务提供的try、confirm、cancel接口 相当于 DTP模型中RM提供的prepare、commit、rollback接口

    XA协议中规定了DTP模型中定RM需要提供prepare、commit、rollback接口给TM调用，以实现两阶段提交。

    而在TCC模型中，从业务服务相当于RM，提供了类似的try、confirm、cancel接口。

3、事务管理器

     DTP模型和TCC模型中都有一个事务管理器。不同的是：

     在DTP模型中，阶段1的(prepare)和阶段2的(commit、rollback)，都是由TM进行调用的。

     在TCC模型中，阶段1的try接口是主业务服务调用(绿色箭头)，阶段2的(confirm、cancel接口)是事务管理器TM调用(红色箭头)。这就是 TCC 分布式事务模型的二阶段异步化功能，从业务服务的第一阶段执行成功，主业务服务就可以提交完成，然后再由事务管理器框架异步的执行各从业务服务的第二阶段。这里牺牲了一定的隔离性和一致性的，但是提高了长事务的可用性。

 

参考资料：

https://juejin.im/entry/5836b48a880741304b6459be

https://www.cnblogs.com/gnodev/p/3817323.html

https://segmentfault.com/a/1190000012534071

http://www.tianshouzhi.com/api/tutorials/distributed_transaction/388