Raft 分布式一致性协议笔记
Raft 分布式一致性协议笔记（名词解释+原理+流程+大厂案例）
一、基础认知
1. 核心名词解释
- 分布式一致性：集群中多个独立节点，在网络波动、节点宕机等异常情况下，最终对数据、指令达成统一结果，是分布式系统的核心难题。
- Raft 协议：一款易理解、易落地的分布式一致性算法，主打选主、日志同步两大核心能力，现在被 Nacos、RocketMQ、Kafka 等主流中间件广泛采用，被誉为分布式系统“定海神针”。
- Leader（领导者）：集群主节点，统一接收客户端请求、下发指令、定时发送心跳，集群对外统一入口。
- Follower（跟随者）：集群从节点，被动接收 Leader 指令、同步日志、响应心跳，不主动发起请求。
- Candidate（候选者）：选举临时角色，Follower 超时未收到心跳后切换身份，主动拉票竞选新 Leader。
- 心跳包：Leader 周期性向所有 Follower 发送的轻量数据包，作用是宣告“自身存活”，抑制新选举。
- 选举超时（Election Timeout）：Follower 内置倒计时，超时未收到心跳则触发选举，Raft 采用随机超时时间规避选票平局。
- 日志复制：节点间同步操作日志的过程，是保证集群数据一致的核心流程。
- 脑裂：网络分区导致集群分裂成多个小集群，同时选出多个 Leader，引发数据混乱，Raft 依靠多数派机制从根源规避该问题。
- 多数派（Quorum）：集群半数以上节点，Raft 所有决策（选举、日志提交）都必须获得多数派认可才算生效。
2. 适用场景
集群主从切换、元数据同步、配置中心、消息队列副本管理、分布式数据库多节点数据同步等。
二、Raft 两大核心场景（正常运行 + 故障选主）
Raft 整体分为两大工作模式：集群有 Leader（日常运行）、无 Leader/原 Leader 宕机（选举新主）。
（一）场景一：集群正常运行（存在 Leader）
核心目标：全体节点数据、指令保持一致，依靠「心跳保活 + 日志复制」实现，遵循先同步日志，再执行指令的核心逻辑。
1. 心跳保活（状态压制）
- 规则：Leader 每隔几十毫秒，向所有 Follower 发送心跳包。
- 作用：Follower 收到心跳后，会重置自身选举倒计时，放弃竞选想法，维持当前角色，保证集群稳定。
- 案例：3节点集群（1个Leader+2个Follower），Leader 持续发心跳，两个从节点始终安分待命，集群不会乱选主。
2. 日志复制（数据同步核心流程）
完整分为日志同步 → 多数确认 → 批量执行三步，保证所有节点最终行为一致。
- 客户端发请求：所有客户端请求统一交给 Leader 处理。
- 第一步：同步日志（只记录，不执行）
Leader 将客户端指令写入本地日志，再把日志并行推送给所有 Follower；Follower 收到后仅落地日志，暂时不执行操作，并向 Leader 返回确认回执。 - 第二步：多数派确认
Leader 无需等待全部节点响应，只要包含自己在内的半数以上节点完成日志同步，就判定指令达成共识。该机制容忍少数节点宕机、网络卡顿。 - 第三步：批量执行指令
Leader 先本地执行该指令，在下一轮心跳中附带「日志已提交」标记；Follower 收到标记后，依次执行对应指令。
实战通俗案例
需求：客户端向集群下发“给视频点赞”指令，集群共3个节点（1 Leader + 2 Follower）
- Leader 接收指令，写入本地日志，同步给两个 Follower；
- 两个 Follower 写入日志并回复确认，此时已达到3节点中的多数派（≥2）；
- Leader 执行点赞操作，下一轮心跳通知 Follower 执行；
- 两个 Follower 依次完成点赞，全集群状态统一。
优势：哪怕其中1个Follower 网络超时，只要多数节点正常，业务完全不受影响。
（二）场景二：Leader 宕机 / 集群刚启动（选举新 Leader）
核心目标：快速选出新主，避免集群长期群龙无首，依靠「随机选举超时 + 拉票投票」实现。
1. 选举触发条件
Leader 宕机、断网后，Follower 持续收不到心跳，选举倒计时不会被重置，计时结束后触发选举。
2. 核心规则（解决选票平局）
所有 Follower 的选举超时时间为随机值（一般 150ms ~ 300ms），不会同时触发选举，从根源避免全员竞选、票数持平死锁。
3. 完整选举流程（以3节点集群为例）
- 身份切换：某个 Follower 计时器率先超时，切换为 Candidate（候选者）。
- 自我投票：Candidate 先给自己投一票。
- 全网拉票：向其他节点发送竞选请求。
- 其他节点判断：对方日志不比自己旧 → 同意投票。
- 当选新 Leader：Candidate 获得多数选票，正式成为新 Leader，立刻向全集群发送心跳，接管集群。
实战案例
3节点集群（A、B、F 均为 Follower，原Leader已宕机）
- 节点A 随机超时时间最短，率先变成 Candidate，给自己投票；
- A 向 B、F 发起拉票请求；
- B、F 检查日志正常，分别投票给 A；
- A 获得3票中的3票（超过半数），成为新 Leader；
- A 持续发送心跳，集群恢复正常运行。
关键考点：为什么必须用随机超时？
如果所有节点超时时间完全一致，Leader 宕机后，所有 Follower 会同时变成 Candidate、互相拉票，最终所有节点票数相同，选举陷入死锁，集群彻底瘫痪。随机时间是 Raft 低成本解决平局的巧妙设计。
三、Raft 核心优势 & 关键特性
- 多数派容错：集群 N 个节点，允许最多
(N-1)/2个节点故障。例如5节点集群，挂掉2个仍可正常工作。 - 天然防脑裂：网络分区后，分裂出的小集群无法凑齐多数选票，选不出新 Leader，保证全局只有一个主节点，数据不混乱。
- 易理解、易实现：对比复杂的 Paxos 算法，Raft 逻辑清晰，工程落地难度低，这也是各大中间件选择自研 Raft 的基础。
- 日志强一致性：所有节点最终日志完全一致，保证数据不丢失、不错乱。
四、大厂中间件定制 Raft 案例（重点解答：为何不共用一套源码）
Raft 理论逻辑统一，但不同中间件的业务场景、网络环境、性能诉求差异极大，因此 Nacos、RocketMQ、Kafka 均选择基于 Raft 思想自研定制，而非直接复用通用代码。
案例1：Nacos（阿里配置中心/服务注册中心）
- 业务诉求：保证配置数据、服务元数据强一致，节点频繁上下线、配置频繁更新。
- 定制改造：基于 Raft 实现集群选主与数据同步，优化配置快照、增量日志同步逻辑；适配大量短连接、高频元数据变更场景，保证配置秒级同步。
- 作用：多节点 Nacos 集群依靠 Raft 保证所有节点配置完全一致。
案例2：RocketMQ（消息队列）
- 旧版本问题：早期主从切换依赖人工配置，故障恢复慢。
- 定制改造：基于 Raft 实现 DLedger 组件，完成 Broker 自动主从切换、副本数据同步。
- 场景：Broker 主节点宕机，Raft 快速选举从节点为新主，消息服务无感知切换，提升容灾能力。
案例3：Kafka（消息队列）
- 历史架构：早期依赖 ZooKeeper 做集群元数据管理、控制器选主，额外增加运维组件与故障点。
- 定制改造：新版本推出 KRaft 模式，彻底抛弃 ZK，内置 Raft 协议管理集群元数据、分区控制器。
- 价值：简化架构，降低运维复杂度，依靠 Raft 保证集群元数据（分区、节点映射）强一致。
补充总结：为什么大厂都“重复造轮子”？
- 通用 Raft 代码无法适配各产品的存储结构、通信模型、性能指标；
- 线上存在网络乱序、磁盘写满、节点反复重启等极端问题，需要结合业务做大量细节优化；
- 中间件核心数据至关重要，自研版本可深度调优，兼顾性能、容灾、监控。
五、Raft 优缺点总结
优点
- 逻辑简单，学习、开发、运维成本低，远优于 Paxos；
- 多数派机制，容错能力强，单机/少数节点故障不影响集群；
- 选举速度快（毫秒级），故障切换用户基本无感知；
- 日志同步严谨，数据一致性高。
缺点
- 仅适用于节点数量不多的集群（节点过多，选举、同步开销会上升）；
- 依赖多数派，若集群半数以上节点宕机，集群整体不可用。
六、面试高频问答
- Raft 有哪三种角色？
Leader（领导者）、Follower（跟随者）、Candidate（候选者，选举临时角色）。 - Raft 如何防止选举平局？
给每个 Follower 设置随机选举超时时间，避免同时触发选举。 - 日志复制为什么要先同步再执行？
先通过多数派确认达成共识，再统一执行，保证全集群指令、数据完全一致。 - Raft 能解决脑裂吗？
可以。网络分区后小集群无法凑齐多数选票，无法选出新 Leader，全局仅一个主节点。 - 为什么主流中间件都自研 Raft，不使用通用实现？
不同中间件的业务、存储、网络场景不同，需要针对极端故障、性能做定制化优化。
七、整体总结
- Raft 核心就两件事：有 Leader 就靠心跳+日志同步保证集群一致；无 Leader 就靠随机超时+多数投票快速选主。
- 它不是单纯的理论算法，而是工程化优先的一致性方案，这也是它取代复杂算法、成为行业主流的原因。
- 理论易懂，但落地难点在于处理网络异常、节点抖动、磁盘故障等边界问题，这也是大厂自研定制的核心原因。
浙公网安备 33010602011771号