OceanBase副本选主用的Paxos算法，ZooKeeper选主也用的类Paxos的Zab协议，为何TiDB选择Raft呢？

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】any
【操作系统】any
【部署方式】云上部署
【问题描述】OceanBase副本选主用的Paxos算法，ZooKeeper选主也用的类Paxos的Zab协议，为何TiDB选择Raft呢？

2

这问题没人感兴趣吗？

3

太高深了。不是很了解。 TiDB 数据库的存储 | TiDB 文档中心 希望官方文档帮助你

1 个赞
4

呵呵，静待有缘人了？

5

一、核心设计目标差异

这是两者最根本的区别，直接决定了后续所有设计选择。

  • Paxos：未将 “可理解性” 作为核心目标，更侧重理论上的正确性与简洁性，导致算法结构零散，难以直观理解。
  • Raft：将 “可理解性” 放在首位，目标是让开发者能轻松掌握算法逻辑、建立直观认知，同时为实际系统提供清晰的实现基础。

二、核心机制差异

1. 算法结构：“分解式” vs “整合式”

  • Raft：采用问题分解策略，将共识过程拆分为 3 个独立且可理解的子问题，各模块逻辑清晰、互不干扰。
    • 领导者选举（Leader Election）：通过随机超时机制快速选主，避免投票分裂。
    • 日志复制（Log Replication）：日志仅从领导者流向追随者，强制追随者日志与领导者一致。
    • 安全性（Safety）：通过 “选举限制”（仅日志足够新的节点能当选领导者）确保已提交日志不丢失。
  • Paxos：结构未明确拆分，核心是 “单决议 Paxos”（解决单个日志项共识），再通过 “多决议 Paxos” 扩展到日志序列，两者逻辑交织，且缺少统一的 “领导者” 角色定义，学习门槛高。

2. 领导者角色：“强领导” vs “弱领导”

这是两者最直观的区别，直接影响日志管理复杂度。

维度 Raft Paxos
领导者地位 核心且唯一，正常运行时仅有 1 个领导者 非必需，仅作为性能优化（可选）
日志流向 单向：仅领导者向追随者复制日志 双向：追随者可能向其他节点同步日志
日志一致性维护 领导者强制覆盖追随者冲突日志 需通过多轮协商合并不同节点日志
新日志写入决策 领导者独立决定日志位置，无需协商 需多节点协商日志序号与内容

3. 领导者选举：“随机超时” vs “无明确机制”

  • Raft：选举逻辑独立且简单。
    1. 追随者超时未收到心跳，转为候选者并发起投票。
    2. 采用随机选举超时（如 150-300ms），避免多个节点同时超时导致投票分裂。
    3. 候选者获得多数投票即当选，逻辑闭环清晰。
  • Paxos：无内置的 “领导者选举” 机制，需开发者自行设计（如基于 “租约” 或外部投票），且选举与日志共识逻辑耦合，易出现复杂边角 case。

4. 集群成员变更：“联合共识” vs “无标准方案”

  • Raft：提供安全且不中断服务的成员变更机制。
    • 分两步：先进入 “联合共识” 阶段（同时承认新旧配置，需两边多数节点同意），再切换到新配置。
    • 确保变更过程中不会出现两个独立的 “多数派”，避免双主问题。
  • Paxos：无官方标准的成员变更方案，不同实现（如 Chubby、ZooKeeper）需自行设计，且易因配置切换时机问题导致安全性漏洞。

三、实现与学习成本差异

1. 可理解性：Raft 显著更优

论文通过用户研究验证：43 名学生中，33 人对 Raft 的理解程度（答题得分）高于 Paxos；且绝大多数学生认为 Raft 更易实现、更易向他人解释。

  • Raft 优势：子问题拆分明确，状态空间小（日志无空洞、冲突少），无需理解复杂的 “单决议 / 多决议” 嵌套逻辑。
  • Paxos 劣势：单决议 Paxos 的 “两阶段协议” 难以直观解释，多决议扩展后逻辑更零散，甚至资深开发者也难以完全掌握。

2. 实现复杂度：Raft 更易落地

  • Raft：
    • 仅需 2 种核心 RPC（RequestVote用于选举、AppendEntries用于日志复制与心跳），加上 1 种可选的InstallSnapshot（日志压缩），消息类型少。
    • 日志管理逻辑简单（单向复制 + 冲突覆盖），无需处理复杂的日志合并场景。
  • Paxos：
    • 单决议 Paxos 需 “准备 - 接受” 两阶段 RPC，多决议扩展后需额外处理日志序号同步，消息类型多且逻辑嵌套。
    • 实际系统（如 Chubby）基于 Paxos 实现时，需大幅修改原算法，导致实现与理论差异大，且难以复用理论正确性证明。

四、总结：核心差异一句话概括

Raft 是 “为开发者设计的共识算法”，通过 “强领导 + 问题分解 + 简化状态” 降低复杂度，同时保证安全性与效率；Paxos 是 “为理论正确性设计的算法”，结构灵活但抽象，学习和实现成本高，更适合作为共识理论的基础而非实际系统的直接模板。

1 个赞
6

学到了~

7

这个问题有深度。

1 个赞
8

实际上我觉得 OB 的 paxos 实现，与原生 paxos 相比，与 Raft 更接近

1 个赞
9

OB的paxos实现确实是优化过的，性能可以了~

10

这个仅仅是开发成本而已，最重要的应该是不同协议的 性能差异

1 个赞
11

我以前一个在ob 工作了7年的前同事，说ob 实际也是raft,，宣传paoxs 吹牛 :grinning:

1 个赞
12

呵呵，真的假的？Paoxs就高大上些吗

13

是的，实现难度更大，彰显技术能力

1 个赞
14

好吧~

15

好高端，结合官网学习吧

1 个赞
16

好的，好像在线课程是有的

17

和几款产品的发布时间也有关系，raft论文发布的时间晚一点。

18

产品定位、技术场不同吧

19

这样的吗？

20

有句俗语说的好，适合才是最好的。
oracle rac 还用 ASM共享存储呢，你咋不说 ob为啥不用。