etcd 架构速览：Raft 共识机制、WAL 日志、快照、MVCC、boltdb 存储引擎的 IO 路径

etcd 作为 Kubernetes 集群的“状态中枢”，其内部架构围绕强一致性与高可用性设计。理解 Raft 共识、WAL 日志、快照、MVCC 以及 boltdb 存储引擎之间的 IO 路径，是进行压测沙盘 IO 曲线复核与风险控制的基础。本节将拆解这些核心组件及其数据流动关系。

2.1 核心组件与职责

etcd 的存储架构可划分为三层：共识层、日志与状态机层、持久化引擎层。下表总结了各组件的关键职责与 IO 特征：

2.2 Raft 共识机制与 IO 触发

Raft 是 etcd 一致性的基石。一个写请求从客户端到达 Leader 后，会经历以下 IO 密集型步骤：

1. Leader 追加日志：Leader 将请求封装为 Entry，追加到自己的 WAL 中（本地顺序写 IO）。
2. 并行复制：Leader 通过 RPC 将 Entry 并行发送给所有 Follower（网络 IO）。
3. Follower 落盘：Follower 收到 Entry 后，同样追加到本地 WAL（本地顺序写 IO），并回复确认。
4. 提交与应用：Leader 收到多数派确认后，将 Entry 标记为已提交，并应用到状态机（boltdb 写入）。

2.3 WAL 日志：写入路径的第一道关口

WAL 是 etcd 的预写日志，所有数据修改必须先写入 WAL 才算安全。其 IO 模型为：

• 顺序追加：WAL 文件按段（segment）切割，每个段默认 64MB，写入模式为 O_APPEND，磁盘行为以顺序写为主。
• 强制刷盘：每次写入后，etcd 会调用 fsync 确保持久化。fsync 频率直接影响写入延迟。
• 日志条目格式：每条日志包含类型、数据、CRC 校验，结构紧凑。

// WAL 日志条目简化结构
type Entry struct {
    Term        uint64    // Raft 任期
    Index       uint64    // 日志索引
    Type        EntryType // 普通 Entry 或配置变更
    Data        []byte    // 序列化的请求数据
}

2.4 快照 (Snapshot)：压缩与恢复的 IO 权衡

随着 WAL 不断增长，etcd 会定期创建快照来压缩历史日志。快照机制涉及以下 IO 操作：

• 创建快照：etcd 将当前 boltdb 中的全量数据序列化，写入一个新的快照文件（顺序写 IO）。
• 裁剪 WAL：快照创建完成后，早于快照索引的 WAL 文件可以被安全删除，释放磁盘空间。
• 快照恢复：节点重启或新节点加入时，先加载快照文件（顺序读 IO），再重放快照点之后的少量 WAL。

2.5 MVCC 与 boltdb 存储引擎：最终状态持久化

etcd 使用 MVCC 管理 key 的多个版本，底层由 boltdb 实现持久化。其 IO 路径如下：

1. MVCC 写入：每次 put 操作会生成一个新的版本号（revision），并插入到 boltdb 的 B+ 树中。旧版本数据不会立即删除，而是标记为可回收。
2. boltdb 事务：boltdb 使用读写事务。读事务可并发，写事务串行执行。写事务会修改 B+ 树的 page，并最终通过 fsync 刷盘。
3. Page 分裂与合并：当 B+ 树节点超过 page 容量时，发生 page 分裂（随机写 IO），这是 boltdb 写放大和 IO 抖动的常见来源。
4. 压缩 (Compaction)：etcd 定期执行压缩，删除历史版本数据，回收 boltdb 中的空闲 page。压缩过程会遍历 B+ 树，产生大量随机读写 IO。

2.6 整体 IO 路径图

下图展示了从客户端请求到最终持久化的完整 IO 路径，以及各组件之间的数据流关系：

2.7 IO 路径总结与压测映射

将上述组件映射到压测沙盘的 IO 曲线复核中，可以归纳出以下风险控制要点：