转载：https://yq.aliyun.com/articles/283392

1、什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2、分布式事务的产生的原因

2.1、数据库分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

image

2.2、应用SOA化

所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

image

以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！

3、事务的ACID特性

3.1、原子性（A）

所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。

3.2、一致性（C）

事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。

3.3、隔离性（I）

所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。

3.4、持久性（D）

所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

4、分布式事务的应用场景

4.1、支付

最经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的操作必然需要引入分布式事务。

4.2、在线下单

买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

5、常见的分布式事务解决方案

5.1、基于XA协议的两阶段提交

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

image

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

XA事务与MySQL

XA事务就是两阶段提交的一种实现方式

XA规范主要定义了事务管理器TM，和资源管理器RM之间的接口

根据2PC的规范，将一次事务分割成两个阶段

1. prepare阶段

TM向所有RM发送prepare指令，RM接受到指令后执行数据修改和日志记录等操作，然后返回 可以提交/不可提交 给TM

（按照我的理解应该类似于MySQL在开启一个事务之后，只差最后的COMMIT或者ROLLBACK的状态）

2. commit阶段

TM接受到所有RM的prepare结果

如果有RM返回是 不可提交 或者超时，那么向所有RM发送ROLLBACK命令

如果所有RM都返回可以提交，那么向所有RM发送COMMIT命令

XA的异常情况处理

MySQL与XA事务的关系有两种情况

1. 内部XA

在使用innodb作为存储引擎，并且开启binlog的情况下，MySQL同时维护了binlog日志与innodb的redo log

为了保证这两个日志的一致性，MySQL使用了XA事务，由于只在单机上工作，所以被称为内部XA

2. 外部XA

就是一般谈论的分布式事务了

MySQL支持XA START/END/PREPARE/COMMIT这些sql语句，通过使用这些命令，我们是可以完成分布式事务的

状态转移图如下

（我有点不能理解的是，为什么一定需要XA END这个语句，直接XA PREPARE不行吗）

在MySQL5.7.7之前，XA事务是有bug的

如果有一个XA事务处于PREPARE状态

1. 如果连接关闭，或者MySQL服务器正常退出，这个事务会被回滚（但是根据XA规范，这个事务应该被保留）

2. 如果MySQL服务器被强制结束，在重启之后，用XA RECOVER命令可以看到这个事务，这个事务也可以被XA COMMIT所提交，但是相关的binlog记录会丢失，这样就会导致数据库引擎中的数据与binlog中的数据不一致 （参考资料）

这两个bug被提出了十年之久，终于在5.7.7中被修正了（第一个bug阿里自己也搞了个修正）

就目前来看，MySQL的XA事务现在做得还不错，应该是可用的

还是有一些不能理解的地方

1. 官方文档中强调：在使用分布式事务的时候，需要使用串行隔离级别，为什么？

（As with nondistributed transactions, SERIALIZABLE may be preferred if your applications are sensitive to read phenomena. REPEATABLE READ may not be sufficient for distributed transactions.）

原因：为了尽可能提高分布式事物的隔离级别，如果分库上使用MySQL默认的RR，那么导致总的分布式事务的隔离级别为RU

参考资料

1. MySQL binlog 组提交与 XA(两阶段提交)

2. MySQL redolog与组提交 资料1 资料2 资料3 资料4

3. MySQL官方的XA文档

4. XA事务的隔离级别

普通事务

普通事务的实现是比较好理解的。以jdbm3为例，大概是这样的过程：

每个事务都新建一个事务文件，当commit时，先把修改过的数据块，写到事务文件里，然后再一次性地写到数据库文件里。

如果commit时挂掉了，那么重启之后，会再次从事务文件里把修改过的块写到数据库文件里。最后再删除事务文件。

https://github.com/jankotek/JDBM3

但是XA事务，即所谓的分布式事务却令人感到云里雾里。一是资料很少，网上的各种配置资料都是流于表面；二是可能实际应用的人也少。

最近研究了下，算是找到点门道了。

二阶段提交（Two-phase Commit）

首先，XA事务是基于二阶段提交（Two-phase Commit）实现的。二阶段提交本身并没有什么令人疑惑的地方。看wiki就可以知道是怎么回事了。

简而言之，有二种角色，事务管理者（DM, Transaction Manager），资源管理器（RM, Resource Manager），通常即数据库或者JMS服务器。

下面两个图片来自：http://www.infoq.com/cn/articles/xa-transactions-handle

[图片上传失败...(image-463692-1585407318380)]

出错回滚：

[图片上传失败...(image-da1992-1585407318380)]

当然，还有各种中间出错时，要处理的情况，详细可以看infoq的原文。

令人疑惑的atomikos

二阶段提交协议是很容易理解的，但是真正令我疑惑的是Java实现的atomikos，一个分布式事务的Transaction Manager组件。

开始的时候，我以为事务管理器(TM)都是独立的一个服务，或者一个独立的进程，它和资源管理器(RM)之间通过网络通迅。

但是在网上看一些atomikos配置文章，都没有提到如何配置一个独立的Transaction Manager，只是简单地介绍了下如何配置atomikos，这些配置都是和应用在一起的。

而从配置里面也没法看出是如何保证在事务过程中，如果应用的进程挂掉后，是如何恢复的。

再把atomikos的例子代码下载下来，发现也没有提到是如何保证事务在失败后，如何协调的。

比如，在第二段提交时，当RM1 commit完成了，而RM2 commit还没有完成，而这时TM，即配置了atomikos的应用程序崩溃，那么这个事务并没有完成，还需要TM重启后协调，才能最终完成这个事务。但是没看到恢复部分的配置。

没办法，只能亲自跑一遍代码了。

跑了下atomikos的代码，在第二阶段提交时，把进程杀掉，发现的确是可以自动处理回滚事务，或者再次提交的。那么信息是保存在哪里的？也没有看到有什么配置文件。

最终，只能下XA的规范下载下来，再一点点慢慢看。

在The XA Specification里的2.3小节：Transaction Completion and Recovery 明确提到TM是要记录日志的：

In Phase 2, the TM issues all RMs an actual request to commit or roll back the

transaction branch, as the case may be. (Before issuing requests to commit, the TM

stably records the fact that it decided to commit, as well as a list of all involved RMs.)

All RMs commit or roll back changes to shared resources and then return status to the

TM. The TM can then discard its knowledge of the global transaction.

TM是一定要把事务的信息，比如XID，哪个RM已经完成了等保存起来的。只有当全部的RM提交或者回滚完后，才能丢弃这些事务的信息。

于是再查看下atomikos例子运行目录，果然有一些文件日志文件：

127.0.1.1.tm13.epoch

tmlog13.log

tmlog.lck

tm.out

tm.out.lck

原来atomikos是通过在应用的目录下生成日志文件来保证，如果失败，在重启后可以通过日志来完成未完成的事务。

XA事务的假设条件

从XA的规范里找到了下面的说法：

The X/Open DTP model makes these assumptions:

TMs and RMs have access to stable storage TM和RM都有牢靠的存储

TMs coordinate and control recovery TM协调和控制恢复流程

RMs provide for their own restart and recovery of their own state. On request, an RM must give a TM a list of XIDs that the RM has prepared for commitment or has heuristically completed. RM在得启和恢复时，得回应TM的请求，返回一系列的XID，是prepared的，或者是已经启发式地完成了的

也就是说，XA事务都假定了TM和RM都是有牢靠的存储的，所以也保证了TM重启后可以从日志里恢复还没处理完的事务。

TM可以向RM查询事务的状态，RM必须要返回一系列事务的XID，表明事务是prepared状态，还是已经commit的状态。

到这里，应该很明了了，XA事务是其限制的，而TM是XA事务的一个单点，TM必须要非常地牢靠。

从XA的接口函数，就可以大概看出协议是怎么工作的（来自XA规范文档）：

[图片上传失败...(image-67987f-1585407318379)]

如何避免XA事务

XA事务的明显问题是timeout问题，比如当一个RM出问题了，那么整个事务只能处于等待状态。这样可以会连锁反应，导致整个系统都很慢，最终不可用。

避免使用XA事务的方法通常是最终一致性。

举个例子，比如用户充值300元，为了减少DB的压力，先把这个放到消息队列里，然后后端再从消息队列里取出消息，更新DB。

那么如何保证，这条消息不会被重复消费？或者重复消费后，仍能保证结果是正确的？

1. 在消息里带上用户帐号在数据库里的版本，在更新时比较数据的版本，如果相同则加上300；
2. 比如用户本来有500元，那么消息是更新用户的钱数为800，而不是加上300；
3. 另外建一个消息是否被消费的表，记录消息ID，在事务里，先判断消息是否已经消息过，如果没有，则更新数据库，加上300,否则说明已经消费过了，丢弃。

前面两种方法都必须从流程上保证是单方向的，不能插入其它的东东。

其它的一些东东：

貌似一直有人想用zookeeper来实现2pc，或者类似的东东，因为zookeeper是比较可靠的。但是感觉也没有办法解决timeout问题。

微软的XA事务恢复流程的文档：

http://msdn.microsoft.com/en-us/library/windows/desktop/ms681775(v=vs.85).aspx

There are two forms of XA transaction recovery, as follows:

• Cold recovery. Cold recovery performed if the transaction manager process fails while a connection to an XA resource manager is open. When the transaction manager restarts, it reads the transaction manager log file and re-establishes the connection to the XA resource manager by calling xa_open_entry. It then initiates XA recover by calling xa_recover_entry.
• Hot recovery. Hot recovery is performed if the transaction manager remains up while the connection between the transaction manager and the XA resource manager fails because the XA resource manager or the network fails. After the failure, the transaction manager periodically calls xa_open_entry to reconnect to the XA resource manager. When the connection is reestablished, the transaction manager initiates XA recovery by calling xa_recover_entry.

总结：

XA事务没有什么神秘的地方，二阶段提交也是一个人们很自然的一个处理方式。

只不过，这个是规范，如果有多个资源之间要协调，而且都支持XA事务，那么会比较方便 。

参考：

The XA Specification 可以从这里下载到：http://download.csdn.NET/detail/hengyunabc/6940529

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

http://www.infoq.com/cn/articles/xa-transactions-handle

http://java.sun.com/javaee/technologies/jta/index.jsp

https://github.com/bitronix/btm 一个开源的JTA Transaction Manager

XA接口详解

XA接口是双向的系统接口，分布式事务是由一个一个应用程序(Application Program)、一个事务管理器（Transaction Manager）以及一个或多个资源管理器（Resource Manager）之间形成通信桥梁。事务管理器控制着JTA事务，管理事务生命周期，并协调资源。

在JTA中，事务管理器抽象为javax.transaction.TransactionManager接口，并通过底层事务服务（即JTS）实现。资源管理器负责控制和管理实际资源(如数据库或JMS队列)。下图说明了事务管理器、资源管理器，以及典型JTA环境中客户端应用之间的关系：

image

XA分布式事务是由一个或者多个Resource Managerd，一个事务管理器Transaction Manager以及一个应用程序 Application Program组成。

• 资源管理器：提供访问事务资源的方法，通常一个数据库就是一个资源管理器。

• 事务管理器：协调参与全局事务中的各个事务。需要和参与全局事务中的资源管理器进行通信。

• 应用程序：定义事务的边界，指定全局事务中的操作。

XA使用场景

许多事务管理器采用这种单阶段提交的模式，可以避免单一事务资源下的过度开销，以及性能的下降，如果在不适合的场景中引入XA数据库驱动，特别是资源比较局限的情况下使用本地事务模型(Local Transaction Model)。

那究竟什么情况下使用XA事务呢？

一般来说，当你的上下逻辑结构涉及的表或者需要协调的资源(如数据库，以及消息主题或队列等)比较多的时候，建议使用XA。

或者对于该系统在未来对整个结构模块趋于稳定，要求负载、代码扩展等方面稳定性大于性能，则可选择XA。

如果这些资源并不在同一个事务中使用，就没有必要去用XA。

而对于性能要求很高的系统，建议使用 一阶段提交(Best Efforts 1PC)或事务补偿机制。

二阶段提交（The two-phase commit protocol，2PC）

二阶段提交是分布式事务的重要的一个关键点，二阶段提交协议包含了两个阶段：第一阶段（也称准备阶段）和第二阶段（也称提交阶段）。

image

引用《Java事务设计策略》一图

1. 准备阶段：准备阶段，每个资源管理器都会被轮训一遍，事务管理器给每个资源管理器发送Prepare消息，每个资源管理器要么直接返回失败(如权限验证失败)或异常，要么在本地执行事务等等，但不Commoit，处于Ready状态。

2. 提交阶段：如果事务管理器收到了资源管理器的失败信息(如异常、超时等)，直接给每个资源管理器发送回滚(Rollback)消息；否则，发送提交(Commit)消息；资源管理器根据事务管理器的指令执行Commit或者Rollback操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

可以看出，二阶段提交这么做的就是让前面都完成了准备工作，才能提交整个事务，若中间由某一环节出现问题，则整个事务回滚。

从两阶段提交的工作方式来看，很显然，在提交事务的过程中需要在多个节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，这样，比起一阶段提交，两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能就会严重下滑。

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

1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。

2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）

3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。

4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

参考资料
http://www.infoq.com/cn/articles/xa-transactions-handle
http://blog.csdn.net/bluishglc/article/details/7612811
http://www.open-open.com/lib/view/open1429863503010.html
http://hedengcheng.com/?p=136
http://www.hollischuang.com/archives/681

事务和两阶段提交,三阶段提交协议（有限状态自动机）

?1 事务的ACID

事务是保证数据库从一个一致性的状态永久地变成另外一个一致性状态的根本，其中，ACID是事务的基本特性。

A是Atomicity，原子性。一个事务往往涉及到许多的子操作，原子性则保证这些子操作要么都做，要么都不做，而不至于出现事务的部分操

作成功，而另外一部分操作没有成功。如果事务在执行的过程中发生错误，那么数据库将回滚到事务发生之前的状态。比如银行的转账服务

，这个事务的最终结果一定是：某个账户的余额增加了x，而另外一个账户的余额减少了x，或者两个账户的余额未发生变化。而不会出现其

他情况。

C是Consistency，一致性。一致性是指事务发生前和发生以后，都不会破坏数据库的约束关系，保证了数据库元素的正确性、有效性和完整

性。这种约束关系可以是数据库内部的约束，比如数据库元素的值必须在一定的范围内，也可以是应用带来的约束，比如转账以后银行账户

的余额不能为负数。

I是Isolation，隔离性。一个事务的操作在未提交以前，是不会被并行发生的其他事务访问到的。也就是说，数据库操作不会看到某个事务

的中间操作结果，比如转账过程中，用户是不能查询到一个账户余额减少了，而另外一个账户余额未发生变化的情况。

D是Durability，持久性。事务完成以后，它对数据库的影响是永久性的，即使在数据库系统发生宕机或者其他故障的情况下，这种影响也

会得到保持。
?2 两阶段提交
应用在分布式系统中。
在分布式系统中，事务往往包含有多个参与者的活动，单个参与者上的活动是能够保证原子性的，而多个参与者之间原子性的保证则需要通

过两阶段提交来实现，两阶段提交是分布式事务实现的关键。

很明显，两阶段提交保证了分布式事务的原子性，这些子事务要么都做，要么都不做。而数据库的一致性是由数据库的完整性约束实现的，

持久性则是通过commit日志来实现的，不是由两阶段提交来保证的。至于两阶段提交如何保证隔离性，可以参考Large-scale Incremental

Processing Using Distributed Transactions and Notifications中两阶段提交的具体实现。

两阶段提交的过程涉及到协调者和参与者。协调者可以看做成事务的发起者，同时也是事务的一个参与者。对于一个分布式事务来说，一个

事务是涉及到多个参与者的。具体的两阶段提交的过程如下：

第一阶段：

首先，协调者在自身节点的日志中写入一条的日志记录，然后所有参与者发送消息prepare T，询问这些参与者（包括自身），是否能够提

交这个事务；

参与者在接受到这个prepare T 消息以后，会根据自身的情况，进行事务的预处理，如果参与者能够提交该事务，则会将日志写入磁盘，并

返回给协调者一个ready T信息，同时自身进入预提交状态状态；如果不能提交该事务，则记录日志，并返回一个not commit T信息给协调

者，同时撤销在自身上所做的数据库改；

参与者能够推迟发送响应的时间，但最终还是需要发送的。

第二阶段：

协调者会收集所有参与者的意见，如果收到参与者发来的not commit T信息，则标识着该事务不能提交，协调者会将Abort T 记录到日志中

，并向所有参与者发送一个Abort T 信息，让所有参与者撤销在自身上所有的预操作；

如果协调者收到所有参与者发来prepare T信息，那么协调者会将Commit T日志写入磁盘，并向所有参与者发送一个Commit T信息，提交该

事务。若协调者迟迟未收到某个参与者发来的信息，则认为该参与者发送了一个VOTE_ABORT信息，从而取消该事务的执行。

参与者接收到协调者发来的Abort T信息以后，参与者会终止提交，并将Abort T 记录到日志中；如果参与者收到的是Commit T信息，则会

将事务进行提交，并写入记录

一般情况下，两阶段提交机制都能较好的运行，当在事务进行过程中，有参与者宕机时，他重启以后，可以通过询问其他参与者或者协调者

，从而知道这个事务到底提交了没有。当然，这一切的前提都是各个参与者在进行每一步操作时，都会事先写入日志。

唯一一个两阶段提交不能解决的困境是：当协调者在发出commit T消息后宕机了，而唯一收到这条命令的一个参与者也宕机了，这个时候这

个事务就处于一个未知的状态，没有人知道这个事务到底是提交了还是未提交，从而需要数据库管理员的介入，防止数据库进入一个不一致

的状态。当然，如果有一个前提是：所有节点或者网络的异常最终都会恢复，那么这个问题就不存在了，协调者和参与者最终会重启，其他

节点也最终也会收到commit T的信息。
?3 日志

数据库日志保证了事务执行的原子性和持久性，日志类型可以分为redo log，undo log，undo/redo log。关于这几种日志形式的具体介绍

，可以参照：

http://nosql-wiki.org/foswiki/bin/view/Main/TransactonLog

--------------------
两阶段提交协议（two phase commit protocol，2PC）可以保证数据的强一致性，许多分布式关系型数据管理系统采用此协议来完成分布式

事务。它是协调所有分布式原子事务参与者，并决定提交或取消（回滚）的分布式算法。同时也是解决一致性问题的一致性算法。该算法能

够解决很多的临时性系统故障（包括进程、网络节点、通信等故障），被广泛地使用。但是，它并不能够通过配置来解决所有的故障，在某

些情况下它还需要人为的参与才能解决问题。参与者为了能够从故障中恢复，它们都使用日志来记录协议的状态，虽然使用日志降低了性能

但是节点能够从故障中恢复。

在两阶段提交协议中，系统一般包含两类机器（或节点）：一类为协调者（coordinator），通常一个系统中只有一个；另一类为事务参与

者（participants，cohorts或workers），一般包含多个，在数据存储系统中可以理解为数据副本的个数。协议中假设每个节点都会记录写

前日志（write-ahead log）并持久性存储，即使节点发生故障日志也不会丢失。协议中同时假设节点不会发生永久性故障而且任意两个节

点都可以互相通信。

当事务的最后一步完成之后，协调器执行协议，参与者根据本地事务能够成功完成回复同意提交事务或者回滚事务。

顾名思义，两阶段提交协议由两个阶段组成。在正常的执行下，这两个阶段的执行过程如下所述：

阶段1：请求阶段（commit-request phase，或称表决阶段，voting phase）

在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（

事务参与者本地作业执行成功）或取消（本地作业执行故障）。

阶段2：提交阶段（commit phase）

在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提

交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。

注意 两阶段提交协议与两阶段锁协议不同，两阶段锁协议为一致性控制协议。

XA
XA是X/Open DTP组织（X/Open DTP group）定义的两阶段提交协议，XA被许多数据库（如Oracle和DB2）和中间件等工具(如CICS 和

Tuxedo).本地支持 。
X/Open DTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。在这个模型中，

通常事务管理器（TM）是交易中间件，资源管理器（RM）是数据库，通信资源管理器（CRM）是消息中间件。

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提

交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。

XA就是X/Open DTP定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、

回滚等。XA接口函数由数据库厂商提供。通常情况下，交易中间件与数据库通过XA 接口规范，使用两阶段提交来完成一个全局事务，XA规

范的基础是两阶段提交协议。

MySQL分布式XA事务

XA–eXtended Architecture 在事务中意为分布式事务

XA由协调者(coordinator，一般为transaction manager)和参与者(participants,一般在各个资源上有各自的resource manager)共同完成。在MySQL中，XA事务有两种。

内部XA事务
mysql本身的插件式架构导致在其内部需要使用XA事务，此时MySQL即是协调者，也是参与者。例如，不同的存储引擎之间是完全独立的，因此当一个事务涉及两个不同的存储引擎时，就必须使用内部XA事务。需要特别注意的是，如果将二进制日志看做一个独立的“存储引擎”,就不难理解为什么即使是一个存储引擎参与的事务也需要使用XA事务了。在向存储引擎提交数据时，同时需要将提交的信息写入二进制日志，这就是一个分布式事务。

下面的SQL就实现了一个简单的MySQL XA事务：

<pre>mysql> XA START 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO mytable (i) VALUES(10);
Query OK, 1 row affected (0.04 sec)

mysql> XA END 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> XA PREPARE 'xatest';
Query OK, 0 rows affected (0.00 sec)

mysql> XA COMMIT 'xatest';
Query OK, 0 rows affected (0.00 sec) </pre>

外部XA事务
MySQL也可以仅作为一个外部XA的参与者。例如在Java程序中实现一个操作多个异构数据库数据的分布式事务，则分工为：

Transaction Manager
javax.transaction.xa.XAResource, or Java::BitronixTm(aka “Transaction Coordinator”) 也就是程序本身

Resource Managers
MySQL, PostgreSQL, Oracle, Redis, MQueue, MongoDB, etc.(aka “cohorts”) 即各个数据库。也就是说只要是提供了相应接口的数据库产品就可以作为XA的参与者

Two-phase commit
XA一般由两阶段完成，称为two-phase commit(2PC)。
阶段一为准备阶段，即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager汇报自己已经准备好。
阶段二为提交阶段。当transaction manager确认所有参与者都ready后，向所有参与者发送commit命令。
如下图所示：
[图片上传失败...(image-dd3598-1585407318371)]

XA的性能问题
XA的性能很低。一个数据库的事务和多个数据库间的XA事务性能对比可发现，性能差10倍左右。因此要尽量避免XA事务，例如可以将数据写入本地，用高性能的消息系统分发数据。或使用数据库复制等技术。
只有在这些都无法实现，且性能不是瓶颈时才应该使用XA。

最后是MySQL的XA官方文档：
http://dev.mysql.com/doc/refman/5.7/en/xa.html

详解Mysql分布式事务XA（跨数据库事务）

在开发中，为了降低单点压力，通常会根据业务情况进行分表分库，将表分布在不同的库中（库可能分布在不同的机器上）。在这种场景下，事务的提交会变得相对复杂，因为多个节点（库）的存在，可能存在部分节点提交失败的情况，即事务的ACID特性需要在各个不同的数据库实例中保证。比如更新db1库的A表时，必须同步更新db2库的B表，两个更新形成一个事务，要么都成功，要么都失败。
那么我们如何利用mysql实现分布式数据库的事务呢？

Mysql 为我们提供了分布式事务解决方案（https://dev.mysql.com/doc/refman/5.7/en/xa.html 这是mysql5.7的文档）
这里先声明两个概念：

• 资源管理器（resource manager）：用来管理系统资源，是通向事务资源的途径。数据库就是一种资源管理器。资源管理还应该具有管理事务提交或回滚的能力。
• 事务管理器（transaction manager）：事务管理器是分布式事务的核心管理者。事务管理器与每个资源管理器（resource
  manager）进行通信，协调并完成事务的处理。事务的各个分支由唯一命名进行标识。

mysql在执行分布式事务（外部XA）的时候，mysql服务器相当于xa事务资源管理器，与mysql链接的客户端相当于事务管理器。

分布式事务原理：分段式提交

分布式事务通常采用2PC协议，全称Two Phase Commitment Protocol。该协议主要为了解决在分布式数据库场景下，所有节点间数据一致性的问题。分布式事务通过2PC协议将提交分成两个阶段：

• prepare；
• commit/rollback

阶段一为准备（prepare）阶段。即所有的参与者准备执行事务并锁住需要的资源。参与者ready时，向transaction manager报告已准备就绪。
阶段二为提交阶段（commit）。当transaction manager确认所有参与者都ready后，向所有参与者发送commit命令。
如下图所示：
[图片上传失败...(image-374a7-1585407318371)]

事务协调者transaction manager

因为XA 事务是基于两阶段提交协议的，所以需要有一个事务协调者（transaction manager）来保证所有的事务参与者都完成了准备工作(第一阶段)。如果事务协调者（transaction manager）收到所有参与者都准备好的消息，就会通知所有的事务都可以提交了（第二阶段）。MySQL 在这个XA事务中扮演的是参与者的角色，而不是事务协调者（transaction manager）。

Mysql的XA事务分为外部XA和内部XA

• 外部XA用于跨多MySQL实例的分布式事务，需要应用层作为协调者，通俗的说就是比如我们在PHP中写代码，那么PHP书写的逻辑就是协调者。应用层负责决定提交还是回滚，崩溃时的悬挂事务。MySQL数据库外部XA可以用在分布式数据库代理层，实现对MySQL数据库的分布式事务支持，例如开源的代理工具：网易的DDB，淘宝的TDDL等等。
• 内部XA事务用于同一实例下跨多引擎事务，由Binlog作为协调者，比如在一个存储引擎提交时，需要将提交信息写入二进制日志，这就是一个分布式内部XA事务，只不过二进制日志的参与者是MySQL本身。Binlog作为内部XA的协调者，在binlog中出现的内部xid，在crash recover时，由binlog负责提交。(这是因为，binlog不进行prepare，只进行commit，因此在binlog中出现的内部xid，一定能够保证其在底层各存储引擎中已经完成prepare)。

MySQL XA事务基本语法

XA {START|BEGIN} xid [JOIN|RESUME] 启动xid事务 (xid 必须是一个唯一值; 不支持[JOIN|RESUME]子句)
XA END xid [SUSPEND [FOR MIGRATE]] 结束xid事务 ( 不支持[SUSPEND [FOR MIGRATE]] 子句)
XA PREPARE xid 准备、预提交xid事务
XA COMMIT xid [ONE PHASE] 提交xid事务
XA ROLLBACK xid 回滚xid事务
XA RECOVER 查看处于PREPARE 阶段的所有事务

PHP调用MYSQL XA事务示例

1、首先要确保mysql开启XA事务支持

<pre class="prettyprint">SHOW VARIABLES LIKE '%xa%'</pre>

如果innodb_support_xa的值是ON就说明mysql已经开启对XA事务的支持了。 
如果不是就执行：

<pre class="prettyprint">SET innodb_support_xa = ON</pre>

开启

2、代码如下：

<pre class="prettyprint"><!--?PHP $dbtest1 = new mysqli("172.20.101.17","public","public","dbtest1")or die("dbtest1 连接失败"); $dbtest2 = new mysqli("172.20.101.18","public","public","dbtest2")or die("dbtest2 连接失败"); //为XA事务指定一个id，xid 必须是一个唯一值。 $xid = uniqid(""); //两个库指定同一个事务id，表明这两个库的操作处于同一事务中 $dbtest1->query("XA START '$xid'");//准备事务1 $dbtest2->query("XA START '$xid'");//准备事务2 try { //$dbtest1 $return = $dbtest1->query("UPDATE member SET name='唐大麦' WHERE id=1") ; if($return == false) {
       throw new Exception("库dbtest1@172.20.101.17执行update member操作失败！");
    } //$dbtest2 $return = $dbtest2->query("UPDATE memberpoints SET point=point+10 WHERE memberid=1") ; if($return == false) {
       throw new Exception("库dbtest1@172.20.101.18执行update memberpoints操作失败！");
    } //阶段1：$dbtest1提交准备就绪 $dbtest1->query("XA END '$xid'"); $dbtest1->query("XA PREPARE '$xid'"); //阶段1：$dbtest2提交准备就绪 $dbtest2->query("XA END '$xid'"); $dbtest2->query("XA PREPARE '$xid'"); //阶段2：提交两个库 $dbtest1->query("XA COMMIT '$xid'"); $dbtest2->query("XA COMMIT '$xid'");
} 
catch (Exception $e) { //阶段2：回滚 $dbtest1->query("XA ROLLBACK '$xid'"); $dbtest2->query("XA ROLLBACK '$xid'");
    die($e->getMessage());
} $dbtest1->close(); $dbtest2->close(); ?></pre>

XA的性能问题

XA的性能很低。一个数据库的事务和多个数据库间的XA事务性能对比可发现，性能差10倍左右。因此要尽量避免XA事务，例如可以将数据写入本地，用高性能的消息系统分发数据。或使用数据库复制等技术。只有在这些都无法实现，且性能不是瓶颈时才应该使用XA。