两阶段协议解释

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】oceanbase数据库两阶段提交协议和传统两阶段协议区别
【复现路径】问题出现前后相关操作

3 个赞
#3

一、传统的两阶段提交协议（2PC）回顾

传统 2PC 的流程大致如下（如 XA 协议、分布式数据库标准实现）：

        +-------------+
        | Coordinator |
        +-------------+
             /  \
            /    \
    +-----------+ +-----------+
    |  Participant A | | Participant B |
    +-----------+ +-----------+

阶段一：Prepare 阶段

  1. 协调者（Coordinator）向所有参与者（Participant）发出 prepare 请求。
  2. 每个参与者执行事务操作，但不提交，只写预提交日志并锁定资源。
  3. 所有参与者返回“可以提交”或“回滚”响应。

阶段二：Commit 阶段

  1. 如果所有参与者都返回“可以提交”，协调者向所有参与者发送 commit。
  2. 否则，发送 rollback。
  3. 各参与者执行最终的提交或回滚，并释放资源。

:point_right: 特点与问题：

  • 协调者是单点，容易成为瓶颈。
  • 参与者要在 prepare 阶段持锁，等待协调者指令 → 容易造成长事务阻塞。
  • 协调者故障会导致长时间的不确定状态（需要引入超时、恢复机制）。
  • 事务日志往往分散在多个节点，恢复复杂。

二、OceanBase 的两阶段提交协议概览

OceanBase 也使用 2PC，但做了 深度的内核优化，其主要特点有：

方面 OceanBase 的做法
协调者角色 事务发起方分区自动充当协调者（Coordinator），无额外集中式协调节点
Prepare 阶段 参与者预提交事务，同时将 prepare 信息写入 Paxos 日志，保证分布式一致性
Commit 阶段 协调者发送 commit/abort，参与者直接提交，本地完成，不依赖集中式日志
故障恢复 依赖 Paxos 日志流（LS）实现无协调者恢复，避免“悬挂事务”
优化点 合并 prepare+日志同步、局部提交、单机事务可降级为本地提交，避免不必要的分布式 prepare

:compass: 三、详细流程对比（OceanBase vs 传统）

阶段 传统 2PC OceanBase 2PC
协调者选取 专门的协调节点或 TM（Transaction Manager） 自动由事务发起的分区（主分区）担任协调者，无需额外角色
Prepare 阶段 发 prepare → 各参与者写 redo/undo → 返回可以提交 发 prepare → 各参与者写 Paxos 日志 记录 prepare 信息，保证副本一致；返回 ack
Commit 阶段 协调者汇总 → 发 commit/rollback → 参与者提交或回滚 协调者汇总 ack → 发 commit → 参与者提交，本地完成；协调者也写 commit log，保障恢复
日志存储 各节点独立日志 + 协调者日志 参与者 prepare 日志同步到副本，依赖 Paxos 确保多数派成功即认为 prepare 成功
容错 协调者宕机会卡住事务，需要 TM 恢复 协调者或参与者宕机 → Paxos 日志自动恢复，事务不会长时间卡住
本地事务 不涉及 2PC OceanBase 可识别“单分区事务”，直接本地提交，跳过 2PC
4 个赞
#4

谢谢

#5

XUEXI

#6

学习到了，每天学习一点点