etcd 架构基础：Raft 共识算法、存储引擎与 WAL/快照机制

理解 etcd 的底层架构是进行容量规划与 I/O 瓶颈诊断的前提。etcd 本质上是一个分布式、强一致性的键值存储系统，其核心由三个关键组件构成：Raft 共识算法（保证数据一致性）、存储引擎（BoltDB/backend）（负责本地持久化）以及 WAL 与快照机制（保障数据安全与恢复效率）。

2.1 Raft 共识算法简介

Raft 是一种用于管理复制日志的共识算法，它将分布式一致性问题分解为三个相对独立的子问题：领导者选举（Leader Election）、日志复制（Log Replication） 和 安全性（Safety）。etcd 使用 Raft 来确保集群中所有节点上的数据状态保持一致。

Raft 的工作流程可以概括为：Leader 接收客户端写入请求，将操作封装为日志条目，通过 AppendEntries RPC 并行复制到所有 Follower。当日志条目被多数节点（Quorum）持久化后，Leader 将其应用到状态机（即 BoltDB），并返回客户端成功。

2.2 etcd 存储引擎：BoltDB / Backend

etcd 的本地持久化存储引擎基于 BoltDB（一个嵌入式、事务性的键值数据库）。在 etcd 的架构中，Backend 是对 BoltDB 的一层封装，负责管理事务、预写日志（WAL）与快照的交互。

BoltDB 的核心特性包括：

• B+ 树索引： 数据以 B+ 树结构组织，支持高效的顺序和随机读写。
• ACID 事务： 提供原子性、一致性、隔离性和持久性保证。
• 单文件存储： 所有数据存储在一个 .db 文件中，简化了管理。
• 无 WAL 日志（自身）： BoltDB 本身不维护 WAL，etcd 通过上层的 WAL 机制来保证数据持久性。

etcd 存储引擎关键概念对比

概念	说明	与 I/O 瓶颈的关系
BoltDB 文件	存储最终状态机数据（KV 数据、元数据）	频繁的写事务会导致 BoltDB 文件产生大量随机 I/O 和页面分裂
Backend	封装 BoltDB，提供事务接口，管理 WAL 与快照	Backend 的批量提交策略直接影响磁盘写入频率
事务（Tx）	读写事务，读事务使用 MVCC 避免锁竞争	长时间运行的读事务会阻塞 BoltDB 的页面重用，导致空间膨胀
Bucket	BoltDB 中的命名空间，类似表	etcd 使用多个 Bucket（如 key、history、meta）管理数据

2.3 WAL 与快照机制

WAL（Write-Ahead Log，预写日志）和快照是 etcd 数据持久化和恢复的两大支柱。

2.3.1 WAL（预写日志）

WAL 记录了所有对 etcd 状态的修改操作。在数据被写入 BoltDB 之前，必须先追加到 WAL 文件。这种机制确保了即使在写入过程中发生崩溃，etcd 也能通过重放 WAL 恢复到一致状态。

• 顺序写入： WAL 是顺序追加写入的，这是 etcd 最主要的写入 I/O 来源。
• 文件轮换： 当 WAL 文件大小达到阈值（默认 64MB）时，会创建新的 WAL 文件。
• 数据完整性： 每条 WAL 记录都包含 CRC 校验，用于检测数据损坏。

2.3.2 快照（Snapshot）

随着 WAL 文件的不断增长，重放所有 WAL 来恢复状态会变得非常缓慢。快照机制通过定期保存当前状态机的完整状态（即 BoltDB 文件的一个压缩版本）来解决这个问题。

• 触发条件： 当 WAL 文件数量或总大小超过阈值（如 10000 条日志条目）时触发。
• 快照文件： 生成一个 .snap 文件，包含 BoltDB 的压缩副本和元数据。
• WAL 裁剪： 快照生成后，之前的 WAL 文件可以被安全删除，从而释放磁盘空间。