分布式讲解—分布式事务解决方案 刚性（2PC、3PC、XA协议）

1. 2PC

两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段，并且由事务协调者来协调所有事务参与者，如果准备阶段所有事务参与者都预留资源成功，则进行第二阶段的资源提交，否则事务协调者回滚资源。

1.1. 准备阶段

1. 协调者询问全部参与者，等待答复
2. 参与者执行本地事务操作，记录 undo 和 redo 信息到事务日志中，但不提交
3. 参与者执行成功后给协调者反馈同意

1.2. 提交阶段

协调者根据参与者的反馈信息通知各参与者提交或者回滚

1. 事务提交

当第一阶段参与者全部反馈同意，协调者发起提交事务请求，所有参与者回复统一，意味着完成事务

• 协调者通知全部参与者发出正式提交的commit请求
• 收到请求后，参与者正式执行事务提交操作
• 参与者完成后向协调者发送ack消息
• 协调者收到后，完成事务

完整流程如下

2.事务回滚

事务回滚的原理也很容易，当收到任意一个节点返回的消息是中止或者超时时间内拿不到全部节点的ack消息，那么就通知全部参与者执行回滚操作，并等待所有参与者返回的回滚ack确认信息

1.3. 总结分析与疑问

总结

2PC能提供原子性操作，但有以下的问题待解决

1. 单点故障风险：如图可知，资源管理器统一协调所有参与者，一旦资源管理器出现故障，则参与者无法完成Commit操作，会一直处于阻塞状态。尽管资源管理器会重新选举，当还是无法解决之前遗留的阻塞问题。
2. 可靠性:如果协调者在二阶段的时候宕机，全部资源都处在锁定状态，新协调者上位也没法解决(新协调者没法跟旧参与者联系，类似上下文不一致)
3. 数据一致性:在超时时间之前，一部分参与者收到commit请求执行了，一部分由于网络问题没收到commit没有执行，会带来短期数据不一致的问题
4. 需要本地数据库支持XA协议。
5. 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈

1.没拿到全部回滚的ack确认码怎么处理?

正常操作就是按照时间设置梯度重试，重试无法解决后就记录失败信息，通过定时任务 进行补偿，补偿也补偿不来就人工接入，也可以使用TCC分布式事务补偿机制实现

2.协调者突然宕机带来的问题？

2. 3PC

三阶段提交说二阶段提交协议的优化版本，主要有2个改动点

• （1）在协调者和参与者中都引入超时机制
• （2）在第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的。

2.1. CanCommit阶段

协调者问参与者能否提交，并等待响应

2.2. RreCommmit阶段

如果全部参与者响应yes，那么协调者发起 preCommit请求并进入准备阶段，参与者们都执行预提交(执行事务但不提交事务)并返回ack码，等待最终命令

如果有一个no或者超时，那么就协调者就发起中断请求，参与者们收到中断请求或者超时没得到协调者的请求就执行事务中断

2.3. doCommit阶段

收到全部参与者发来的ack后就进行正式提交阶段，这时候，如果超时收不到事务提交的ack响应，参与者会继续执行事务提交，如果超时收不到事务中断的响应，也会自动进行事务的中断。

2.4. 总结

进入doCommit阶段后，无论协调者出现问题，或者协调者与参与者之间的网络出现问题，都会导致参与者无法接收到协调者发出的 doCommit 请求或 abort 请求。此时，参与者都会在等待超时之后，继续执行事务提交。这其实基于概率来决定的，当进入第三阶段时，说明第一阶段收到所有参与者的CanCommit响应都是Yes，意味着大家都同意修改了，并且第二阶段所有的参与者对协调者的PreCommit请求也都是同意的。所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit 或者abort响应，但是他有理由相信：成功提交的几率很大。

与2PC相比，3PC降低了阻塞范围，并且在等待超时后，协调者或参与者会中断事务，避免了协调者单点问题，阶段三中协调者出现问题时，参与者会继续提交事务。

数据不一致问题依然存在，当在参与者收到 preCommit 请求后等doCommit 指令时，此时如果协调者请求中断事务，而协调者因为网络问题无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

刚性事务：XA模型、XA接口规范、XA实现

XA模型 或者 X/Open DTP模型

X/OPEN是一个组织.X/Open国际联盟有限公司是一个欧洲基金会，它的建立是为了向UNIX环境提供标准。它主要的目标是促进对UNIX语言、接口、网络和应用的开放式系统协议的制定。它还促进在不同的UNIX环境之间的应用程序的互操作性，以及支持对电气电子工程师协会（IEEE）对UNIX的可移植操作系统接口（POSIX）规范。

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

在X/Open DTP(Distributed Transaction Process)模型里面，有三个角色：

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

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

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

• • XA把参与事务的角色分成AP，RM，TM。
  • AP，即应用，也就是我们的业务服务。
  • RM指的是资源管理器，即DB，MQ等。
  • TM则是事务管理器。

AP自己操作TM，当需要事务时，AP向TM请求发起事务，TM负责整个事务的提交，回滚等。

XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接口。XA接口是双向的系统接口，在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。

XA之所以需要引入事务管理器是因为，在分布式系统中，从理论上讲（参考Fischer等的论文），两台机器理论上无法达到一致的状态，需要引入一个单点进行协调。事务管理器控制着全局事务，管理事务生命周期，并协调资源。资源管理器负责控制和管理实际资源（如数据库或JMS队列）

XA规范

什么是XA

用非常官方的话来说:

• XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。
• XA 规范 描述了全局的事务管理器与局部的资源管理器之间的接口。 XA规范 的目的是允许的多个资源（如数据库，应用服务器，消息队列等）在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。
• XA 规范 使用两阶段提交（2PC，Two-Phase Commit）协议来保证所有资源同时提交或回滚任何特定的事务。
• XA 规范 在上世纪 90 年代初就被提出。目前，几乎所有主流的数据库都对 XA 规范 提供了支持。

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各个阶段的处理流程

XA协议的实现

2PC/3PC协议

两阶段提交（2PC）协议是XA规范定义的 数据一致性协议。

三阶段提交（3PC）协议对 2PC协议的一种扩展。

Seata

Seata , 官网 , github , 1万多星

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式

在 Seata 开源之前，Seata 对应的内部版本在阿里经济体内部一直扮演着分布式一致性中间件的角色，帮助经济体平稳的度过历年的双11，对各BU业务进行了有力的支撑。商业化产品GTS 先后在阿里云、金融云进行售卖

XA规范的问题

但是XA规范在1994年就出现了，至今没有大规模流行起来，必然有他一定的缺陷：

1. 数据锁定：数据在事务未结束前，为了保障一致性，根据数据隔离级别进行锁定。
2. 协议阻塞：本地事务在全局事务 没 commit 或 callback前都是阻塞等待的。
3. 性能损耗高：主要体现在事务协调增加的RT成本，并发事务数据使用锁进行竞争阻塞。

XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。

其实也并非不用，例如在IBM大型机上基于CICS很多跨资源是基于XA协议实现的分布式事务，事实上XA也算分布式事务处理的规范了，但在为什么互联网中很少使用，究其原因有以下几个：

• 性能（阻塞性协议，增加响应时间、锁时间、死锁）；
• 数据库支持完善度（MySQL 5.7之前都有缺陷）；
• 协调者依赖独立的J2EE中间件（早期重量级Weblogic、Jboss、后期轻量级Atomikos、Narayana和Bitronix）；
• 运维复杂，DBA缺少这方面经验；
• 并不是所有资源都支持XA协议；

准确讲XA是一个规范、协议，它只是定义了一系列的接口，只是目前大多数实现XA的都是数据库或者MQ，所以提起XA往往多指基于资源层的底层分布式事务解决方案。其实现在也有些数据分片框架或者中间件也支持XA协议，毕竟它的兼容性、普遍性更好。