3. etcd 架构总览：组件分层与请求处理流程
etcd 是一个高度模块化的分布式键值存储系统，其内部架构按照职责清晰划分为四个核心层次：API 层、Raft 层、存储层和WAL 层。理解每一层的职责以及它们之间的协作关系，是分析 etcd 性能瓶颈的基础。
3.1 组件分层架构
下图展示了 etcd 的完整组件分层结构，以及各层之间的数据流向。
3.2 各层核心职责
| 层次 | 核心组件 | 主要职责 | 性能关键点 |
|---|---|---|---|
| API 层 | gRPC Server、HTTP Gateway | 接收客户端请求，进行协议转换、认证鉴权、请求校验 | 序列化/反序列化开销、连接数管理 |
| Raft 层 | Raft Node、RaftLog、状态机 | 实现 Raft 共识算法：Leader 选举、日志复制、日志提交 | 网络 RTT、日志条目批量大小、心跳间隔 |
| 存储层 | MVCC、TreeIndex、BoltDB | 多版本键值管理、事务执行、数据持久化 | BoltDB 事务提交频率、索引查找效率、磁盘随机写 |
| WAL 层 | WAL 文件、日志编码器 | 顺序写入 Raft 日志条目，保证崩溃恢复时的数据完整性 | fsync 频率、磁盘顺序写吞吐量、日志文件轮转 |
3.3 请求处理流程全景图
一个典型的 etcd 写入请求（如 Put）会依次穿越上述四个层次。下图展示了完整的请求处理流程。
3.4 请求处理步骤详解
- 客户端发起请求：客户端通过 gRPC 调用
Put、Range、Delete等接口，请求到达 API 层。 - API 层处理：gRPC Server 接收请求，进行 协议解码（Protobuf → 内部结构）、请求校验（key 长度、权限检查）、限流判断。校验通过后，将请求转发给 Raft 层。
- Raft 层共识：如果当前节点是 Leader，则将请求封装为 Raft 日志条目，追加到本地的 RaftLog 中。Leader 并行向所有 Follower 发送
AppendEntriesRPC，等待多数派（quorum）确认写入成功。 - WAL 层持久化：每个节点在收到日志条目后，首先将其 顺序追加 到 WAL 文件中，并调用
fsync刷盘。这一步是 etcd 写入延迟的主要来源之一。 - 存储层应用：当日志条目被 Raft 层标记为“已提交”（committed）后，状态机会将日志应用到存储层。存储层执行 MVCC 写入：创建新的版本记录，更新 TreeIndex，最后将数据写入 BoltDB 事务并提交。
- 返回响应：存储层写入完成后，Raft 层向 API 层返回成功信号，API 层将响应序列化后返回给客户端。
性能关键洞察： 在上述流程中，步骤 4（WAL fsync） 和 步骤 5（BoltDB 事务提交） 是磁盘 I/O 最密集的环节。WAL 写入是顺序 I/O，延迟相对可控；而 BoltDB 的 B+ 树写入涉及随机 I/O，在磁盘性能不足时容易成为瓶颈。Raft 层的网络 RTT 和日志批量大小则决定了共识阶段的吞吐上限。
3.5 各层之间的数据流与依赖
| 数据流方向 | 传递内容 | 同步/异步 | 性能影响 |
|---|---|---|---|
| API 层 → Raft 层 | 序列化后的请求结构（Proposal） | 同步调用 | 序列化开销、请求排队 |
| Raft 层 → WAL 层 | Raft 日志条目（已序列化） | 同步写入 + fsync | 磁盘顺序写延迟、fsync 频率 |
| Raft 层 → 存储层 | 已提交的日志条目（Apply） | 异步批量应用 | Apply 协程处理速度、BoltDB 事务合并 |
| 存储层 → 磁盘 | BoltDB 数据页 | 事务提交时同步写盘 | 磁盘随机写性能、BoltDB 页面分裂 |
注意： Raft 层与 WAL 层之间的同步 fsync 是 etcd 写入延迟的 硬性约束。即使使用 NVMe SSD，单次 fsync 延迟也在微秒到毫秒级别。如果 WAL 和 BoltDB 共用同一块磁盘，两者之间的 I/O 竞争会进一步加剧延迟波动。在生产环境中，建议将 WAL 和数据文件分离到不同的磁盘设备上。