etcd 架构速览：Raft 共识算法、WAL 日志、快照与 MVCC
etcd 是一个高可用的分布式键值存储，其核心架构围绕 强一致性 与 高可靠性 设计。理解其底层机制是制定灾备策略、优化 RPO 的基础。本节将拆解 etcd 的四大核心组件：Raft 共识算法、WAL 日志、快照 (Snapshot) 以及 MVCC 机制。
1. Raft 共识算法：集群的“决策引擎”
Raft 是 etcd 实现数据一致性的基石。它将集群中的节点分为三种角色：Leader、Follower 和 Candidate。所有写操作必须由 Leader 处理，并通过日志复制同步到多数节点。
关键指标： 集群容忍故障节点数为 (N-1)/2。例如 3 节点集群可容忍 1 个节点故障，5 节点集群可容忍 2 个。
工程启示： 灾备场景下，若主集群完全不可用，需通过 Raft 重新选举或切换至备份集群。RPO 受限于日志同步的延迟与快照恢复速度。
2. WAL 日志：写入的“安”
WAL (Write-Ahead Log) 是 etcd 持久化的核心。所有数据修改在应用到内存状态机之前，必须先顺序写入 WAL 文件。这保证了即使系统崩溃，也能通过重放 WAL 恢复数据。
| 特性 | 说明 | 灾备影响 |
|---|---|---|
| 顺序追加 | 日志条目按时间顺序追加到文件末尾，无随机写 | 写入性能高，但日志文件会持续增长 |
| 持久化策略 | 可配置每次写入或定期 fsync | 每次 fsync 保证零数据丢失，但增加延迟 |
| 日志条目 | 包含 term、index、操作类型、数据 | 恢复时需从初始状态重放所有条目 |
RPO 风险点： 若仅依赖 WAL 恢复，当 WAL 文件过大时，重放时间会显著增加，导致 RPO 恶化。必须配合快照使用。
3. 快照 (Snapshot)：加速恢复的“检查点”
快照是 etcd 在某个时间点对内存数据库的完整拷贝。它记录了当前状态，并记录了该状态对应的日志索引。快照生成后，之前的 WAL 日志可以被安全清理。
- 触发条件： 默认当 WAL 日志条目数超过 10,000 时自动触发快照。
- 文件结构： 快照文件包含元数据（最后包含的日志索引、term）和数据库状态。
- 恢复流程： 加载最新快照 → 重放快照之后的 WAL 日志 → 恢复至最新状态。
优化要点： 调整快照间隔（--snapshot-count）可平衡磁盘空间与恢复速度。更频繁的快照减少日志重放量，但增加 I/O 开销。
4. MVCC 机制：并发控制的“时间旅行者”
etcd 使用多版本并发控制 (MVCC) 管理数据。每次写操作不是原地更新，而是创建一个新版本的数据，并保留旧版本。每个版本关联一个全局递增的 revision（修订号）。
- 读操作： 可指定 revision 读取历史数据，实现“快照读”。
- 写操作： 生成新版本，旧版本数据保留在 backend 中。
- 压缩 (Compaction)： 定期清理旧版本数据，防止存储无限增长。
| 概念 | 说明 | 运维关注点 |
|---|---|---|
| Revision | 全局单调递增的版本号 | 用于实现分布式锁、事务、监听 |
| Key-Value 历史 | 每个 key 可保留多个历史版本 | 未压缩的历史版本占用磁盘空间 |
| Compaction | 删除指定 revision 之前的所有历史版本 | 需定期执行，否则磁盘会写满 |
灾备关联： 备份时若使用 etcd 的 snapshot API，会包含当前所有版本数据。若使用 etcdctl 的 watch 或增量备份，需注意 revision 的连续性，避免因 compaction 导致数据断层。
5. 架构总结：组件协同关系
etcd 的写入路径完整展示了各组件如何协同工作：
- 客户端请求 发送至 Leader 节点。
- Leader 追加日志 到 WAL 文件，并并行复制到 Follower。
- 多数节点确认 后，日志条目被提交。
- 应用到内存状态机，数据通过 MVCC 生成新版本。
- 快照 定期将内存状态持久化，并清理旧 WAL。
核心结论： Raft 保证一致性，WAL 保证持久性，快照保证恢复效率，MVCC 保证并发读写的隔离性。四者共同决定了 etcd 的灾备能力与 RPO 上限。