4. etcd 写入路径深度解析：客户端请求 → gRPC → Raft 提案 → WAL 写入 → boltdb 提交

理解 etcd 的完整写入路径是性能调优的基础。每一次键值写入操作，都会经历一条严格串行的内部管道。这条路径上的每一个环节都可能成为瓶颈，直接影响写入延迟和吞吐量。下面我们逐层拆解这条路径，并分析每个阶段对磁盘 IO 和网络延迟的敏感度。

4.1 写入路径全景：五阶段流水线

一个典型的 etcd 写入请求（例如 etcdctl put key value）在 etcd 内部会依次经过以下五个核心阶段：

4.2 阶段详解与 SVG 流程图

下图展示了从客户端发起请求到数据最终落盘的完整内部流程，以及各阶段之间的数据传递关系：

4.3 各阶段深度剖析

4.3.1 客户端请求 → gRPC

• 序列化与连接：客户端将 PutRequest 序列化为 protobuf 格式，通过 HTTP/2 流式连接发送到 etcd 服务端。
• 性能要点：连接复用（keepalive）和请求批处理可以显著降低此阶段的网络开销。压测时，客户端连接数不足会导致延迟飙升。

4.3.2 gRPC 服务端 → Raft 提案

• 拦截器链：etcd 的 gRPC 拦截器会执行鉴权、限流、指标采集等操作。这些操作虽然轻量，但在高并发下会成为 CPU 瓶颈。
• 提案生成：KV Server 将写入请求封装为 Raft 提案（Proposal），并提交给 Raft 状态机。此过程需要获取当前集群的 Leader 信息。

4.3.3 Raft 提案：网络延迟的核心战场

• 日志复制：Leader 将提案广播给所有 Follower，等待多数派（quorum）确认写入成功。
• 延迟公式：写入延迟 ≈ 2 × RTT（Leader ↔ Follower）+ WAL fsync 延迟 + boltdb fsync 延迟。
• 集群规模影响：3 节点集群需要 2 个节点确认；5 节点集群需要 3 个节点确认。节点越多，网络延迟影响越大。

4.3.4 WAL 写入：顺序 IO 的守护者

• 写入模式：WAL 是顺序追加写入，理论上磁盘吞吐量很高。但每次写入后的 fsync 调用是真正的性能杀手。
• 磁盘 IO 延迟：HDD 的 fsync 延迟通常在 5-15ms，SSD 在 0.1-1ms，NVMe 在 0.02-0.1ms。这是 etcd 写入延迟的底线。
• 批量合并：etcd 会将多个提案合并为一次 WAL 写入，减少 fsync 次数。压测时，写入负载越高，批量效果越明显。

4.3.5 boltdb 提交：B+ 树的持久化

• B+ 树写入：boltdb 将键值对写入内存中的 B+ 树页缓存，然后定期刷盘。
• 随机写特征：与 WAL 的顺序写不同，boltdb 的 page 刷盘是随机 IO 模式，对磁盘性能要求更高。
• 两次 fsync：一次在 WAL 阶段，一次在 boltdb 提交阶段。这是 etcd 写入路径中不可避免的两次磁盘同步开销。

4.4 写入路径中的关键时序对比

下表对比了不同磁盘介质和网络条件下，各阶段的典型延迟分布（单位：微秒）：

4.5 写入路径的异步与同步边界

etcd 的写入路径并非完全同步。理解异步边界有助于正确解读压测结果：

4.6 压测视角的路径总结

1. 磁盘 IO 瓶颈：WAL 和 boltdb 的 fsync 延迟是写入延迟的下限。使用高性能 NVMe 磁盘可以将此延迟降低到 50µs 级别。
2. 网络延迟瓶颈：Raft 提案阶段的多数派通信延迟是写入延迟的上限。跨可用区部署时，网络 RTT 可能达到 1-10ms，成为压倒性因素。
3. 批量效应：高并发写入时，etcd 会自动合并提案和 WAL 写入，降低单次 fsync 的开销。压测时，低 QPS 场景的延迟反而可能更高。
4. 异步提交：boltdb 的刷盘是异步的，不会阻塞客户端响应。但若 boltdb 写入积压，会导致内存压力增大，最终影响稳定性。