3. etcd 架构解剖：gRPC API层、Raft共识层、存储引擎（boltdb/bbolt）、WAL预写日志

etcd 是一个高度模块化的分布式键值存储系统，其内部架构可以清晰地划分为四个核心层次。理解每一层的职责与交互方式，是进行精准压测与性能调优的前提。本章将自上而下地解剖 etcd 的架构，重点分析 gRPC API 层、Raft 共识层、存储引擎（boltdb/bbolt）以及 WAL 预写日志。

3.1 四层架构总览

下图展示了 etcd 的核心分层架构，以及请求从客户端到持久化存储的完整路径。

3.2 gRPC API 层：系统的门面

gRPC API 层是 etcd 对外暴露的唯一接口。所有客户端请求（无论是读写还是集群管理）都必须通过这一层进入系统。该层基于 Protocol Buffers 定义服务接口，并利用 gRPC 框架提供高性能的远程过程调用能力。

3.2.1 核心服务与接口

3.2.2 请求处理流程

1. 反序列化与校验： gRPC 框架将客户端发来的 Protobuf 字节流反序列化为请求对象，并进行基本的参数校验（如键名长度、请求 ID 合法性）。
2. 拦截器链： 请求依次通过认证拦截器（检查证书/）、限流拦截器（判断是否超出配额）、日志拦截器等。
3. 路由分发： 根据请求类型（读/写/维护），将请求分发到对应的后端处理器。
4. 序列化响应： 处理完成后，将结果序列化为 Protobuf 格式，通过 gRPC 流返回给客户端。

3.3 Raft 共识层：分布式一致性的核心

Raft 层是 etcd 实现分布式一致性的基石。它负责将客户端的写请求转化为 Raft 日志条目，并在集群节点间达成共识。该层直接决定了系统的写入延迟、可用性和数据一致性。

3.3.1 关键组件与角色

• Node： Raft 节点的抽象，负责管理状态机、日志和选举定时器。
• Raft Log： 有序的日志条目集合，每个条目包含一个提议（Proposal）和任期号（Term）。
• Leader： 处理所有客户端写请求，负责日志复制和提交决策。
• Follower： 被动接收来自 Leader 的日志复制请求（AppendEntries）和心跳。
• Candidate： 选举过程中的临时角色，用于发起新一轮 Leader 选举。

3.3.2 写入流程（Propose → Commit → Apply）

一个典型的写入请求在 Raft 层经历以下三个阶段：

1. Propose（提议）： Leader 收到写请求后，将其封装为一个 Raft 日志条目，并追加到自己的日志中。
2. Append & Commit（复制与提交）： Leader 并行向所有 Follower 发送 AppendEntries RPC。当 Leader 收到多数派（quorum）节点的成功响应后，该日志条目被标记为已提交（Committed）。
3. Apply（应用）： Leader 将已提交的日志条目应用到状态机（即存储引擎）中，并返回结果给客户端。

3.4 WAL 预写日志：持久化的第一道防线

WAL（Write-Ahead Log）是 etcd 保证数据不丢失的关键机制。在 Raft 日志条目被应用到状态机之前，必须首先持久化到 WAL 文件中。这种“先写日志，后写状态机”的策略确保了系统在崩溃后能够通过回放 WAL 恢复到一致状态。

3.4.1 WAL 文件结构

• 日志文件： 以 .wal 为后缀，按顺序编号（如 0000000000000001-0000000000000000.wal）。
• 日志记录： 每条记录包含日志类型（如 raftLogEntry、metadata、snapshot）、数据内容和 CRC 校验码。
• 快照截断： 为防止 WAL 文件无限增长，etcd 会定期创建快照（Snapshot），并删除快照之前的 WAL 文件。

3.4.2 写入策略与性能

3.5 存储引擎（bbolt）：最终状态机

bbolt 是 etcd 使用的嵌入式键值存储引擎，它是 BoltDB 的 Go 语言实现分支。bbolt 负责存储经过 Raft 层提交并应用后的最终数据，即 etcd 的“状态机”。

3.5.1 bbolt 核心特性

• B+树结构： 数据以 B+树形式组织，支持高效的键值查找、范围扫描和顺序遍历。
• 事务支持： 提供 DB.Begin(true)（读写事务）和 DB.Begin(false)（只读事务）。同一时刻只允许一个读写事务，但允许多个只读事务并发执行。
• 内存映射文件： 通过 mmap 系统调用将数据库文件映射到进程地址空间，减少用户态与内核态的数据拷贝。
• 无 WAL 机制： bbolt 本身不维护 WAL，其持久化依赖于底层的 fsync 调用。etcd 的 WAL 层已经保证了日志的持久性，bbolt 只需保证最终状态的一致性。

3.5.2 读写事务与并发模型

bbolt 的并发模型对 etcd 的读写性能有直接影响：

• 读写事务（RW Transaction）： 持有排他锁，阻塞所有其他读写事务和只读事务。etcd 的 apply 协程会以读写事务的方式将已提交的 Raft 日志写入 bbolt。
• 只读事务（RO Transaction）： 持有共享锁，不阻塞其他只读事务，但会被读写事务阻塞。etcd 的读请求（如 Range）通常使用只读事务。

3.6 四层交互与性能影响总结

下表总结了每一层在请求路径中的角色、关键性能指标以及常见的压测瓶颈。