分布式事务.XA方案

解决思路

两阶段提交（2PC）

案例同学聚会：
角色：  聚会 参与者  组织者
流程： 
1.    确定聚会  组织者开始打电话通知所有参与者参与者都说可以参加聚会举行commit
2.    确定聚会组织者开始打电话通知所有参与者参与者有人说不可以参加组织者告诉通知参与者取消聚会rollback

特点：
1.    保证的是强一致性，反过来说：如果有一个RM异常就没法执行
2.    2PC基于XA协议，只有部分关系数据库支持（Oracle、MySQL等）
3.    事务执行需要TM协调，增加了事务的时长，在高并发的场景支持能力有限
4.     2PC是基于所有节点都正常场景，这就导致应对异常能力不足，如果任何时间点出现单点故障，要不是数据不一致，要不就是TM卡死。

参考：

两阶段提交协议：事务管理器分两个阶段来协调资源管理器，第一阶段准备资源，也就是预留事务所需的资源，如果每个资源管理器都资源预留成功，则进行第二阶段资源提交，否则协调资源管理器回滚资源。

2PC协议的核心是，划分出了事务参与者和协调者的角色，并将整个过程划分成两个阶段。

第一阶段：所有事务参与者，执行后进行预提交；直到协调者收到所有参与者的预提交才会进入第二步；

如果在协调者的超时时间内，有任意参与者的预提交preCommit没发送或未到达，都会结束事务。
第二阶段：所有事务预提交了各自的结果后，由协调者决定最终事务是成功(commit)还是失败(rollback)。

二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点的：

1.执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2.参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。（没有多少容错机制）
3.协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。（这个可以依赖后面要讲的Paxos协议实现HA）
4.二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

为此，Dale Skeen和Michael Stonebraker在“A Formal Model of Crash Recovery in a Distributed System”中提出了三阶段提交协议（3PC）

三阶段提交（3PC）

       3PC提交是在2PC上的改进版本，3PC最关键要解决的就是协调者和参与者同时挂掉的问题，所以3PC把2PC的准备阶段再次一分为二，这样三阶段提交。处理流程如下：

案例同学聚会：

角色：聚会 参与者  组织者

流程：

1. 确定聚会 à 组织者开始打电话通知所有参与者询问是否可以参加à参与者收到通知根据情况判断是否可以参与并反馈yes/no
2.  All yes 场景：通知所有参与者聚合举行 à 参与者收到消息按照时间出发，在酒店外边签字(回复组织者是否OK)等候(不提交事务)
3. 有 no 或者 有电话打不通着 场景：协调者通知参与者 忽略本次聚会；如果协调者长时间不通知参与者自动忽略。
4. 所有参与者都到齐(执完成行ack的反馈都收到) 场景：协调者发出进入酒店提议(do Commit) 所有参与者一块走进酒店(提交事务)，并反馈提交成功，协调者收集所有参与者全部进入酒店，事务完成。
5. 有部分到期没有到的 场景：大家都回家吧(回滚)，如果人道了，协调者长时间不通知那么也自动回家。

特点：

1. 增加单点故障超时后就回滚的逻辑
2. 阶段31中，如果协调者出问题事务会提交，对外提供服务可能就是协调者异常了，此时你怎么给用户提示。
3. 阶段31中，如果参与者拉稀去厕所了没收到你提交事务的消息，其他事务已经提交，怎么办？回滚，已提交的数据其他事务可以访问了。 不会滚就连一致性保证不了了。  如果此时协调者故障，回滚没希望了，直接数据不一致。

参考：

两阶段提交不同的是，三阶段提交有两个改动点。

引入超时机制。同时在协调者和参与者中都引入超时机制。
在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

1. CanCommit阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

2. PreCommit阶段

协调者根据参与者的反应情况来决定是否可以继续事务的PreCommit操作。根据响应情况，有以下两种可能。 假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。
1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。
1.发送中断请求 协调者向所有参与者发送abort请求。
2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

3. doCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况。
3.1 执行提交
1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
3.响应反馈 事务提交完之后，向协调者发送Ack响应。
4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。
3.2 中断事务
协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
1.发送中断请求 协调者向所有参与者发送abort请求
2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息
4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

DTP模型

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

• AP: Application，应用程序。也就是业务层。哪些操作属于一个事务，就是AP定义的。
• TM: Transaction Manager，事务管理器。接收AP的事务请求，对全局事务进行管理，管理事务分支状态，协调RM的处理，通知RM哪些操作属于哪些全局事务以及事务分支等等。这个也是整个事务调度模型的核心部分。
• RM：Resource Manager，资源管理器。一般是数据库，也可以是其他的资源管理器，如消息队列(如JMS数据源)，文件系统等。

三者之间的关系如图：

一般的编程方式是这样的：

1. 配置TM，通过TM或者RM提供的方式，把RM注册到TM。可以理解为给TM注册RM作为数据源。一个TM可以注册多个RM。

1. AP从TM获取资源管理器的代理（例如：使用JTA接口，从TM管理的上下文中，获取出这个TM所管理的RM的JDBC连接或JMS连接）
2. AP向TM发起一个全局事务。这时，TM会通知各个RM。XID（全局事务ID）会通知到各个RM。
3. AP通过1中获取的连接，直接操作RM进行业务操作。这时，AP在每次操作时把XID(包括所属分支的信息)传递给RM，RM正是通过这个XID与2步中的XID关联来知道操作和事务的关系的。
4. AP结束全局事务。此时TM会通知RM全局事务结束。
5. 开始二段提交，也就是prepare - commit的过程。

XA协议

XA协议(XA Specification)，指的是TM和RM之间的接口。

事务管理器(Transaction Manager) TM

资源管理器(Resource Manager) RM

其实这个协议只是定义了xa_和ax_系列的函数原型以及功能描述、约束和实施规范等。至于RM和TM之间通过什么协议通信，则没有提及。原因是具体实现组件不同，可能通信协议也选择的不同。

XA接口是双向的系统接口。在事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。

2PC和DTP

2PC 是方案，思路

DTP是模型，TM和RM就是DTP的概念。DTP 是将所有资源抽象后的模型。

DTP和XA

DTP是模型，其中两个实体TM和RM交互的接口规范是XA。

JTA

JTA 是DTP模型的编程实现。可以被Spring集成。

Tuxedo

实现了DTP模型，术语中间件，即通过接口调研方式。

中间件（早期重量级Weblogic、Jboss、后期轻量级Atomikos、Narayana和Bitronix）

 为什么XA大家都不用

       一句话：懂得不用，不懂的不敢

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

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

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

实现案例：JTA+Atomikos

适用场景：在一个项目中操作多个数据库。

XA模式

XA是X/Open DTP组织（X/Open DTP group）定义的两阶段提交协议，XA被许多数据库（如Oracle、DB2、SQL Server、MySQL）和中间件等工具(如CICS 和 Tuxedo)本地支持 。
X/Open DTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）。

XA接口函数由数据库厂商提供。XA规范的基础是两阶段提交协议2PC。
JTA(Java Transaction API) 是Java实现的XA规范的增强版 接口。

在XA模式下，需要有一个[全局]协调器，每一个数据库事务完成后，进行第一阶段预提交，并通知协调器，把结果给协调器。协调器等所有分支事务操作完成、都预提交后，进行第二步；第二步：协调器通知每个数据库进行逐个commit/rollback。
其中，这个全局协调器就是XA模型中的TM角色，每个分支事务各自的数据库就是RM。

MySQL 提供的XA实现（https://dev.mysql.com/doc/refman/5.7/en/xa.html ）

XA模式下的 开源框架有atomikos，其开发公司也有商业版本。
XA模式缺点：事务粒度大。高并发下，系统可用性低。因此很少使用。

---

end