2. etcd 架构深度解析：Raft、BoltDB、Watch、Lease 与 MVCC

etcd 是 Kubernetes 集群的“大脑”，所有集群状态、调度决策、资源元数据都持久化在 etcd 中。理解 etcd 的内部架构，是进行跨集群调度压测、性能调优以及故障排查的基石。本章将深入剖析 etcd 的五大核心组件：Raft 共识算法、BoltDB 存储引擎、Watch 机制、Lease 机制以及MVCC 多版本并发控制。

2.1 Raft 共识算法：分布式一致性的基石

etcd 使用 Raft 算法来保证集群中多个节点之间的数据一致性。Raft 是一种易于理解的共识算法，它将问题分解为领导者选举、日志复制和安全机制三个子问题。

2.1.1 节点角色与状态转换

在任意时刻，Raft 集群中的每个节点都处于以下三种角色之一：

2.1.2 日志复制与提交

当客户端向 Leader 发送一个写请求（如 put key value）时，Raft 通过以下步骤确保日志被安全复制到多数节点：

1. 追加日志：Leader 将请求封装为一个日志条目，追加到自己的本地日志中。
2. 并行广播：Leader 并行向所有 Follower 发送 AppendEntries RPC，包含该日志条目。
3. 多数确认：Follower 收到后追加到本地日志，并回复确认。当 Leader 收到超过半数（含自身）的确认后，该日志条目进入“已提交”（Committed）状态。
4. 应用状态机：Leader 将已提交的日志应用到自己的状态机（即 BoltDB），并通知 Follower 该日志已提交，Follower 随后也应用到自己的状态机。
5. 响应客户端：Leader 向客户端返回写入成功。

2.2 BoltDB 存储引擎：持久化与 B+ 树

etcd 使用 BoltDB 作为其底层持久化存储引擎。BoltDB 是一个纯 Go 语言实现的、嵌入式、ACID 兼容的键值数据库，其核心数据结构是 B+ 树。

2.2.1 B+ 树结构

BoltDB 将数据组织在多个 B+ 树中。每个事务（Transaction）对应一个 B+ 树的根节点。B+ 树的特点包括：

• 所有数据存储在叶子节点：内部节点只存储键（Key）和指向子节点的指针，不存储实际值（Value），这使得内部节点可以容纳更多键，降低树的高度。
• 叶子节点形成有序链表：所有叶子节点通过指针串联成一个双向链表，便于范围查询（Range Query）和顺序遍历。
• 高扇出（Fan-out）：每个节点通常包含数百个键，使得一个 3 层或 4 层的 B+ 树即可存储数百万个键值对。

2.2.2 事务与 ACID 特性

BoltDB 支持两种事务模式：

BoltDB 通过 写前日志（WAL） 和 崩溃恢复 机制保证持久性和原子性。所有写操作先写入 WAL，再写入 B+ 树，确保系统崩溃后数据可恢复。

2.3 Watch 机制：事件驱动的核心

Watch 机制是 etcd 实现服务发现、配置变更通知的关键。它允许客户端监听某个键或某个前缀的变化，当数据发生变化时，etcd 会实时推送事件给客户端。

2.3.1 Watch 的工作原理

1. 创建 Watch：客户端通过 gRPC 流式 RPC 向 etcd 发起 Watch 请求，指定要监听的键或前缀。
2. 事件缓冲：etcd 的 Watch 模块在内存中维护一个事件缓冲队列。当有数据变更（Put、Delete）时，事件被写入该队列。
3. 事件推送：Watch 模块通过 gRPC 流将事件实时推送给客户端。如果客户端消费速度慢于事件产生速度，事件会在缓冲队列中堆积。
4. 历史事件回放：如果 Watch 断开重连，客户端可以指定一个版本号（Revision），etcd 会从该版本开始回放历史事件。

2.4 Lease 机制：分布式租约与心跳

Lease（租约）是 etcd 实现分布式锁、服务健康检查和节点心跳的核心机制。一个 Lease 是一个带有 TTL（生存时间）的契约，etcd 保证在 TTL 过期后自动删除与该 Lease 关联的键值对。

2.4.1 Lease 的生命周期

2.4.2 Lease 与 etcd 性能

在 Kubernetes 中，每个 Node 的心跳本质上是一个 Lease 续约操作。当集群规模达到数千节点时，Lease 续约请求会成为 etcd 的主要写负载之一。优化 Lease 相关的参数（如 --experimental-peer-skip-client-san-verification 和调整心跳间隔）对大规模集群稳定性至关重要。

2.5 MVCC 多版本并发控制：无锁读与历史版本

etcd 通过 MVCC（Multi-Version Concurrency Control） 实现高效的并发读写，避免读写冲突。每个键的每次修改都会生成一个新版本，旧版本数据不会被立即删除，而是保留一段时间。

2.5.1 版本号与 Revision

etcd 使用一个全局单调递增的 Revision（版本号） 来标识每一次写操作。Revision 是一个 64 位整数，每次写操作（Put、Delete、Txn）都会递增。每个键值对都包含以下元数据：

• create_revision：该键被创建时的 Revision。
• mod_revision：该键最后一次被修改时的 Revision。
• version：该键被修改的次数（从 1 开始计数）。

2.5.2 MVCC 的工作流程

1. 写操作：当执行 put key value 时，etcd 生成一个新的 Revision，并将新数据写入 BoltDB。旧版本数据仍然保留在 BoltDB 中，但标记为“历史版本”。
2. 读操作：只读事务获取当前最新的 Revision 快照，读取该快照下的数据。读操作不需要加锁，不会阻塞写操作。
3. 历史版本查询：客户端可以通过指定 Revision 参数读取历史版本的数据，实现时间旅行查询。
4. 压缩（Compaction）：为了避免历史版本无限增长导致磁盘空间爆炸，etcd 会定期执行压缩操作，删除指定 Revision 之前的所有历史版本。

2.6 核心组件关联与性能影响

etcd 的这五大组件并非孤立运行，它们相互协作，共同决定了 etcd 的整体性能和稳定性。下表总结了它们之间的关联关系及对性能调优的影响：