Raft 是当今工业界应用最广泛的分布式共识算法，而 etcd 则是它最经典的落地实现之一。Kubernetes 的元数据、CoreDNS 的配置、各类微服务框架的服务发现，几乎都跑在 etcd 之上。要理解 etcd 为什么能在网络抖动、节点宕机的情况下依然保证数据不丢不乱，就必须理解它内部的 Raft 模块。这篇文章从协议原理讲到工程实现，再落到日常运维中的调优和排障，帮你把 Raft 从纸面概念变成可操作的知识。
Raft 协议的核心机制：选举、日志复制与安全性
Raft 把一致性问题分解成三个相对独立的子问题：领导者选举、日志复制和安全性约束。etcd 的 raft 库（go.etcd.io/raft）完整实现了这三部分，代码不到三千行，是学习 Raft 的最佳教材之一。
先说选举。Raft 集群中的每个节点处于三种角色之一：Leader、Follower、Candidate。所有写请求都由 Leader 处理，因此选出唯一的 Leader 是一切的前提。节点默认是 Follower，如果在 election timeout 时间内没收到 Leader 的心跳，就转变为 Candidate 并发起投票。Candidate 递增自己的任期号 term，向其他节点发送 VoteRequest。拿到多数派选票的 Candidate 成为新 Leader。这里有个关键细节：term 是 Raft 中的逻辑时钟，节点发现收到的消息 term 比自己大，会立刻更新自己的 term 并退回 Follower 状态，这个机制保证了过期的旧 Leader 无法继续作出有效决策。
再看日志复制。客户端的写请求到达 Leader 后，Leader 不是立即提交，而是把操作封装成日志条目，先持久化到本地 WAL，然后并行发给所有 Follower。Follower 会检查日志的前后连接性：只有当新条目的 prevLogIndex 和 prevLogTerm 与自己日志中对应位置匹配时才接受追加，否则拒绝。Leader 收到多数派的成功响应后，将该条目标记为 committed，应用到状态机，并在后续心跳中通知 Follower 同步提交进度。这个多数派确认的机制正是 Raft 容忍节点故障的基础：一个 3 节点集群最多容忍 1 个节点故障，5 节点集群容忍 2 个。
package main
import (
"context"
"go.etcd.io/etcd/clientv3"
"time"
)
func main() {
cli, err := clientv3.New(clientv3.Config{
Endpoints: []string{"http://127.0.0.1:2379"},
DialTimeout: 5 * time.Second,
})
if err != nil {
panic(err)
}
defer cli.Close()
// etcd 中的每一个 Put 操作，背后都是一次完整的 Raft 日志复制流程
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
_, err = cli.Put(ctx, "/demo/key", "hello-raft")
cancel()
if err != nil {
panic(err)
}
}最后是安全性约束。Raft 通过几个投票和提交规则保证已提交的日志永远不会被覆盖：候选者必须比自己拥有更完整的日志才能获得投票；Leader 只提交当前任期内的日志条目，之前任期条目的提交是随当前任期条目的提交间接完成的。这些规则组合起来，避免了协议设计中那些容易被忽略的边界漏洞。
etcd 对 Raft 的工程实现：WAL、快照与存储分层
论文里的 Raft 是抽象的，etcd 的实现则要面对磁盘、网络、快照等一系列现实问题。etcd 将共识层与存储层解耦：raft 库本身不操作磁盘，它通过 Ready 结构体把需要上层处理的事情打包输出，由 etcdserver 负责真正的持久化和网络发送。
WAL（Write-Ahead Log）是保证数据不丢的第一道防线。每条 Raft 日志在发送给 Follower 之前，Leader 必须先把条目 fsync 到 WAL 文件。这意味着写入吞吐直接受磁盘 fsync 性能制约，生产环境强烈建议使用 SSD。WAL 文件按段切分，默认每 64MB 一个段文件，可以通过 --wal-segment-bytes 调整。极端情况下，如果需要恢复数据，可以使用 etcdctl snapshot restore 或直接从 WAL 目录回放。
快照机制解决的是日志无限增长的问题。Raft 日志如果一直累积，新加入的节点就需要重放全部历史日志，启动成本会越来越高。etcd 在日志超过一定数量后触发快照，默认是十万条（参数 --snapshot-count），把状态机的当前状态完整序列化成 snapshot 文件，之后就可以安全地截断旧日志。当一个落后的 Follower 需要的数据已经被截断时，Leader 会通过 InstallSnapshot 消息直接把快照传给它，而不是逐条补日志。
存储层方面，etcd v3 使用 MVCC 多版本模型，键值对保存在内嵌的 BoltDB（v3.4 起改为 bbolt）中，每个键的每次修改都生成一个递增的 revision。Raft 保证的是修改顺序在所有节点上一致，MVCC 则在此基础上提供历史版本查询和事务能力。理解这个分层很重要：Raft 层面的一致与业务层面看到的一致存在一个窗口，客户端写入成功后立刻读另一个节点，可能读到旧数据，除非使用串行读或指定 revision 读。
参数调优与生产环境排障实战
etcd 的 Raft 相关参数直接影响集群的可用性和性能，其中最重要的两个是心跳间隔和选举超时。默认配置中心跳为 100ms，选举超时为 1000ms。心跳太频繁会增加网络与 CPU 开销，太稀疏则可能触发误选举；选举超时一般建议设置为心跳间隔的 10 倍左右，并且要大于跨机房的典型往返延迟。跨地域部署时，如果网络抖动经常超过 1 秒，可以把心跳调到 300ms、选举超时调到 5000ms，代价是故障时的主从切换变慢。
# 启动一个调优后的 etcd 节点 etcd --name infra-node1 \ --initial-advertise-peer-urls http://192.168.0.1:2380 \ --listen-peer-urls http://192.168.0.1:2380 \ --listen-client-urls http://192.168.0.1:2379 \ --initial-cluster infra-node1=http://192.168.0.1:2380,infra-node2=http://192.168.0.2:2380,infra-node3=http://192.168.0.3:2380 \ --heartbeat-interval 300 \ --election-timeout 5000 \ --snapshot-count 50000 \ --quota-backend-bytes 8589934592
日常排障时，etcdctl endpoint status 是最常用的命令，重点看三个字段：leader 所在节点、Raft term 和 raftIndex。term 频繁递增说明集群在反复选举，通常是网络问题或节点负载过高导致心跳超时。raftIndex 长时间不增长则说明多数派中有节点不可用，写入会被阻塞。如果出现脑裂导致的旧 Leader，不必惊慌，Raft 的 term 机制会让它在联系到新 Leader 后自动下台，其未提交的日志会被丢弃，已提交的数据不受影响。
成员变更是另一个高风险操作。摘除节点前务必确认集群剩余节点数仍构成多数派，3 节点集群绝不能同时摘两个。添加节点时建议先 member add 再启动新节点，新节点会通过快照加增量日志追平进度。数据库大小方面，默认配额 2GB 触发告警、达到配额后集群进入只读保护，这实际上也是 Raft 层面的一种自我保护——避免落后的节点永远追不上日志。运维实践中，配合磁盘监控、fsync 延迟监控和 --experimental-initial-corrupt-check 一致性校验，可以在故障演变成数据问题之前及时发现异常。
总结来看，Raft 在 etcd 中的实现是算法理论与工程打磨结合的典范：选举机制解决谁说了算，日志复制保证多数派一致，WAL 和快照处理持久化与恢复，参数调优和监控保障生产可用。把这些环节串起来理解，你对分布式一致性的认识就不再停留在概念层面了。