分布式事务的“婚礼总导演”——XA协议原理与落地实践

CH-23-05-015·约 19 分钟·分布式系统与高并发设计·更新 2026-08-12

想象你正在筹备一场盛大的婚礼晚宴。你需要婚庆公司布置场地、酒店准备餐点、乐队调试音响，这三方各自独立，但必须全部成功才能让晚宴完美开场。如果场地布置好了、餐点也备齐了，唯独乐队出了岔子，整个晚宴就砸了——你总不能只让宾客在空荡荡的场地上吃冷餐吧？这就是分布式事务的核心困境：多个独立的系统（如数据库）协同完成一个业务动作，要么全部成功，要么全部失败。XA协议就是那位“婚礼总导演”，它用一套“两阶段提交”的指挥流程，确保各方资源管理器整齐划一地行动。本文将带你认识这位总导演的工作方式、它在MySQL中的落地配置、常见的“演出事故”（性能瓶颈与死锁）以及如何避免它们。

岗位关联

对于后端工程师而言，理解XA协议意味着你掌握了跨数据库数据一致性的“最后一道保险”。当单体应用拆分微服务、单库拆分为分库分表后，XA仍是保底方案选型中绕不开的基石。

可视化演示
事务演进背景
XA总体架构
两阶段提交流程
MySQL实现
性能瓶颈
死锁排查
方案选型落地
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示XA协议两阶段提交(2PC)与三阶段提交(3PC)流程，及五种分布式事务方案对比。

本节配有交互动效（进入视口后自动加载，约 3KB）。

两阶段提交(2PC)：Prepare→Commit/Rollback Phase1: TM向所有RM发送Prepare，RM投票Yes/No Phase2: 全部Yes则Commit，任一No则Rollback Commit⟺∀RM.vote=Yes 2PC保证原子性但存在协调者单点阻塞问题

事务演进背景

在还没有分布式事务的年代，一个业务操作只需操作一个数据库。好比一个小餐馆，厨师一人身兼采购、切菜、炒菜数职，食材在自己一亩三分地里流转，全部环节由一人掌控，自然不会出现“菜炒好了但盘子没准备好”的乌龙。数据库的本地事务（ACID）同样如此：要么全部写入成功，要么全部回滚，由数据库自己保障。

后来，餐馆做大成了连锁集团，每个分店负责不同的菜系，但一道婚宴大菜需要多个分店协作完成——订单在订单中心，库存还在仓储中心，支付则要走财务中心。三个系统各自独立，彼此通过网络通信。此时再靠一个数据库的本地事务，已经无能为力，因为根本没有一个“总数据库”能同时锁住三处的数据。

于是，“分布式事务”这个词登上舞台。它的目标是让分布在不同数据库上的多个操作，仍然保持原子性、一致性、隔离性和持久性。问题是：谁来协调？怎么协调？——这就是 XA 协议要回答的问题。XA 是 X/Open 组织定义的分布式事务处理标准，它规定了事务管理器（TM）与资源管理器（RM）之间的接口，为跨数据库的事务协调提供了统一的“指挥语言”。理解了它的设计动机，也就理解了后续所有概念为何存在。

XA总体架构

让我们回到那场婚礼：你是总导演（事务管理器 TM），婚庆公司、酒店餐饮、乐队演出分别是三位分包商（资源管理器 RM），各自管理自己的“本地资源”（场地、食材、乐器）。AP（Application Program）则是你的助理，负责传达你的指令给各位分包商。

在这个架构中，TM 是全局事务的决策中心，拥有最高权力。它负责向 RM 发送指令、收集反馈、最终拍板是“如约举行”还是“全部取消”。RM 是实际干活的角色，管理各自的资源并执行真正的数据读写；它同时要具备“可提交”与“可回滚”的能力——就像分包商既要会布置场地，也要能随时撤掉布置恢复原状。

AP 是发起事务的应用，它需要 TM 的控制与 RM 的协作来共同完成一个完整的业务动作。三者通过标准接口通信：xa_start、xa_end、xa_prepare、xa_commit、xa_rollback 等。这套接口把“谁能做什么”定义得清清楚楚，如同一份严密的演出合同。

这种架构的价值在于标准化。任何支持 XA 规范的数据库（Oracle、MySQL、PostgreSQL 等）都能作为 RM 接入统一的 TM，无需为每家数据库定制协议。这就像你雇了十家供应商，只要都按同一份合同模板签署，总导演就能统一调度。

两阶段提交流程

XA 协议最核心的机制就是“两阶段提交”（2PC）。它把全局事务拆成两个阶段：准备阶段（Prepare Phase）与提交阶段（Commit Phase）。这是总导演确保“万事俱备才开席”的智慧所在。

阶段一：准备阶段。 TM 向所有 RM 发送 prepare 指令，询问“你能否完成自己的本地事务？”每个 RM 收到后，开始执行本地事务的写操作，但先不提交，只将事务状态记录为“预提交”。随后 RM 向 TM 回复“OK“或”不 OK”。如果有任何一个 RM 回复失败或超时未答复，TM 就决定全局回滚。

阶段二：提交阶段。如果所有 RM 都回复 OK，TM 再向所有 RM 发送 commit 指令。每个 RM 在本地真正提交事务，释放锁，然后向 TM 确认完成。若 TM 未能收到某个 RM 的确认，它会启动异常处理流程，通过日志恢复机制让 RM 重试提交。

这就像婚礼的“彩排-实施”机制：先让每方演练一遍并回复“我已就绪”，总导演确认全员到齐后，再下令正式开场。如果有人临时缺席，则果断取消，避免浪费投入的资源。

两阶段提交的关键在于“先投票后执行”的顺序保证了全局原子性：在准备阶段没有做出任何不可逆的提交动作，所以回滚可以安全执行；而一旦所有参与者承诺可提交，全局提交就不可逆。

这个“全体同意才执行”的逻辑，在分布式系统中被称为“投票-提交”模型，是实现原子性的基础。生活里的“全票通过才动工”的业主委员会决策，与之异曲同工。

\text{全局决策} = \begin{cases} \text{Commit}, & \text{若 } \forall \ RM_i \ \text{回复 } OK \\ \text{Rollback}, & \text{若 } \exists \ RM_i \ \text{回复 } No \text{ 或超时} \end{cases}

这个公式的含义是：只有当所有资源管理器都“举手同意”时，全局事务才提交；只要有一方“投反对票”或迟迟不回应，整个事务就回滚。

遍历所有 RM事务管理器向每个资源管理器发送 prepare 指令，逐个收集反馈。
$\forall \ RM_i$
判定条件一——全票通过如果所有 RM 都返回成功，则全局事务进入提交阶段。
$\text{if } RM_i = OK, \forall i$
判定条件二——存在反对只要有一个 RM 返回失败或超时，则全局事务回滚。
$\exists \ RM_i = No$
阶段划分第一阶段的“同意”并非真正提交，只是承诺；第二阶段的“提交”才是不可逆的执行。
$Prepare \rightarrow Commit \ (\text{不可逆})$

MySQL实现

MySQL 从 5.0 版本开始就内置了对 XA 的支持，它扮演资源管理器的角色，通过 SQL 语句暴露 XA 接口。这是总导演与分包商之间的“合同文本”——语法固定、含义明确。

XA 的 SQL 接口包含几个关键语句：XA START xid 开启一个分支事务；XA END xid 标记该事务的操作完成；XA PREPARE xid 进入预提交状态；XA COMMIT xid 正式提交；XA ROLLBACK xid 回滚。此外，XA RECOVER 用于查询当前未提交的 XA 事务列表，在故障恢复时非常重要。

从配置角度来看，MySQL 的 InnoDB 引擎天然支持 XA 事务，无需额外打开开关。但若要全局事务在 MySQL 中高效运行，需要关注几个参数：innodb_lock_wait_timeout（默认 50 秒）控制等待锁的超时时间；max_binlog_cache_size 决定大事务的 binlog 缓存上限；binlog_format=ROW 建议配合 XA 使用以保证与存储引擎的一致性。

MySQL 的 XA 实现还涉及 binlog 与 InnoDB 的协调：当一条 XA 事务执行 prepare 后，MySQL 会在 binlog 中写入一条特殊记录；如果此时客户端断开或服务器崩溃，MySQL 重启后可根据 binlog 与 InnoDB 的 redo log 判断事务状态，决定是提交还是回滚。这条“恢复红线”确保了 RM 层面的不丢不重。

实际开发中，你通常不需要手动执行这些 SQL——分布式事务中间件（如 Seata 管理的 XA 模式）会代为生成并执行。但理解这组状态转换，能帮你在 XA RECOVER 看到异常悬空事务时，知道如何排查。

\text{XA 事务状态} = \begin{cases} \text{ACTIVE}, & \text{XA START 后} \\ \text{IDLE}, & \text{XA END 后} \\ \text{PREPARED}, & \text{XA PREPARE 后} \end{cases}

事务像一条流水线上的工件，经过“开工→完工→预检”三个状态，之后要么进入成品库（提交），要么被丢弃（回滚）。

XA START开启一个分支事务，类似分配一个专属工作台给分包商。
$ACTIVE \xleftarrow{\text{XA START}} init$
XA END业务操作完成，告知“我这边活儿干完了”。
$IDLE \xleftarrow{\text{XA END}} ACTIVE$
XA PREPARE进入预提交，锁定资源但不落库，等待全局决策。
$PREPARED \xleftarrow{\text{XA PREPARE}} IDLE$
XA COMMIT / ROLLBACK根据全局决策，提交或撤销事务，释放资源。
$PREPARED \rightarrow^{COMMIT / ROLLBACK} \text{终态}$

性能瓶颈

XA 协议用简单的两阶段换来了强一致性，但它并非免费午餐。总导演的调度方式决定了它存在固有的性能代价。

代价一：准备阶段的同步等待延迟。在 prepare 阶段，TM 必须等待最慢的那个 RM 回复。如果一个 RM 网络延迟 1 秒，整个事务的响应时间就被拉长到 1 秒以上。这就像总导演要等最拖拉的分包商确认到场才能继续，其他越快的人也无济于事。

代价二：锁持有时间过长。 RM 在 prepare 阶段写完数据后，并不会立即释放锁，而是等到全局 commit/rollback 指令下达后才释放。这就意味着“锁->等->交”的时间窗口被拉长。在高并发场景下，锁冲突概率显著上升，整体吞吐量下降。这是 XA 事务最受诟病的点。

代价三：TM 单点故障风险。如果 TM 在准备阶段完成后崩溃，所有 RM 会一直持有锁等待 TM 恢复。若 TM 无法恢复，RM 只能依赖超时机制自行回滚，但超时时间的设置又需要慎重考虑。

我们可以用公式概括锁持有时间：

理解这三个时间分量，是调优 XA 事务性能的切入点。缩短 prepare 时间、优化网络 RTT、减少锁粒度，都能直接改善吞吐。

T_{lock} = T_{prepare} + T_{decision} + T_{commit}

锁持有总时间等于三个阶段耗时之和：准备、决策、提交。任何一环变慢都会放大锁竞争。

准备耗时RM 完成本地事务并回复 OK 所需的时间。
$T_{prepare} = Max(T_{rm1}, T_{rm2}, \dots)$
决策耗时TM 收集所有反馈并做出全局决策所需的时间。
$T_{decision} = T_{collect} + T_{judge}$
提交耗时RM 收到提交指令后真正落库的时间。
$T_{commit} = T_{write} + T_{ack}$

死锁排查

在分布式事务场景中，死锁发生的条件与单库类似，但范围更广：两个全局事务 A 和 B，各自持有部分资源锁并等待对方持有的锁，形成循环等待。总导演的两个分包商互相掐着对方的道具不松手，谁也等不到谁。

MySQL 检测 XA 死锁主要有两种途径。第一是 InnoDB 自带的死锁检测机制，会定期检测等待图，发现死锁时主动回滚一个代价较小的事务（打印 deadlock found 错误）。第二是锁等待超时：当 innodb_lock_wait_timeout 超时后，事务自动回滚并报错。两种机制都能打破死锁，但都需要时间，期间事务会一直阻塞。

排查死锁的标准动作是看错误日志与执行 SHOW ENGINE INNODB STATUS，其中会列出最近一次死锁涉及的事务、持有锁和等待锁的详细信息。将这些信息与 SQL 文本对照，就能分析出循环等待的链路。

在生产中，减少死锁的关键是让所有全局事务以相同顺序访问资源，并尽量缩短锁持有时间。这样会极大降低形成等待环的概率。

Deadlock \iff \exists \text{ 事务环 } T_1 \rightarrow T_2 \rightarrow \dots \rightarrow T_1

死锁本质是“谁都等对方先放手”的僵局：事务环上每个节点都在等待下一个节点释放锁。MySQL 通过回滚其中一个事务来打破僵局。

环的存在性死锁必然对应一个等待环，如 T1 等 T2 的资源，T2 又等 T1 的资源。
$T_1 \rightarrow T_2 \rightarrow T_1$
等待与持有每个事务在等待别人资源的同时，持有自己资源，构成互相牵制。
$Hold(\text{资源}_A) \wedge Wait(\text{资源}_B)$
打破僵局选择环中代价最小的事务回滚，释放锁，让其他事务继续。
$Rollback(T_{cost\text{-}min}) \Rightarrow \text{环消失}$

方案选型落地

讲到这里，你可能会问：既然 XA 有这么多限制，那它到底适不适合生产环境？答案是：适合，但要看场景。

适用场景包括：事务涉及的库数量少（2-3 个）；一致性要求极高（资金交易、订单履约）；并发量不是极高（每秒几十到几百笔）。在这些场景下，XA 的优势是“简单可靠”——与 Seata AT、TCC 等方案相比，它不需要侵入业务代码实现补偿逻辑，数据库原生支持，出错率低。

替代方案各有取舍：TCC 通过 Try-Confirm-Cancel 三阶段提供更高灵活性，但需要业务方自己实现幂等与补偿逻辑；本地消息表与 MQ 的事务消息则偏向最终一致性，适合延迟容忍较高的场景。如果追求最终一致且不想写太多补偿代码，可以考虑 Seata 的 AT 模式（基于 undo 日志自动回滚）。

生产落地建议遵循几条原则：一是尽量把锁时间压到最短，比如在 prepare 前就完成所有耗时的网络调用；二是为 TM 配置高可用（如基于 ZooKeeper 选主）；三是设置合理的超时与重试策略，避免“永远等待”。

最终，方案选择的核心变量是：一致性等级 vs 可用性 vs 性能。XA 站在“强一致”的一端，适合用它来承载核心链路；把边缘化、非关键的数据同步交给更灵活的方案。

AI 应用场景

场景一：基于 Seata XA 模式的微服务订单系统

阶段：方案选型与架构设计

解决的问题：在微服务拆分后，一个订单创建涉及订单库、库存库、账户库三个独立数据库。传统本地事务无法跨库保证一致性，而手写分布式事务代码容易出错。通过 Seata 提供的 XA 模式，只需在代码中开启全局事务注解，Seata 会自动代你执行 XA 的 prepare/commit/rollback 流程，业务代码几乎无侵入。

具体案例：你正负责将单体订单系统拆分为微服务。业务要求“下单后库存扣减与余额扣减必须同时成功”。将 Seata 的 XA 模式接入后，订单服务的 @GlobalTransactional 注解会开启全局事务，库存服务与账户服务的本地事务自动注册为 RM，由 Seata Server（TM）统一协调两阶段提交。用户支付失败时，全局回滚让之前扣减的库存自动恢复。

场景二：MySQL 原生 XA 在两库同步场景中的应用

阶段：数据层开发与运维

解决的问题：核心业务同时写入主库与统计库，必须保证两库不出现数据不一致。通过 MySQL 原生 XA 接口，在同一应用内程序化地协调两个数据源。

具体案例：一个交易系统需要把订单数据同时写入在线交易库与数据分析库。两个库都在 MySQL 上，通过 Spring 的 JtaTransactionManager 配置两个数据源并开启 XA，代码中一次事务可同时操作两个库。任一库写入失败，全局事务自动回滚另一库，从根源上杜绝跨库脏数据。XA RECOVER 命令可在异常后快速定位悬空事务并人工裁决。

场景三：XA 与 AI 数据管道的一致性保障

阶段：数据集成与训练样本管理

解决的问题：AI 训练样本的标注结果通常存储在业务库与特征库两份数据中，两者必须同步更新；否则模型训练会用到不一致的特征，导致训练效果劣化。通过 XA 保证双库写入的一致性。

具体案例：某推荐系统团队在数据标注平台中，将标注结果同时写入 MySQL 的标注库与 Redis 缓存（通过 XA 对 Redis 的模拟支持或改写到 MySQL 特征库）。每次标注更新，XA 事务确保两份数据的更新要么同时成功，要么同时回滚，从而让下游训练的模型特征始终保持一致版本。

Python 演示

python77 行

"""XA 两阶段提交的简化模拟器模拟事务管理器(TM)与3个资源管理器(RM)的协调过程"""import timeimport random  class ResourceManager:    """模拟一个资源管理器"""     def __init__(self, name, fail_rate=0.0):        self.name = name        self.fail_rate = fail_rate        self.state = "IDLE"  # IDLE / PREPARED / COMMITTED / ROLLEDBACK     def prepare(self):        time.sleep(0.05)        if random.random() < self.fail_rate:            print(f"[{self.name}] 准备失败，将投反对票")            return False        self.state = "PREPARED"        print(f"[{self.name}] 已准备，回复 OK")        return True     def commit(self):        self.state = "COMMITTED"        print(f"[{self.name}] 已提交 COMMIT")     def rollback(self):        self.state = "ROLLEDBACK"        print(f"[{self.name}] 已回滚 ROLLBACK")  class TransactionManager:    """模拟事务管理器"""     def __init__(self, rms):        self.rms = rms     def run_global_transaction(self):        print("=== 阶段一：准备阶段 ===")        all_ok = True        for rm in self.rms:            if not rm.prepare():                all_ok = False                break         print("=== 阶段二：执行决定 ===")        if all_ok:            print(">>> 全局决策：COMMIT")            for rm in self.rms:                rm.commit()        else:            print(">>> 全局决策：ROLLBACK")            for rm in self.rms:                rm.rollback()  if __name__ == "__main__":    # 3 个 RM 全部正常的情况    print("---------- 场景1：全员正常 ----------")    rms = [        ResourceManager("RM-A"),        ResourceManager("RM-B"),        ResourceManager("RM-C"),    ]    TransactionManager(rms).run_global_transaction()     # RM-B 有 30% 概率失败的情况    print("\n---------- 场景2：RM-B 可能失败 ----------")    rms = [        ResourceManager("RM-A"),        ResourceManager("RM-B", fail_rate=0.3),        ResourceManager("RM-C"),    ]    TransactionManager(rms).run_global_transaction()

目的：用 Python 对象模拟 XA 两阶段提交的协调逻辑。ResourceManager 对应数据库资源管理器，TransactionManager 对应事务管理器，运行代码可观察不同故障模式下全局事务走向提交或回滚。

class ResourceManager表示一个数据库资源管理器，维护自己的状态与 prepare/commit/rollback 行为。
self.state = "IDLE"初始状态为待命，记录 RM 当前处于哪个事务阶段。
def prepare(self)模拟 XA PREPARE，随机决定是否投反对票，返回是否成功。
if random.random() < self.fail_rate以设定的概率模拟数据库故障，用于观察回滚路径。
self.state = "PREPARED"事务进入预提交状态，绑定资源但并未落库。
def commit(self)模拟 XA COMMIT，真正落库并释放资源。
def rollback(self)模拟 XA ROLLBACK，撤销本地操作并释放锁。
class TransactionManager模拟事务管理器，负责收集 RM 投票并决策。
def run_global_transaction(self)完成两阶段提交的主流程。
for rm in self.rms遍历所有 RM，逐一调用 prepare，模拟“全体投票”。
if not rm.prepare(): all_ok = False任何一个 RM 失败，全局决策定为回滚。
rm.commit()` / `rm.rollback()根据全局决策统一执行提交或回滚。

常见误区

误区听说两阶段提交就是让多个数据库“同时”提交，各库在同一时刻完成写入，这样就能保证一致性。

正解两阶段提交不是物理上的同时动作，而是逻辑上的“全票通过后依次完成提交”。各 RM 收到 commit 指令后是各自独立落库的，先后可能有毫秒级差异。但由于 prepare 阶段已经保证每个 RM 都能成功提交，所以这个先后差异不会导致“一部分成功一部分失败”，最终一致性得以保证。

为何常见：从“两阶段”的字面意思与总导演“统一指挥”的直觉出发，容易让人想象成“按一下按钮全部同时完成”。

误区网上都说 XA 性能差、锁时间长，那生产环境就完全不考虑它，直接用消息队列实现最终一致性。

正解XA 的“性能差”是相对无事务方案或 TCC 而言的。在事务量不大、库数量可控（2-4 个）、网络延迟低的场景，XA 的强一致保障价值远超性能损失。很多银行、电商的核心交易链路仍然采用 XA。关键在于按业务场景评估——若每笔交易都要求即时强一致，XA 是最稳妥的选择。

为何常见：大量技术博客强调 XA 在高并发下的劣势，却忽略了它的可靠性和零侵入优势，导致“一刀切”的看法。

误区只要用了 XA 两阶段提交，就一定不会出现数据不一致，它一劳永逸地解决了分布式事务的所有问题。

正解两阶段提交在设计上可以处理 RM 正常回复的场景，但在极端情况下仍有“脑裂”风险：当 TM 在 prepare 后发出 commit 指令，但某个 RM 因网络分区没收到，且 TM 已无法重试时，该 RM 会一直处于 PREPARED 状态，与已提交的 RM 数据不一致。这时需要人工运维介入，通过 XA RECOVER 与 XA COMMIT 手工补齐。XA 降低了一致性风险，但不能做到零风险。

为何常见：对“两阶段”的信任超过了对故障模型的理解，忽略了网络分区与分布式系统的不确定性。

面试题

Q1. XA 协议中，最终决定全局事务提交或回滚的组件是？

单选题 · easy

A.应用系统 AP
B.事务管理器 TM← 正确答案
C.资源管理器 RM
D.网络中间件

答案：B。TM 是全局事务的决策中心，负责收集 RM 的投票并做出最终提交/回滚决策。AP 只是发起方，RM 只是执行方，网络中间件不参与决策。总导演（TM）才有权说“开场”或“取消”。

Q2. XA 两阶段提交的第一步是？

单选题 · easy

A.直接提交所有分支事务
B.事务管理器向所有资源管理器发送准备指令← 正确答案
C.应用向事务管理器提交数据
D.资源管理器自动回滚未完成事务

答案：B。两阶段提交第一阶段 prepare 由 TM 向所有 RM 发送准备指令，RM 执行本地事务但先不提交，回复是否就绪。选项 A 是第二阶段；选项 C 是事务发起；选项 D 是异常处理，均不符合第一阶段语义。

Q3. 在 MySQL 中，用于查询当前未完成 XA 事务的语句是？

单选题 · easy

A.SHOW XA STATUS
B.XA RECOVER← 正确答案
C.SHOW PROCESSLIST
D.XA CHECK

答案：B。XA RECOVER 是 MySQL 提供的标准命令，用于列出当前处于 PREPARED 状态、未完成提交或回滚的 XA 事务。排查悬空 XA 事务时，这就是你最先要执行的语句。

Q4. 关于 XA 两阶段提交的锁释放时机，以下说法正确的是？

单选题 · mid

A.RM 在执行本地事务写入后立即释放锁
B.RM 在 prepare 后释放锁，无需等待全局决策
C.RM 在收到全局 commit 或 rollback 指令后才释放锁← 正确答案
D.TM 在收到 prepare 反馈后立即释放所有锁

答案：C。RM 在 prepare 后保持锁不释放，直到收到 TM 的 commit/rollback 指令。这是 XA 锁持有时间长的根源，也是高并发下性能瓶颈的核心原因。其余选项描述的释放时机均不符合两阶段提交规范。

Q5. XA 事务在 RM 收到 commit 指令但网络异常未能执行时，最终如何恢复？

单选题 · mid

A.RM 自动回滚，保证数据安全
B.TM 重发 commit 直到 RM 完成确认← 正确答案
C.RM 根据自身日志强制提交
D.丢弃该事务并记录错误

答案：B。当 RM 在 PREPARED 状态未收到 commit 或网络中断时，TM 通常有重试机制会重新发送 commit 直到 RM 确认完成。若 TM 已不可用，则需人工通过 XA RECOVER 定位并 XA COMMIT 补齐。选项 A 是回滚，C/D 违反了 XA 的原子性保证。

Q6. 以下哪种情况会导致 XA 全局事务回滚？

单选题 · mid

A.一个 RM 回复 prepare 成功
B.全部 RM 回复 prepare 成功
C.一个 RM 回复 prepare 失败← 正确答案
D.TM 收到全部 RM 的反馈

答案：C。两阶段提交的规则是“一票否决”：任意一个 RM 在 prepare 阶段回复失败或超时，TM 就决定全局回滚。只有全部 RM 都回复成功，才会进入提交阶段，这是保证原子性的关键。

Q7. 在 MySQL InnoDB 中，XA 事务的 PREPARED 状态记录在何处？

单选题 · hard

A.仅存储在内存中，重启后丢失
B.仅记录在 binlog 中
C.记录在 InnoDB 的 redo log 且 binlog 有对应记录← 正确答案
D.由应用系统独立保存

答案：C。MySQL 的 XA 实现会将 PREPARED 状态持久化在 InnoDB 的 redo log 中，同时记录 binlog 以确保主从一致性。服务器重启后，可通过这些日志恢复事务状态并决定最终提交或回滚。只存内存（A）会丢失状态；只存 binlog（B）不足以恢复 InnoDB 内部状态。

Q8. XA 两阶段提交中，属于事务管理器（TM）的职责有？

多选题 · mid

A.发起全局事务
B.向各 RM 发送 prepare 指令← 正确答案
C.收集 RM 反馈并做出全局决策← 正确答案
D.管理自身业务的数据库事务

答案：BC。TM 的核心职责是向 RM 发送 prepare/commit/rollback 指令，并汇总投票做出全局决策。发起全局事务通常由应用 AP 完成，不是 TM 的职责；D 是 RM 的职责，TM 本身并不直接操作业务数据库。

Q9. 以下哪些策略有助于降低 XA 事务的死锁概率？

多选题 · hard

A.多个全局事务以相同顺序访问资源← 正确答案
B.尽量缩短锁持有时间← 正确答案
C.无限增加锁等待超时时间
D.将大事务拆分为小事务← 正确答案

答案：ABD。相同资源访问顺序能避免循环等待环的形成；缩短锁持有时间能减少竞争窗口；拆小事务同样缩短了锁占有时长。而无限增大超时时间（C）会让死锁更持久、阻塞更久，是错误做法。

Q10. 关于 XA 与 TCC 两种分布式事务方案，正确的说法有？

多选题 · hard

A.XA 通常对业务代码侵入更小← 正确答案
B.TCC 需要业务方实现 Try/Confirm/Cancel 逻辑← 正确答案
C.XA 在高并发场景下会因锁等待导致吞吐下降← 正确答案
D.TCC 可以完全杜绝数据不一致

答案：ABC。XA 由中间件代管 prepare/commit，业务代码侵入小，但锁持有时间长；TCC 需要业务实现三段逻辑，更灵活但代码复杂。TCC 仍可能因 Confirm/Cancel 逻辑本身的 bug 或网络问题导致不一致，所以 D 的“完全杜绝”表述错误。