HDUO Lab

深入 Raft 陷阱排查：巨型 Snapshot 传输阻塞心跳引发的 Leader 频繁易主与集群雪崩实战

作者：

ningniu

在

近期排查了一个极为经典的分布式共识层故障。某核心业务的自研强一致性 KV 存储（基于 Hashicorp Raft 深度定制）在节点替换时，触发了集群级别的写操作持续超时（P99 Spikes > 5s）。排查结论很简单：落后节点重连触发了巨型 Snapshot（快照）全量同步，Leader 端粗暴的单线程 I/O 模型导致 AppendEntries（心跳）被阻塞，健康的 Follower 因迟迟未收到心跳而触发 Election Timeout，集体反叛导致 Leader 频繁易主，集群陷入“同步快照-心跳超时-重新选举-打断快照”的死亡循环。

Raft 的论文非常优雅，但工程落地绝对是另一个维度的泥潭。把心跳（Heartbeat）和海量数据复制（Snapshot Transfer）塞进同一个事件循环或 I/O 队列里，是很多自研分布式系统最容易犯的低级错误。

案发现场：一次常规扩容引发的血案

业务侧最初的反馈是集群 QPS 出现周期性跌零。登录到 Leader 节点，Load Average 并不高，但 Raft 核心日志疯狂刷屏：

[WARN] raft: Heartbeat to follower B took 1250ms, expected < 100ms
[WARN] raft: Heartbeat to follower C took 1280ms, expected < 100ms
[INFO] raft: Node A stepping down to follower, term changed (term 150 -> 151)
[INFO] raft: Node C elected as leader for term 151

紧接着，不到 2 分钟，Node C 也交出了 Leader 权限，集群就像在玩击鼓传花。 查看监控指标：

  1. Raft Term（任期）：呈阶梯状疯狂上涨。

  2. Leader Transition Count：每 1~2 分钟触发一次。

  3. Network TX (Leader)：在每次选举后，网络打满到 1.5Gbps，持续数十秒后骤降为 0。

我抓取了当时的 goroutine profile，发现 Leader 节点的大量 CPU 时间和网络栈都耗在了 InstallSnapshot RPC 上。

扒开底层看逻辑：为什么会雪崩？

根据 Raft 协议，当一个 Follower 落后太多（其请求的 nextIndex 已经被 Leader 的日志压缩机制丢弃），Leader 就无法通过增量的 AppendEntries 来同步日志，只能发送 InstallSnapshot。

在这个案例中，业务积累了约 8GB 的状态机数据。当新节点加入时，触发了以下连锁反应：

  1. 同步阻塞：Leader 收到同步请求后，开始读取本地的 8GB Snapshot 文件，并通过 gRPC/TCP 将数据 Chunk 发送给 Follower。

  2. 心跳饥饿：由于底层的 Raft 核心循环（Event Loop）没有对心跳和数据复制做严格的线程隔离和 QoS 划分。发送 Snapshot 占满了网络 I/O 线程，甚至阻塞了 ticker 处理逻辑。

  3. 心跳超时：Leader 配置的 HeartbeatTimeout 是 100ms，ElectionTimeout 是 1000ms。由于网络栈被 8GB 快照传输打满，或者 I/O 阻塞了协程，发往其他健康 Follower 的空心跳（Empty AppendEntries）被延迟了 1.2 秒才发出。

  4. 集群兵变：健康的 Follower 苦等 1000ms 没收到心跳，立刻认为 Leader 已死，自增 Term 发起选举。

  5. 打断与重试：原 Leader 收到更高 Term 的投票请求，立刻 Step Down。原本进行到一半的 Snapshot 传输直接断开。新 Leader 上位后，落后节点再次向新 Leader 请求快照，进入无解的死循环。

这种设计的愚蠢之处在于：把维持集群生存的“控制流”（Heartbeat）和极度消耗资源的“数据流”（Snapshot）混为一谈。

解决方案与防御性编程实践

修复这个工程设计缺陷，必须在代码和配置层面同时动刀。

1. 控制流与数据流解耦（Out-of-band Heartbeat）

在底层 RPC 实现中，心跳包必须拥有最高优先级的独立通道。在诸如 etcd 或现代定制的 Raft 实现中，通常会将心跳包（MsgBeat）与日志追加（MsgApp）放在不同的 Goroutine 或物理连接中。

// 错误示范：单通道处理所有 Raft 消息
func (r *RaftNode) processMessages() {
    for msg := range r.msgQueue {
        r.sendRPC(msg) // Snapshot 和 Heartbeat 在这里排队，互相阻塞
    }
}

// 防御性改造：优先队列或独立连接处理心跳
func (r *RaftNode) processHeartbeats() {
    for heartbeat := range r.heartbeatQueue {
        r.sendRPCWithHighPriority(heartbeat) 
    }
}

2. Snapshot 传输限流与分块（Chunking & Rate Limiting）

绝对不能让快照传输耗尽系统带宽或挤占磁盘 IOPS。对于几 GB 的文件，必须分 Chunk 传输，并且在 Chunk 之间主动 Yield，或者直接在应用层加上流控（Token Bucket）。

// Raft 引擎调优配置片段
{
    "snapshot_chunk_size": "4MB",
    "snapshot_rate_limit_mbps": 50, 
    "heartbeat_timeout": "100ms",
    "election_timeout": "1500ms"
}

注：适当拉开 election_timeout 和 heartbeat_timeout 的比例（建议 10:1 以上），能有效容忍偶发的网络抖动。

3. 开启 Pre-Vote 机制（防止僵尸节点扰乱集群）

虽然本次核心原因是 Leader 阻塞，但网络分区场景下，落后节点很容易因为无法连通 Leader 而疯狂增加 Term。一旦网络恢复，其携带的超大 Term 会瞬间迫使现任 Leader 下台。 必须在 Raft 引擎中开启 Pre-Vote 扩展协议：节点在正式增加 Term 发起选举前，先用当前的 Term 进行一轮“预投票”，只有能获得半数以上节点回应的前提下，才真正增加 Term 发起选举。

排查清单：Raft 集群假死同类问题速查

如果你的强一致性集群（etcd, Consul, TiKV, 自研 Raft）出现无规律的 Leader 频繁切换，直接核对以下几点：

  1. 磁盘 fsync 延迟排查：检查 Leader 的 wal_fsync_duration_seconds 指标。如果磁盘 IOPS 饱和（如 SATA 盘或云盘 IO 打满），fsync 超过 election_timeout，会导致本节点心跳发送失败而退位。

  2. 大包阻塞心跳（Head-of-line Blocking）：排查近期是否有大 KV 写入或新节点加入。检查 RPC 网络监控，确认心跳包（Empty AppendEntries）的 RTT 是否被大 Payload 同步拖垮。

  3. Pre-Vote 状态确认：检查集群配置是否强制开启了 Pre-Vote。如果没有开启，任何一个发生单向网络分区的 Follower 恢复后，都会引发一次集群强震。

  4. Ticker 假死 / CPU Starvation：检查宿主机是否发生了全局的 CPU Throttling（如 cgroup 配额不足）或 GC Pause（Java/Go）。这些运行时暂停如果超过了心跳超时周期，Raft 的心跳机制将彻底失效。

更多文章