（二）分布式事务

关注

原创最新推荐文章于 2026-09-18 10:14:14 发布 455 阅读 AI 写同款· GEO 优化 ›

从二将军问题开始，把分布式事务的分类与应用场景一次讲清前言不知不觉距离上一篇的更新已经有好几天了，后台也有很多小伙伴催更，奈何事情比较多，期望我能坚持下去～最近几篇我们聊一聊分布式事务。二将军问题我们先来看个故事，相信会有助于你对分布式事务的理解。二将军问题是一个计算机领域一个经典的问题。「故事背景」黑白两军交战之际，两股白军将黑军被围困在山谷之中；山谷两侧任意一股白军都比山谷中的黑军人数少，因此单独一只白军向黑军发起进攻，必败无疑，但是两股白军人数总和却比黑军人数多，若能同时向黑军发起进攻，则可大胜。而山谷左右侧的白军相互通信（告知进攻时间）阅读详情

分布式事务

分布式事务（Distributed Transaction Processing，DTP）是指在分布式环境下，操作多个数据库的事务。

XA规范

XA是由X/Open组织提出的分布式事务的规范。
X/Open DTP 模型（ 1994 ）包括应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。
XA是RM和TM的交互规范和接口定义。
XA协议采用两阶段提交方式（2PC）来管理分布式事务。

在这里插入图片描述

AP：这个角色要做两件事情，一方面是定义构成整个事务所需要的所有操作，另一方面是亲自访问资源节点来执行操作。
RM：这个角色是管理着某些共享资源的自治域，比如说一个MySQL数据库实例。在DTP里面，还有两个要求，一是RM自身必须是支持事务的，二是RM能够根据将全局（分布式）事务标识定位到自己内部对应的事务。
TM：这个角色能与AP和RM直接通信，协调AP和RM来实现分布式事务的完整性。主要的工作是提供AP注册全局事务的接口，颁发全局事务标识（GTID之类的），存储/管理全局事务的内容和决策并指挥RM做commit/rollback。

MySQL

XA语法

XA {START|BEGIN} xid：启动一个XA事务 (xid 必须是一个唯一值)
XA END xid：结束一个XA事务
XA PREPARE xid：准备
XA COMMIT xid：提交XA事务
XA ROLLBACK xid：回滚XA事务
XA RECOVER：查看处于PREPARE 阶段的所有XA事务

使用案例

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

mysql> INSERT INTO test (name,tel) VALUES ('123','123');
Query OK, 1 row affected (0.00 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)

Spring Boot XA实现

https://blog.youkuaiyun.com/ACMer_AK/article/details/78742148

2PC

两阶段提交（2PC：two-phase commit protocol）是一个非常经典的强一致、中心化的原子提交协议。中心化是指协议中存在两类节点：一是中心化协调者节点（coordinator），二是N个参与者节点（partcipant）

准备阶段

Coordinator发送Prepare请求给所有的Partcipant，每一个Partcipant会根据自身执行结果返回成功/失败。

提交阶段

若所有的Partcipant返回成功，则Coordinator发送Commit请求给所有的Partcipant，那么Partcipant就会提交事务并释放资源
若存在一个Partcipant返回失败/超时，则Coordinator发送Rollback请求给所有的Partcipant，那么Partcipant就会回滚事务并释放资源

缺点

性能：可以看到在事务执行过程中，所有Partcipant都是被阻塞的，如果整个事务时间很长，则对性能影响很大
协调者单点故障：若Coordinator发生故障，Partcipant会被阻塞，事务会处于一个中间状态，即使重新选举新的Coordinator，也无法解决Partcipant阻塞问题
数据不一致：在提交阶段中，若出现网络问题，导致部分Partcipant接受不到提交消息，则会导致数据不一致

3PC

三阶段提交协议（3PC：three-phase commit protocol），是2PC的改进版本，增加了超时机制以及CanCommit阶段

超时机制：3PC对于Coordinator和Partcipant都设置了超时时间，而2PC只有Coordinator具有超时机制，解决了Partcipant和Coordinator无法通讯时，Partcipant可释放资源，降低了阻塞时长和范围
CanCommit阶段：多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的

CanCommit阶段

Coordinator发送CanCommit请求给所有的Partcipant询问是否可以执行事务提交操作，Partcipant若认为可顺利执行，则返回YES，并进入PreCommit阶段，否则返回NO

PreCommit阶段

若Partcipant全部返回YES，Coordinator发送PreCommit请求，并进入Prepared阶段，而Partcipant接受到PreCommit请求后，则会开始执行事务操作（未提交状态），并返回结果
若存在Partcipant返回NO/超时，Coordinator执行事务中断，Coordinator就会向Partcipant发送abort请求。

DoCommit阶段

若Partcipant全部返回YES，Coordinator发送DoCommit请求，Partcipant接受到DoCommit请求后，则提交事务。如果Partcipant无法及时接收到Coordinator的doCommit或者rebort请求时，会在等待超时之后，继续进行事务的提交。
若存在Partcipant返回NO/超时，Coordinator就会向Partcipant发送abort请求并中断事务

缺点

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