Raft 核心原理与工程实践 —— 开篇:分布式共识的本质与 Raft 引言
Raft 核心原理与工程实践 —— 开篇:分布式共识的本质与 Raft 引言
导语: 在现代后端架构中, 只要涉及到高可用和强一致性, 我们总是绕不开一个词: 共识(Consensus). 提到共识, 很多人立刻会想到晦涩难懂的 Paxos. 如果说 Paxos 是分布式共识领域的"相对论", 那么 Raft 就是将相对论转化为工程可用技术的"造原子弹说明书". 在深入探究 Raft 的机制之前, 我们必须先站在高处, 俯瞰整个分布式系统的全貌.
一、 现代分布式系统的基石
1. 分布式服务器集群的宏观视角
当我们谈论分布式集群时, 我们在谈论什么？从宏观视角来看, 一个优秀的分布式系统应该像是一个"黑盒". 无论内部由 3 台、5 台还是 1000 台物理机组成, 对外部客户端而言, 它表现得就像是一台永不宕机、性能无限扩展的超级单机.
这种"单机错觉"是通过网络通信和状态协同来维持的. 但网络是不可靠的(延迟、丢包、乱序), 节点是脆弱的(OOM、断电、磁盘损坏), 如何在物理上的不确定性之上, 构建出逻辑上的确定性, 这就是分布式系统的核心命题.
2. 为什么需要多个节点？(打破单点诅咒)
传统的单机架构面临着无法逾越的物理瓶颈:
- 可用性(Availability): 单节点意味着单点故障(SPOF). 一旦机器宕机, 整个服务不可用.
- 吞吐量(Throughput): 单机的 CPU、内存和磁盘 I/O 上限决定了业务的天花板. 为了解决这些问题, 我们引入了多节点副本(Replica). 但多节点随之带来了分布式领域最让人头疼的问题——数据一致性.
3. 为什么需要共识算法？
假设我们有 A、B、C 三个节点. 客户端向 A 写入了 x=1, 紧接着向 B 写入了 x=2. 如果此时网络发生分区(Network Partition), C 节点该听谁的？ 如果没有一个严谨的规则, 集群就会出现脑裂(Split-Brain), 各个节点的数据南辕北辙. 共识算法的存在, 就是为了在存在故障和网络异常的异步系统中, 让多个节点对"某一个值"或"一系列操作的顺序"达成不可逆的共识, 以此来保证对于客户端来说, 整个服务系统是完全一致, 并且没有宕机的.
4. 从宏观共识到微观节点:如何落地？
虽然我们理解了共识算法的宏观目标——让多个节点"统一口径", 但落实到工程实现上, 这并不是魔法. 我们需要一种具体的架构模式, 让每个独立的物理节点都能遵循相同的规则行事.
这就引出了分布式系统中最经典的工程抽象:如何把一个庞大的集群级共识问题, 拆解为每一个单节点都能独立执行、且互不冲突的确定性逻辑？要在不可靠的网络面上建立可靠的共识, 我们必须先将每个节点变成一台严谨的"状态演进机器".
二、 透视单节点:复制状态机(RSM)架构
我们以 Raft 共识算法为例, 在 Raft 中, 我们通常说有 Leader 节点, Follower 节点, 有时候还会出现 Candidate 节点. 但是这些只是节点处于不同的状态, 每个节点应该是独立运行相同的程序的, 只是在不同的时间点处于不同的状态. 在实际实现中, 集群中的每一个节点, 本质上都是一个复制式状态机(Replicated State Machine, RSM). 这也是理解分布式共识的最核心概念: 如果两个状态机具有相同的初始状态, 并且按照相同的顺序执行了相同的输入指令, 那么它们最终必然达到相同的状态.
因此, Raft 的核心任务不是直接同步数据, 而是同步操作日志(Log)的顺序. 真正的数据同步由下层的状态机保证. 我们之前的博客就介绍了一种日志同步的虚拟机.
1. 核心五层组件设计
如果我们解剖一个 Raft 节点的内部(注意, 每一个节点都是相同的), 它通常遵循高度解耦的五层设计:
- L1. 客户端 API 层 (Client Interface): 负责接收外部的读写请求, 并在内部路由到当前系统的 Leader 节点.
- L2. 共识模块 (Consensus Module): **Raft 的大脑. ** 负责处理选举(选主)、日志复制、以及心跳维持. 它决定了一条日志是否可以被"提交(Commit)".
- L3. 日志存储层 (Log/WAL Storage): 持久化层. 所有操作在执行前, 必须先追加到本地的预写日志(Write-Ahead Log)中. 即便机器掉电, 重启后也能通过日志恢复.
- L4. 状态机 (State Machine): 真正的业务执行引擎(例如一个 KV 数据库的内存哈希表). 只有被共识模块标记为"已提交"的日志, 才会被应用(Apply)到状态机中.
- L5. 网络 RPC 层 (Network RPC): 节点间的通信基建. Raft 只需要两种核心 RPC:
RequestVote(请求投票)和AppendEntries(追加日志与心跳).
Raft 中的每一个节点都包含上述的所有模块, 并且执行相同的程序, 只是在不同的时刻可能扮演不同的角色.
2. 补充:一条写请求的"黄金流转"链路
在这一套架构下, 一条写请求(例如:SET X 10)的生命周期如下:
- 接收: Leader 接收到客户端的写请求.
- 追加: Leader 将该请求作为一个新的 Entry 追加到自己的本地日志中(此时未提交).
- 广播: Leader 并行地向所有 Follower 发送
AppendEntriesRPC. - 复制: Follower 收到验证无误后, 写入本地日志并回复 ACK.
- 提交: Leader 收到大多数(Majority, N/2+1)节点的 ACK 后, 将这条日志标记为已提交(Committed).
- 应用与响应: Leader 将日志应用到本地状态机, 并将成功结果返回给客户端. 异步地, Leader 在下一次心跳中通知 Follower 也去应用这条日志.
下图中展示了基础状态下上述的五层组件设计结构, 以及服务端的 Leader 节点与 Follower 节点是如何协作以及处理请求的. 图中还有 Leader 宕机的情况, 以及选举发生的情况, 这个我们后续会详细解释.
三、 共识算法的核心特性与工程保证
从工程的角度来看, Raft 为系统提供了三个钢铁般的保证:
- 安全性(Safety): 系统绝对不会返回错误的结果. 如果任何一个节点在状态机中应用了一条特定的日志条目, 那么其他任何节点都不可能在同一个日志索引位置应用不同的日志.
- 高可用(Availability): 只要集群中有多数派(N/2+1)节点存活且可以相互通信, 系统就能持续提供服务. 例如 5 台机器的集群, 可以容忍 2 台机器同时宕机.
- 线性一致性(Linearizability): 一旦一个写操作完成并返回给客户端, 那么所有后续的读操作, 都必定能读到这个最新写入的值.
四、 工业级实战推演:以核心支付系统为例
理论往往是枯燥的, 让我们把 Raft 放到一个真实的工业场景中:银行后台跨行转账的核心支付系统.
1. 场景设定:支付状态的流转
假设我们用一个 3 节点的 Raft 集群(Node A 为 Leader, B 和 C 为 Follower)来维护用户的账户余额表(这就是我们的状态机). 当前状态机中:User_X = 1000 元.
用户发起了一笔操作:"User_X 扣减 200 元".
- Node A(Leader)收到请求, 生成一条日志
[Index: 5, Term: 2, Command: User_X - 200]. - A 将日志并行发送给 B 和 C.
- B 和 C 收到后落盘日志, 回复给 A:"我已记录".
- A 发现加上自己, 已经有 3 个节点(大于多数派 2)记录了日志. 于是 A 将操作应用到状态机:
User_X的余额变为 800 元. - A 告诉网关:支付成功.
2. 故障模拟:主节点宕机与数据拯救
极端情况来了: 假设 Leader A 在收到 B 和 C 的确认(步骤 3)之后, 还没来得及把结果应用到状态机, 也没来得及返回给客户端, 突然网线断了(节点宕机).
- 客户端视角: 支付请求超时. 钱到底扣没扣？
- 集群内部视角: B 和 C 发现 A 迟迟不发心跳, 开始新一轮选举. 假设 B 胜出成为新 Leader.
- 数据一致性保证: 此时 B 上已经拥有那条未决的
[User_X - 200]日志. B 当选后, Raft 的机制会强制 B 推进前任遗留的日志提交. B 会将这条日志标记为 Committed, 并应用到自己的状态机中. - 最终结果: 账户余额安全地变成了 800 元. 客户端由于超时发起重试检查, 查询到的已经是扣款成功后的状态, 资金没有因为宕机而产生任何错乱.
这就是共识算法的魅力所在:在混乱和故障中, 凭借精妙的规则, 捍卫数据的绝对正确.
结语: 本篇我们从宏观的分布式需求出发, 了解了 RSM 的工作原理和 Raft 的核心流转链路. 但你可能还有疑问:Leader 宕机后, 节点是如何选出新 Leader 的？如果日志发生冲突该如何截断？
浙公网安备 33010602011771号