3. etcd 存储机制：底层存储引擎 boltdb、MVCC 多版本并发控制、数据文件结构

etcd 作为云原生日志平台的核心元数据存储组件，其存储机制直接决定了集群的稳定性与性能上限。本章深入剖析 etcd 的底层存储引擎 boltdb、MVCC 多版本并发控制 以及 数据文件结构，帮助 SRE 工程师理解磁盘空间膨胀与轮转策略的根源。

3.1 底层存储引擎：boltdb

etcd v3 使用 boltdb 作为其持久化存储引擎。boltdb 是一个纯 Go 语言实现的嵌入式键值数据库，设计目标为高可靠性与简单性，而非高并发吞吐。

核心特性

• 单文件存储：所有数据存储在一个 .db 文件中，默认路径为 /var/lib/etcd/member/snap/db。
• B+树索引：使用 B+树组织数据，支持高效的键范围扫描与顺序访问。
• 事务支持：提供 ACID 事务，etcd 的每次读写操作都封装为 boltdb 事务。
• 无 WAL 分离：boltdb 自身不维护预写日志（WAL），etcd 通过 Raft 日志实现崩溃恢复。

3.2 MVCC 多版本并发控制

etcd 在 boltdb 之上实现了 MVCC（Multi-Version Concurrency Control），以支持无锁读和高并发访问。每次写入操作不会原地覆盖旧值，而是生成一个新版本。

版本管理机制

MVCC 带来的磁盘问题

• 版本堆积：频繁写入导致历史版本数量激增，boltdb 文件膨胀。
• 碎片化：boltdb 的 B+树在删除旧版本时会产生内部碎片，无法立即回收空间。
• 压缩依赖：etcd 的 --auto-compaction-retention 参数控制历史版本保留时长，若设置不当，磁盘空间会持续增长。

3.3 数据文件结构

etcd 的数据文件结构分为 内存层 与 磁盘层。理解这两层结构有助于定位磁盘空间瓶颈。

3.3.1 内存层：treeIndex

etcd 在内存中维护一个 treeIndex（基于 B-tree），用于快速查找 key 对应的最新版本号。treeIndex 不存储实际值，仅存储 key 到 revision 的映射。

3.3.2 磁盘层：boltdb 文件

boltdb 文件内部包含多个 bucket，每个 bucket 是一个独立的 B+树。etcd 使用以下核心 bucket：

3.3.3 数据写入与读取流程

1. 写入：客户端发起 put 请求 → etcd 分配新 revision → 写入 boltdb key bucket（保留旧版本）→ 更新 treeIndex。
2. 读取：客户端发起 get 请求 → 查询 treeIndex 获取最新 revision → 从 boltdb 读取对应版本数据。
3. 压缩：后台压缩协程扫描历史版本 → 删除 key bucket 中过期的版本 → 触发 boltdb 内部页合并。

3.4 核心存储架构图

下图展示了 etcd 存储引擎的整体架构，包括内存 treeIndex、boltdb 文件以及 MVCC 版本链的关系。

3.5 数据文件生命周期与压缩流程

下图展示了 etcd 数据文件从写入到压缩的完整生命周期，帮助理解磁盘空间回收的延迟机制。

3.6 关键参数与运维建议