6.1 Raft 共识 101

Raft 正是当前工业界最主流的共识实现之一：Etcd、TiKV、CubeFS Master 等系统都在不同层次上使用了 Raft（或 Multi-Raft）。理解 Raft，是读懂这些系统控制面与数据面复制组行为的关键一步。尤其是在复杂分布式环境下，系统行为的设计和推演，必须建立在深度理解 Raft 算法、工业级 Raft 共识框架的实现上。

初识 raft 学习思路：战略上重视，战术上藐视

笔者认为，工程师不应过分神魔化这个经典的共识方法。它应当是我们构建大规模分布式系统的一把锤子。我们的任务仍然是建立认识和合理应用。

在笔者入门的时候，还远没有 Claude 和 Gemini 帮忙答疑解惑。是带着一丝抽象的色彩去看了原论文，再一头雾水地去推导论文中的一些 conner case。

现在回过头来看，更应该先根据计算机系统的抽象和分层，了解清楚上层应用与共识算法之间调用边界，再去细究算法证明和实现细节。

不妨让我们 “假想一个工程任务” 来学习 raft：

• 在 1 个月内，利用现有的 raft 工业级框架，迅速建立起一套分布式存储集群控制面组件
• 提供节点扩缩容等运维能力和处理 SOP
• 保证控制面的一致性和高可用性
• 建立异常场景的共识算法的逻辑和推演能力和处理 SOP

这种假想目标会帮助我们去魅这个算法，强迫我们从更高层的架构思考整个 raft 的使用。

共识算法与工业系统用途

2026年，Raft 算法其实不是一个年轻的新算法，其已经在众多分布式系统中得到了大范围的应用。

先抛开复杂的算法理论研究，根据笔者观察和理解，raft 算法被用在以下场景

• 分布式系统控制面的实现，利用其一致性、高可用性、管理接口
• 分布式存储元数据的构建，常常配合分片策略和 multi-raft 扩展，利用其多数派写和扩缩容能力
• 分布式存储数据面的构建，利用了其多数派写能力、以及 raft log 的定序能力

而这些需求都可以抽象成一种 “共识算法” 的需求。

共识关注的是达成一致的过程。在现实中，分布式系统充满了不确定性：服务器可能会突然宕机重启，网线可能会被挖断，消息可能会延迟或丢失。共识算法就是一套严密的数学和逻辑规则，确保在这个充满故障的群体中，所有健康的节点依然能够对某一个值或某一项决定“达成共识”。

复制式状态机(RSM): 上层应用的权利和义务

为什么必须先了解复制式状态机(replicated state machines, RSM)？因为你想构建的服务逻辑，必须是 RSM 的形状，才能配合 raft 使用。

Raft 算法本身并不关心你的业务是做 KV 存储还是做消息队列。Raft 的唯一工作，就是保证分布式环境下，输入指令序列的一致性。——这也是工业级 raft 框架赋予用户的能力。

接下来不得不搬出这张读者可能已经看出的审美疲劳的插图了。

Raft 算法对业务逻辑要求 (上层应用的义务)

算法/框架强迫你将自己的业务逻辑设计成如下形状

• 服务端(Server)能够将用户的请求抽象、包装成日志指令(Log)
• 业务逻辑状态机(State Machine)接受来自共识算法处理的日志副本(Log)
• 业务逻辑状态机(State Machine)若以完全相同的顺序执行日志指令，能得到一模一样的输出。

Raft 算法的职责（上层应用的权利）

算法/框架负责保证 replicated log 的一致性。

• 客户端发出请求，服务端包装成指令给共识算法模块
• 共识算法自身互相通信
• 保证在混沌的分布式环境中，replicated log 能够以相同的顺序给与业务逻辑状态机(State Machine)
• 少量慢速、异常机器不影响整个系统的性能
• 支持节点的迁移、变更

对于上层业务，共识算法就是一个神奇的黑盒。在 client 视角，整个业务高可用组是一个可靠的状态机。