3. etcd 基础架构：Raft 协议、WAL 日志、MVCC 存储引擎

etcd 作为云原生领域的“协调神经系统”，其底层架构围绕三个核心支柱构建：Raft 共识协议保证数据一致性，WAL（Write-Ahead Log，预写式日志）确保数据持久性，MVCC（Multi-Version Concurrency Control，多版本并发控制）存储引擎提供高效并发读写。理解这三者的协同机制，是进行性能调优与网络延迟分析的前提。

3.1 架构总览：三支柱协同

etcd 的请求处理路径可概括为：客户端请求 → Raft 节点间共识 → WAL 落盘 → MVCC 状态机应用。下图展示了这一核心流程：

3.2 Raft 协议：分布式共识的基石

Raft 是一种易于理解的分布式共识算法，etcd 使用它来确保集群中所有节点数据一致。Raft 将节点角色分为三种：

角色	职责	关键行为
Leader	处理所有客户端写入请求，管理日志复制	定期发送心跳（Heartbeat）维持权威；负责日志条目分发与提交
Follower	被动响应 Leader 和 Candidate 的请求	接收并追加日志；参与选举投票
Candidate	在选举阶段竞选 Leader	发起选举请求，收集多数派投票

3.3 WAL 日志：持久化的第一道防线

WAL（Write-Ahead Log）是 etcd 保证数据不丢失的核心机制。所有数据修改在应用到内存状态机之前，必须先写入 WAL 文件。其工作流程如下：

1. 追加写入：Leader 收到客户端请求后，将操作封装为日志条目，追加到本地 WAL 文件。
2. 并行复制：Leader 并行向所有 Follower 发送日志条目，等待多数派（Quorum）确认写入成功。
3. 提交确认：一旦多数派节点确认写入，Leader 标记该条目为“已提交”，并通知所有节点应用到状态机。
4. 文件分段：WAL 文件按段（Segment）管理，每段默认 64MB，写满后创建新段，旧段可被压缩或清理。

3.4 MVCC 存储引擎：并发控制与历史版本

etcd 使用基于 BoltDB（底层为 bbolt）的 MVCC 存储引擎，支持多版本并发控制。每个键值对都维护一个版本号（revision），实现无锁读取和历史查询。

3.4.1 核心数据结构

概念	说明	性能影响
Revision	全局单调递增的版本号，每次事务递增	用于 MVCC 版本标识和线性化读
Key-Value 存储	主索引：key → 最新版本 value	点查性能 O(log n)
历史版本桶	存储所有历史版本，用于 Watch 和范围查询	历史版本过多会膨胀存储，触发压缩
Lease（租约）	关联 key 的 TTL 机制，到期自动删除	大量短 TTL key 会增加 Lease 管理开销

3.4.2 读写路径对比

MVCC 引擎的读写路径差异显著，直接影响压测中的延迟分布：

• 读路径：客户端请求 → 线性化读（需 Raft 确认）或 串行化读（本地直接读取）→ MVCC 索引查找 → 返回数据。线性化读保证强一致性，但需要一次 Raft 交互。
• 写路径：客户端请求 → Raft 共识（多数派写入 WAL）→ MVCC 状态机应用 → 返回响应。写操作必须经过完整的 Raft 流程，延迟受网络和磁盘影响更大。

3.5 三组件交互时序

下图展示了一次完整写入请求在三个组件间的交互时序：

3.6 性能调优关键参数

针对 Raft、WAL、MVCC 三个组件，以下参数在压测中需要重点关注：

组件	参数	默认值	调优方向
Raft	--heartbeat-interval	100ms	网络延迟高时适当增大，避免误触发选举
Raft	--election-timeout	1000ms	至少为 heartbeat-interval 的 10 倍
WAL	--wal-sync	true	压测时可设为 false 观察性能上限，生产环境必须为 true
MVCC	--auto-compaction-retention	0（关闭）	根据历史版本保留需求设置，如 5m 表示保留 5 分钟
MVCC	--quota-backend-bytes	2GB	增大可减少压缩频率，但会占用更多内存