1. etcd 基础架构：Raft 共识算法、节点角色与持久化机制
etcd 是一个高可用的分布式键值存储系统，其核心是 Raft 共识算法。理解 Raft 是分析 etcd 性能瓶颈、进行压测调优的前提。本节从 Raft 原理、节点角色、WAL 与快照机制三个维度展开。
1.1 Raft 共识算法原理
Raft 是一种用于管理复制日志的共识算法，它将共识问题分解为三个相对独立的子问题：领导者选举（Leader Election）、日志复制（Log Replication） 和 安全性（Safety）。etcd 使用 Raft 确保集群中所有节点数据最终一致。
Raft 将时间划分为不定长的 任期（Term），每个任期以一次选举开始。如果选举成功，该任期由新 Leader 管理；如果选举失败（如选票分裂），则立即进入下一个任期。
| 子问题 | 描述 | 性能影响 |
|---|---|---|
| 领导者选举 | 节点通过超时机制发起选举，获得多数票者成为 Leader。 | 选举超时时间影响故障恢复速度；频繁选举会降低可用性。 |
| 日志复制 | Leader 将客户端请求追加到日志，并行复制到 Follower。 | 网络延迟、磁盘 I/O 直接影响写入吞吐和延迟。 |
| 安全性 | 保证已提交的日志不会被覆盖，只有拥有最新日志的节点才能成为 Leader。 | 日志一致性检查增加少量开销，但保障数据安全。 |
1.2 节点角色：Leader / Follower / Candidate
etcd 集群中的每个节点在任意时刻都处于以下三种角色之一。角色转换由 Raft 协议驱动。
- Leader（领导者）：处理所有客户端请求（读写），管理日志复制，定期向 Follower 发送心跳以维持权威。
- Follower（跟随者）：被动接收来自 Leader 的日志复制和心跳，响应 Leader 的 AppendEntries RPC。如果长时间未收到心跳，Follower 会转换为 Candidate。
- Candidate（候选者）：Follower 在选举超时后转换为 Candidate，发起新一轮选举，向其他节点请求投票。获得多数票后成为 Leader。
1.3 WAL（Write-Ahead Log）与快照机制
etcd 通过 WAL（预写日志） 和 快照（Snapshot） 两种持久化机制保证数据不丢失，并控制磁盘空间占用。
1.3.1 WAL 预写日志
所有数据修改操作在应用到状态机之前，必须先追加到 WAL 文件。WAL 是顺序写入，对磁盘 I/O 性能敏感。WAL 文件按段（segment）管理，每个段文件达到一定大小（默认 64MB）后创建新文件。
- 写入流程： 客户端请求 → Leader 追加日志到 WAL → 并行复制到 Follower → 多数节点确认后提交 → 应用到状态机。
- 性能关键： WAL 的 fsync 频率直接影响写入延迟。etcd 默认每次写入都执行 fsync，保证崩溃恢复安全。
1.3.2 快照（Snapshot）
随着日志不断增长，WAL 文件会占用大量磁盘空间，且重启时需要重放所有日志，速度极慢。etcd 定期创建快照，将当前状态机数据持久化到文件，并丢弃快照点之前的 WAL 日志。
| 机制 | 作用 | 触发条件 | 压测影响 |
|---|---|---|---|
| WAL | 记录所有操作日志，保证崩溃恢复 | 每次写入操作 | 磁盘 I/O 瓶颈，fsync 延迟敏感 |
| Snapshot | 压缩日志，加速重启恢复 | 日志条目数达到阈值（默认 100,000） | 创建快照时 CPU 和磁盘 I/O 突增，可能引起延迟尖刺 |
--snapshot-count 参数（默认 100,000），适当增大可降低快照频率，但会占用更多磁盘空间。
1.4 小结
etcd 的基础架构围绕 Raft 共识算法构建：Leader 负责处理请求和日志复制，Follower 被动同步，Candidate 在选举超时后发起选举。WAL 保证数据持久性，快照控制日志增长。在压测调优中，需要重点关注 Leader 节点负载、WAL 磁盘 I/O 以及快照频率对延迟的影响。