分布式事务的两阶段提交协议（2PC）

描述
两阶段提交协议（2PC）是分布式系统中用于保证跨多个节点的事务原子性的经典算法。它确保所有参与节点要么全部提交事务，要么全部中止事务，避免部分提交导致的数据不一致问题。协议包含一个协调者（Coordinator）和多个参与者（Participant），通过“准备阶段”和“提交阶段”两个阶段实现协作。

详细讲解

1. 角色与前提条件

   • 协调者：中央节点，负责决策事务的最终提交或中止，并驱动协议流程。
   • 参与者：实际执行事务的子节点，负责本地事务操作并反馈状态。
   • 前提：所有节点均假设为可故障但支持日志持久化（通过日志恢复状态），且网络可能延迟但不会恶意篡改消息。

2. 第一阶段：准备阶段

   • 步骤1：协调者向所有参与者发送“准备请求”（Prepare），附带事务内容。
   • 步骤2：每个参与者执行本地事务操作（如写日志、加锁），但不提交。若执行成功，参与者回复“同意”（Yes）；若失败（如违反约束），回复“中止”（No）。
   • 关键点：参与者回复“Yes”后，必须保证本地事务最终能提交（即使后续崩溃），这通过写持久化日志实现。

3. 第二阶段：提交阶段

   • 情况A：所有参与者回复“Yes”
     • 协调者向所有参与者发送“提交请求”（Commit）。
     • 参与者收到后正式提交本地事务（如释放锁、写入最终数据），并回复“完成”（Ack）。
     • 协调者收到所有Ack后，标记事务完成。
   • 情况B：任意参与者回复“No”或超时
     • 协调者向所有参与者发送“回滚请求”（Abort）。
     • 参与者收到后中止事务（撤销操作、释放锁），并回复Ack。
     • 协调者收到所有Ack后，标记事务中止。

4. 故障处理与缺陷

   • 参与者崩溃：
     • 若在准备阶段崩溃，恢复后根据日志决定：若已记录“Yes”，则等待协调者指令；若未记录，可单方面中止。
     • 若在提交阶段崩溃，恢复后根据日志：若已记录Commit，则提交；若记录Abort，则回滚；若无记录，需查询协调者状态。
   • 协调者崩溃：
     • 若在发送Prepare前崩溃，事务自动中止。
     • 若在准备阶段后崩溃，参与者可能阻塞（等待指令），需通过日志选举新协调者或超时机制解决。
   • 核心缺陷：
     • 同步阻塞：参与者在回复“Yes”后需锁定资源，等待协调者指令，期间资源不可被其他事务访问。
     • 单点问题：协调者故障可能导致整个系统阻塞。
     • 数据不一致风险：若协调者仅部分节点收到Commit指令后崩溃，部分节点可能提交而其他节点未提交。

5. 实际应用与优化

   • 2PC是分布式数据库（如MySQL Cluster）和中间件（如Java EE的JTA）的基础协议，但通常结合超时机制和重试策略降低阻塞风险。
   • 改进方案如三阶段提交（3PC）通过引入“预提交”阶段减少阻塞，但增加了复杂度，实际较少使用。