etcd 核心架构回顾：Raft 共识算法、MVCC、Watch 机制、BoltDB 存储引擎
在构建云原生日志平台的压测沙盘之前，必须深入理解 etcd 的四大核心支柱。etcd 作为分布式键值存储系统，其可靠性、一致性与高性能分别由 Raft 共识算法、MVCC 并发控制、Watch 事件机制以及 BoltDB 本地存储引擎共同保障。本节将逐一拆解这些组件的原理与协作关系，为后续压测指标分析与风险控制奠定基础。
2.1 Raft 共识算法：分布式一致性的基石
Raft 是一种用于管理复制日志的共识算法，它将共识问题分解为领导者选举、日志复制和安全性三个子问题。etcd 使用 Raft 确保集群中所有节点数据最终一致，即使部分节点故障也能保持可用性。
核心角色与任期： 每个节点在任意时刻处于 Leader、Follower 或 Candidate 三种状态之一。时间被划分为连续的任期（Term），每个任期最多只有一个 Leader。
- 领导者选举： Follower 在选举超时后转为 Candidate，发起投票请求。获得多数派（quorum）投票的节点成为 Leader。
- 日志复制： Leader 接收客户端写请求，将操作封装为日志条目，并行复制到所有 Follower。当日志条目被多数节点持久化后，Leader 提交该条目并应用到状态机。
- 安全性： Raft 通过“只有拥有最新日志的节点才能成为 Leader”以及“日志提交必须由 Leader 发起”等规则保证一致性。
2.2 MVCC：多版本并发控制
etcd 采用 MVCC（Multi-Version Concurrency Control）机制管理键值对的历史版本。每次写操作都会生成一个新的版本号（revision），旧版本数据不会被立即覆盖，而是保留以供历史查询或 Watch 事件回溯。
| 概念 | 说明 | 压测影响 |
|---|---|---|
| Revision | 全局单调递增的版本号，每次事务递增 | 高并发写入导致 revision 快速增长，影响存储空间 |
| KeyValue | 每个键值对包含 create_revision、mod_revision、version | 频繁更新导致 version 递增，Watch 事件量增大 |
| 历史版本 | 旧版本数据存储在 BoltDB 中，通过 revision 索引 | 历史版本堆积可能导致磁盘空间膨胀和查询性能下降 |
| Compact | 手动或自动压缩历史版本，释放存储空间 | 压缩操作本身消耗 I/O，需在低峰期执行 |
压测提示： 在日志平台场景下，大量日志索引的频繁更新会产生海量历史版本。务必监控
etcd_server_history_count 指标，并合理配置 --auto-compaction-retention 参数，避免存储爆炸。
2.3 Watch 机制：事件驱动的核心
Watch 是 etcd 提供的一种观察者模式，客户端可以监听特定键或前缀的变化。当被监听的键发生创建、更新或删除操作时，etcd 会向客户端推送事件。这是云原生日志平台实现配置热更新、服务发现和日志路由动态调整的基础。
- Watch 类型： 支持单键 Watch、前缀 Watch（WithPrefix）和范围 Watch（WithRange）。
- 事件流： 客户端通过 gRPC 流式接口接收事件，支持从指定 revision 开始回溯历史事件。
- 性能考量： 每个 Watch 都会在 etcd 内存中维护一个观察者对象，大量 Watch 连接会消耗内存和 CPU。
风险警示： 压测时如果创建大量短生命周期的 Watch（例如每次请求都新建 Watch 然后立即关闭），会导致 etcd 频繁进行观察者注册和注销，可能引发内存碎片和 GC 压力。建议使用长连接 Watch 并复用。
2.4 BoltDB 存储引擎：本地持久化
etcd 使用 BoltDB 作为底层存储引擎，这是一个基于 B+ 树的嵌入式键值数据库，提供 ACID 事务支持。etcd 的所有数据（包括键值对、历史版本、元数据）最终都持久化在 BoltDB 文件中。
| 特性 | 描述 | 压测关注点 |
|---|---|---|
| B+ 树结构 | 数据按 key 有序存储，支持范围查询 | 大量随机写入可能导致 B+ 树频繁分裂，影响写入性能 |
| 事务隔离 | 支持读写事务，读事务不阻塞写事务 | 长事务会阻塞 BoltDB 文件增长和压缩操作 |
| 文件映射 | 通过 mmap 将数据文件映射到内存 | 内存映射区域过大可能导致 OOM，需监控 db 大小 |
| 预写日志（WAL） | 先写 WAL 再写数据文件，保证崩溃恢复 | WAL 写入延迟直接影响写吞吐量 |
2.5 四大组件协同工作流
当客户端发起一次写操作时，上述四个组件按照严格的顺序协同工作：
- 客户端通过 gRPC API 发送 Put 请求到 etcd 节点。
- Raft 模块将请求封装为日志条目，通过领导者选举和日志复制确保多数节点持久化。
- 日志提交后，MVCC 模块生成新的 revision，并将键值对的新版本写入内存缓存。
- BoltDB 模块将数据以 B+ 树形式持久化到磁盘文件，同时更新 WAL。
- 如果该键上有 Watch 监听，etcd 会异步将事件推送给客户端。
压测沙盘启示： 在日志平台场景下，写操作是核心负载。Raft 的日志复制延迟、MVCC 的历史版本堆积、Watch 的事件推送能力以及 BoltDB 的磁盘 I/O 性能，共同决定了 etcd 集群的承载上限。后续章节的观测面板将围绕这四个组件的关键指标进行设计。