Raft核心原理与工程实践_动态成员变更与联合共识
Raft 剖析终篇_运行中的跑车换轮胎, 动态成员变更与联合共识
导语: 在前面的四篇文章中, 我们所有的推演都有一个潜在的假设:集群的节点数量和名单是固定不变的. 但在真实的工业环境中, 机器会老化报废、业务会突增需要扩容. 我们需要一种机制, 能在不停机、不影响外部服务的前提下, 将集群从 3 个节点扩容到 5 个, 或者替换掉损坏的节点. 在分布式系统中, 这被称为“给正在高速行驶的汽车换轮胎”. 今天, 我们将揭开 Raft 动态成员变更的神秘面纱, 看看它是如何化解新老交替时的脑裂危机的.
一、 灾难起源: 为什么不能直接修改配置？
最直观的想法是: 管理员直接向 Leader 发送一条指令: “把节点配置从 A,B,C 改为 A,B,C,D,E”. Leader 收到后广播给全网.
致命缺陷: 配置生效的“时差”会导致脑裂 (Split-Brain).
由于网络延迟和节点处理速度的不同, 集群中的节点不可能在同一绝对时间点切换到新配置. 假设我们尝试将集群从 3 节点(\(C_{old}\))变更为 5 节点(\(C_{new}\)).
========================================================================
灾难现场: 直接变更配置导致的双 Leader 脑裂
------------------------------------------------------------------------
节点 A (原Leader): 率先应用了 C_new (5节点配置)
节点 B: 还没收到通知, 依然处于 C_old (3节点配置)
节点 C: 还没收到通知, 依然处于 C_old (3节点配置)
节点 D (新加入): 处于 C_new 配置
节点 E (新加入): 处于 C_new 配置
========================================================================
脑裂推演:
- 此时如果发生网络抖动, 触发了重新选举.
- 节点 B 处于 \(C_{old}\), 它只需要拿到 A,B,C 中的 2 票 就能当选 Leader.假设 B 和 C 互相投票, B 成了 Leader.
- 节点 E 处于 \(C_{new}\), 它需要拿到 A,B,C,D,E 中的 3 票 就能当选 Leader.假设 A, D, E 互相投票, E 也成了 Leader.
- 悲剧发生: 同一个 Term 内, 集群中出现了两个合法的 Leader, 分别处理客户端请求, 数据彻底错乱毁灭！
结论: 任何直接从 \(C_{old}\) 切换到 \(C_{new}\) 的单步操作, 都无法避免不相交的多数派产生.
二、 Raft 的正统解法: 联合共识(Joint Consensus)
为了跨越这个鸿沟, Raft 的作者 Diego Ongaro 引入了一个极度严谨的过渡状态:联合共识(Joint Consensus, 简称 \(C_{old,new}\)).
核心思想是: 既然直接跳跃会摔死, 那我们就分两步走.在过渡期, 让系统同时受制于新旧两种配置.
1. 联合共识的执行流程
我们用一个序列图来看看一次安全的成员变更(从 \(C_{old}\) 到 \(C_{new}\))是如何流转的:
2. \(C_{old,new}\) 状态的钢铁规则
在这个过渡期(步骤 2 到 8), 集群处于 \(C_{old,new}\) 状态, 此时如果发生选举或日志提交, 必须遵循极其严苛的条件:
- 日志提交: 一条业务日志必须同时获得 \(C_{old}\) 机器中的大多数 ACK, 并且获得 \(C_{new}\) 机器中的大多数 ACK, 才算提交！
- 选举获胜: 一个 Candidate 必须同时拿到 \(C_{old}\) 的多数票, 并且拿到 \(C_{new}\) 的多数票, 才能当选 Leader！
这就从数学上彻底锁死了产生两个 Leader 的可能性.因为无论是旧配置还是新配置, 它们的大部分都被同时控制住了.
三、 工业界的妥协与进化: 单节点变更(Single-Server Change)
联合共识虽然在数学上完美无瑕, 但它的实现逻辑极其复杂, 容易出 Bug.因此, Diego Ongaro 在他的博士论文中提出了一个简化版的替代方案, 这也是目前 etcd、TiKV 等工业级系统的标配: 单节点变更.
1. 为什么一次只变一个节点是绝对安全的？
数学原理很简单:如果你每次只向集群中增加 1 个节点, 或者移除 1 个节点, 那么变更前后的两个配置的“多数派”必然会有交集.
- 假设旧配置是 3 个节点(需 2 票当选).
- 新配置增加 1 个节点, 变成 4 个节点(需 3 票当选).
- (2+3)>4.这意味着, 不可能存在两组不相交的节点分别选出 Leader. 旧配置的多数派和新配置的多数派, 必定有至少一台机器是重合的. 而由于 Raft 的规则(一台机器一个 Term 只能投一票), 脑裂被从根本上阻止了.
2. 工业界的操作规范
如果你要从 3 节点扩容到 5 节点, 工业界的做法不是一次性加两个, 而是:
- 提交
AddNode(D)的变更日志, 集群变为 4 节点. - 等待变更完全 Commit.
- 提交
AddNode(E)的变更日志, 集群变为 5 节点.
大道至简, 这就是顶级架构的工程权衡.
四、 深水区: 成员变更中的极端异常与解法
了解了流程只是入门, 真正的考验在于处理变更过程中的特殊情况. 以下是三个最经典的坑与 Raft 的解法:
异常场景一: 空白节点拖垮集群可用性 (The Catch-up Problem)
问题: 假设我们向 3 节点集群加入一个全新的节点 D. D 的日志是完全空的(Index=0), 而当前集群的 Leader 已经跑到 Index=10000 处了. 如果在配置变更生效的那一刻, D 拥有了投票权, 但它因为日志太落后, 跟不上 Leader 的新日志同步速度, 它就无法给出 AppendEntries 的 ACK. 此时如果原本的 3 个节点挂了一个, Leader 就凑不齐多数派了(4 节点的多数派是 3, 现在只有 2 个能响应), 整个集群直接陷入“可用性瘫痪”.
Raft 的解法: 引入 Learner(学习者)角色
- 新加入的机器首先被标记为 Learner(只同步日志, 不参与投票, 不算入配置的计算基数).
- Leader 会像倒水一样, 把历史日志拼命发给 Learner.
- 只有当 Leader 发现 Learner 的日志进度已经基本追平了(只差几个心跳间隔)时, Leader 才会真正发起那条
AddNode(D)的配置变更日志, 赋予它投票权.
异常场景二: 被踢出的节点化身“复仇怨灵” (The Disruptive Server)
问题: 假设 Leader 发起了移除节点 A 的操作. 变更完成后, A 被移除了. 但是 A 自己并不知道(比如它网络刚好断了没收到新配置). A 依然认为自己是集群的一员. 由于 A 收不到心跳了, 它的选举定时器超时, 它会把自己的 Term 增加, 并向全网广播 RequestVote. 现任 Leader 收到 A 的高 Term 投票请求, 会“见大即怂”, 立刻退位. 这导致集群无故中断并重新选举. 由于 A 已经被踢出配置, 它选不上 Leader, 于是不断超时, 不断增加 Term 发起拉票, 导致集群永无宁日！
Raft 的解法: CheckQuorum 机制 与 Pre-Vote
- 工业界普遍采用 CheckQuorum(仲裁检查): 只要一个正常节点在过去的一个选举超时时间内, 成功收到过现任 Leader 的心跳, 它就会直接无视并丢弃任何发过来的
RequestVote请求. - 怨灵 A 发再多的拉票信息, 只要现任 Leader 活得好好的, Follower 们根本连看都不看一眼, A 就无法扰乱系统.
异常场景三: Leader 挥刀自宫 (Leader Steps Down)
问题: 如果管理员发起的成员变更, 恰好是要移除当前的 Leader 节点呢？
Raft 的解法: 站好最后一班岗
- 即使 Leader 知道自己被移除了(它将移除自己的 \(C_{new}\) 日志写入了本地), 它也不能立刻交出兵权.
- 它必须继续扮演 Leader, 坚持把这条 \(C_{new}\) 日志复制到多数派身上.
- 只有当它确认 \(C_{new}\) 这条日志已经成功被 Commit 的那一瞬间, 它才会“功成身退”, 主动退化为 Follower 并关闭自身, 把选举权交给剩下的节点.
浙公网安备 33010602011771号