2. etcd 核心架构与 Raft 协议精讲：深入剖析 etcd 的存储引擎、MVCC、Raft 共识算法在压测中的行为

在压测场景下，etcd 的每一个组件都可能成为瓶颈。理解其核心架构——从底层的存储引擎、多版本并发控制（MVCC）到顶层的 Raft 共识算法——是精准定位 K8s 集群瓶颈的前提。本节将拆解 etcd 的读写路径，并分析在高压下各模块的行为特征。

2.1 etcd 整体架构分层

etcd 的逻辑架构可划分为四层，每一层在压测中表现出不同的压力特征：

2.2 存储引擎：BoltDB 与 B+ 树

etcd 的持久化存储基于 BoltDB，一个嵌入式的、支持 ACID 事务的 KV 存储引擎，底层使用 B+ 树组织数据。在压测中，BoltDB 的行为直接影响写入延迟和空间回收效率。

• Page 管理： BoltDB 将数据划分为固定大小的 Page（默认 4KB）。B+ 树的节点（Branch/Leaf）存储在 Page 中。频繁的插入和更新会导致 Page 分裂与合并，产生写放大。
• 事务隔离： 支持串行化隔离级别。etcd 的 Backend 模块会合并多个写事务，减少 BoltDB 的事务提交次数，但合并窗口过大会增加读延迟。
• 空闲列表（Freelist）： 删除操作释放的 Page 会进入 Freelist。压测中大量创建/删除 Key 会导致 Freelist 膨胀，影响后续分配性能。

2.3 MVCC：多版本并发控制与 Revision

etcd 通过 MVCC 实现高效的并发读写，每个 Key 的每次修改都会生成一个新的版本（Revision）。在压测中，MVCC 的行为直接决定了内存消耗和查询性能。

2.4 Raft 共识算法：Leader 选举与日志复制

Raft 是 etcd 分布式一致性的基石。在压测中，Raft 的行为决定了集群的可用性和写入吞吐上限。理解 Raft 在高压下的表现，是定位集群瓶颈的核心能力。

2.4.1 核心角色与状态

• Leader： 处理所有客户端写入请求，负责日志复制。压测中 Leader 的 CPU 和网络带宽最先达到瓶颈。
• Follower： 被动复制日志，处理只读请求。Follower 的磁盘 IO 可能成为读延迟的瓶颈。
• Candidate： 选举过程中的临时角色。频繁的选举通常意味着网络分区或磁盘抖动。

2.4.2 压测中的关键 Raft 行为

2.5 压测瓶颈定位清单

结合上述架构分析，以下是在压测中快速定位 etcd 瓶颈的检查清单：

1. 检查 Raft 提案积压： etcd_server_proposals_pending > 100 时，说明写入速度超过集群处理能力。
2. 检查磁盘延迟： etcd_disk_wal_fsync_duration_seconds 的 p99 超过 10ms，磁盘是瓶颈。
3. 检查 MVCC 版本膨胀： etcd_mvcc_db_total_size_in_use_bytes 与 etcd_mvcc_db_total_size_bytes 差距过大，需要调整 Compaction 策略。
4. 检查网络延迟： 节点间 RTT 超过 50ms 时，Raft 选举稳定性下降。
5. 检查内存使用： TreeIndex 内存占用过高（超过 2GB）时，考虑拆分 Key 空间或使用 etcd v3.5+ 的 --max-request-bytes 限制。