扫码获取 VIP 码
添加管理员微信获取 VIP 码
二阶段提交协议（Two-Phase Commit，简称 2PC）是分布式数据库系统中用于保证分布式事务原子性的经典一致性协议。它的核心思想可以概括为一句话：把一个跨越多个资源管理器（通常是多个数据库节点）的全局事务的提交过程，拆分成两个先后有序的阶段，由一位协调者（Coordinator）统一下达指令，让所有参与者（Participant，也叫参与者节点或从节点）要么全部提交、要么全部回滚，从而保证全局事务满足原子性要求。
在正式展开之前，需要先厘清几个标准术语。分布式事务，指的是一个逻辑事务需要同时操作分布在不同物理节点上的多个数据库，例如一个银行转账操作，需要同时更新 A 地数据库的账户余额和 B 地数据库的账户余额，这两个操作必须作为一个整体成功或失败。协调者，是负责发起并指挥全局提交流程的节点，通常是发起该事务的应用服务器或者专门的事务管理器。参与者，是参与该全局事务、持有各自本地资源和本地事务状态的资源管理器，通常是各个数据库节点。全局提交，指所有参与者的本地事务都提交成功；全局回滚，指只要有一个参与者的本地事务无法提交，所有参与者都必须回滚，以保持全局数据一致。
理解二阶段提交协议，必须把它放在数据库事务的原子性语义这个大背景下。在单机数据库中，一个事务的原子性由本地的事务管理机制保证：要么整个事务的修改全部写入数据库，要么全部撤销，中间不会出现只写了一部分的状态。但是当数据分散在多个节点上时，没有任何一个节点能够单方面知道其他节点的执行情况，也就无法独自决定"要不要提交"。二阶段提交协议正是为了解决这个问题而设计的：它通过引入协调者这个中央决策角色，把所有参与者的本地执行结果先汇总起来，再由协调者做出统一的全局提交或全局回滚决策，从而在分布式环境下还原出单机事务的原子性保证。
从协议性质上讲，二阶段提交协议是一种分布式共识协议的早期形态，它的目标不是选出某个值，而是就"一个全局事务最终是提交还是回滚"这个二值决策达成一致。它与后来出现的 Paxos、Raft 等共识算法的区别在于，2PC 假设存在一个固定的、不会出错的协调者来主导决策，而 Paxos、Raft 则允许任何节点发起提案并在容忍部分节点故障的前提下达成一致。这个假设的差异，也埋下了 2PC 在容错性上的先天不足，这一点会在后面详细分析。
还需要补充说明的是，二阶段提交协议解决的是分布式事务的原子性问题，但它并不单独解决隔离性和一致性问题。原子性保证的是"全有或全无"，而隔离性需要靠并发控制机制（如两段锁协议、多版本并发控制）来保证，一致性则在原子性和隔离性共同作用下才得以维持。很多考生会把分布式事务的各个特性混为一谈，误以为只要用了 2PC 就万事大吉，这是理解上的一个常见偏差。在软考的考查框架里，2PC 通常只对应"多个节点如何统一提交或回滚"这一件事，而并发控制、故障恢复是另外的知识模块，二者要分开掌握。
二阶段提交协议的运行机制，需要拆开看它的两个阶段分别做了什么、协调者和参与者各自维护了怎样的状态、日志又是如何保证崩溃恢复的。只有把这些底层机制理解透，才能在考试中准确判断每一个状态转换的时机。
准备阶段（Prepare Phase），也叫投票阶段（Voting Phase），是整个协议的第一步。这一阶段的目标是让协调者询问所有参与者是否已经做好了提交的准备。
具体的消息交互流程是这样的：协调者首先在本地事务日志中写入一条"开始提交"的记录，目的是万一协调者在本阶段崩溃，恢复后能够知道自己正在处理哪个全局事务。然后，协调者向所有参与者广播一条准备提交（prepare）消息。
每一个参与者收到准备提交消息后，执行自己本地事务的全部操作，但此时并不真正提交。这里有一个关键点：参与者在执行本地事务的同时，会写入两类日志——重做日志（redo log）和撤销日志（undo log），并且对事务涉及的数据记录加上排他锁。写入重做日志，是为了将来一旦收到提交指令，能够保证即使发生故障也能重放这些修改；写入撤销日志，是为了将来一旦收到回滚指令，能够把这些修改干净地撤销掉。加排他锁，是为了在最终决策下达之前，防止其他事务对这些数据做出并发修改，从而保证提交或回滚操作能够安全执行。
参与者完成上述操作后，根据本地事务的执行结果向协调者回送一个投票消息。如果本地事务执行成功、资源和日志都已就绪，就回送"同意提交"（ready，也可理解为投赞成票）；如果本地事务执行失败、或者遇到任何无法继续的情况，就回送"放弃提交"（abort，投反对票）。需要注意的是，一旦参与者回送了"同意提交"，它就进入了一种特殊的"就绪"状态，这个状态意味着参与者已经把事务的修改写入了日志并锁定了资源，只等协调者的最终指令，自己已经不能单方面反悔了。
提交阶段（Commit Phase），也叫执行阶段，是协议的第二阶段。协调者在收集齐所有参与者的投票之后，进入决策环节。
协调者的决策逻辑非常清晰：如果所有参与者都回送了"同意提交"，协调者就在自己的事务日志中写入一条"全局提交"记录，然后向所有参与者广播提交（commit）指令；只要有一个参与者回送了"放弃提交"，或者协调者在规定的超时时间内没有收到某个参与者的投票，协调者就在日志中写入"全局回滚"记录，然后向所有参与者广播回滚（rollback）指令。这一条"一票否决"的规则，是二阶段提交协议保证原子性的核心所在——任何一个参与者的失败都会导致整个全局事务的回滚。
参与者收到提交指令后，执行真正的本地提交操作：把重做日志中记录的事务修改正式应用到数据库，释放之前加的排他锁，写入一条"已提交"日志记录，然后向协调者回送一个确认（ack）消息。参与者收到回滚指令时，则利用撤销日志把本地事务的修改撤销掉，释放锁，写入"已回滚"日志记录，同样回送确认消息。
协调者收集齐所有参与者的确认消息后，在日志中写入一条"事务完成"记录，整个全局事务的处理流程到此结束。之所以要求参与者回送确认消息，是为了让协调者确认每一个参与者都已经真正完成了提交或回滚，这样协调者才能安全地释放为这个全局事务所维护的状态信息，否则一旦协调者过早清理状态，后续若需重发指令就会失去依据。
如果从有限状态机的视角来看二阶段提交协议，整个协议的生命周期就变得非常清晰。协调者的状态转换顺序是：初始状态，写入"开始提交"记录后进入"等待投票"状态，收集齐投票后进入"决策"状态并写入提交或回滚记录，广播指令后进入"等待确认"状态，收齐确认后回到"完成"状态。参与者的状态转换顺序是：初始状态，收到准备提交消息后执行本地事务并写日志，进入"就绪"或"放弃"状态，其中"就绪"状态会一直保持，直到收到提交或回滚指令，才转换到"已提交"或"已回滚"状态。
这个状态机里最值得注意的，就是参与者的"就绪"状态。它是一个高度不稳定的中间态：参与者已经锁定了资源、写好了日志，但事务的最终结果尚未确定，必须被动等待协调者下达指令。这个中间态正是二阶段提交协议所有缺陷的根源，理解了这个中间态，后面要讲的同步阻塞、单点故障等问题就都不难理解了。
从日志的角度再看一遍，可以更深刻地理解 2PC 为什么需要这么多轮消息往返。协调者的"开始提交"日志和"全局提交"或"全局回滚"日志，构成了协调者崩溃恢复时的决策依据；参与者的重做日志和撤销日志，构成了参与者崩溃恢复时的执行依据。可以说，二阶段提交协议本质上是依靠日志的顺序写入来对抗节点故障的。协调者只有在日志里确认了全局决策之后才会广播指令，参与者只有在日志里确认了本地执行结果之后才会回送投票，这种"先落盘、再通信"的顺序，保证了任何一方的崩溃都不会导致决策信息的丢失。理解这一点，就能明白为什么 2PC 的每一次关键动作之前都要先写日志——这不是冗余，而是分布式环境下唯一可靠的记忆手段。
二阶段提交协议并非一个孤立存在的协议，它在实际的分布式系统中有着明确的工程落地形态，并且在其基础上还衍生出了改进版本。理解它的分类与应用场景，有助于把握命题人对这个考点的考查边界。
二阶段提交协议最著名的工程实现，是 X/Open 组织提出的 XA 规范（X/Open Distributed Transaction Processing，分布式事务处理模型）。XA 规范定义了三类角色：应用程序（Application Program）、事务管理器（Transaction Manager，TM）和资源管理器（Resource Manager，RM）。其中事务管理器就扮演二阶段提交协议中协调者的角色，资源管理器（通常是数据库）就扮演参与者的角色。XA 规范规定了事务管理
本篇完！