4. 压缩机制详解：v3 API 压缩原理、历史版本回收与存储空间释放
etcd 的 MVCC 架构在写入新 key-value 时不会原地覆盖旧值，而是追加写入一个新版本。如果不加干预，历史版本会无限堆积，导致存储空间膨胀、查询性能劣化。v3 API 的压缩（Compaction）机制正是解决这一问题的核心手段——它负责回收已废弃的历史版本，释放底层存储空间。
4.1 压缩的本质：版本号裁剪
etcd v3 使用全局单调递增的 revision（修订版本号） 来标识每一次写入。每个 key 的每次修改都会产生一个新 revision，旧 revision 的数据仍然保留在 BoltDB 中，直到被压缩回收。
核心概念：压缩操作指定一个目标 revision
N，etcd 会删除所有 小于等于 N 的历史版本，仅保留大于 N 的版本以及当前最新版本。
压缩操作本身不会立即释放磁盘空间，它只是标记 BoltDB 中的旧数据为“可回收”。真正的空间释放发生在后续的 碎片整理（defragmentation） 阶段。
4.2 压缩的触发方式
etcd 提供三种压缩触发模式，适用于不同运维场景：
| 触发方式 | 命令 / 配置 | 适用场景 |
|---|---|---|
| 手动压缩 | etcdctl compaction <revision> |
运维排障、临时回收 |
| 自动定期压缩 | --auto-compaction-retention=1h |
按时间窗口保留历史 |
| 自动按版本压缩 | --auto-compaction-retention=1000 |
按版本数量保留历史 |
最佳实践：生产环境推荐使用 自动定期压缩，设置
--auto-compaction-retention=1h 或根据业务查询窗口调整。按版本压缩容易在写入突发时产生不可控的压缩频率。
4.3 压缩的内部执行流程
当 etcd 执行一次压缩操作时，内部经历以下关键步骤：
- 锁定压缩状态：etcd 在内存中记录当前正在压缩的目标 revision，防止重复压缩。
- 遍历 BoltDB Bucket：扫描
key和history两个 bucket，标记所有 revision ≤ N 的 key-value 记录。 - 删除历史版本：从 BoltDB 中删除被标记的记录，但 BoltDB 的 B+ 树节点不会立即收缩。
- 更新压缩状态：将压缩后的最新 revision 写入
metabucket，供后续 watch 和事务使用。 - 触发后端空闲页回收：BoltDB 内部将删除产生的空闲页加入空闲列表，等待后续写入复用。
4.4 压缩与碎片整理的关系
压缩和碎片整理是两个独立但互补的操作，运维人员常混淆二者。下表清晰区分：
| 维度 | 压缩（Compaction） | 碎片整理（Defragmentation） |
|---|---|---|
| 目标 | 删除历史版本，回收逻辑空间 | 整理 BoltDB 空闲页，回收物理磁盘空间 |
| 是否影响数据 | 是，删除不可恢复的历史版本 | 否，仅重组存储布局 |
| 执行频率 | 高频（分钟~小时级） | 低频（天~周级） |
| 对性能影响 | 中等，遍历 bucket 消耗 CPU 和 IO | 高，需要全量复制数据，建议低峰期执行 |
| 是否自动执行 | 支持自动（--auto-compaction-retention） | 需手动触发（etcdctl defrag） |
常见误区：只执行压缩而不做碎片整理，磁盘空间不会下降。压缩后必须执行
etcdctl defrag 才能真正释放空间。但碎片整理期间 etcd 会短暂不可用（单节点模式），生产环境建议逐个节点滚动执行。
4.5 压缩对性能的影响
压缩操作虽然必要，但不当的压缩策略会引发性能问题。以下是关键影响维度：
- CPU 开销：压缩需要遍历 BoltDB 的 B+ 树，大量历史版本时 CPU 占用飙升。
- IO 压力：删除操作产生大量 BoltDB 空闲页，后续写入需要遍历空闲列表，增加 IO 延迟。
- Watch 延迟：压缩期间 watch 事件流可能短暂阻塞，因为压缩需要获取内部锁。
- 内存占用：压缩过程中 etcd 会缓存部分 BoltDB 页，内存使用量短暂上升。
4.6 压缩策略配置参数
etcd 提供以下关键参数控制压缩行为，运维人员应根据业务负载精细调优：
| 参数 | 默认值 | 说明 |
|---|---|---|
--auto-compaction-retention |
0（关闭） | 自动压缩保留时长（如 1h）或版本数（如 1000） |
--auto-compaction-mode |
periodic | 压缩模式：periodic（按时间）或 revision（按版本） |
--experimental-compaction-batch-limit |
1000 | 单次压缩批量删除的最大版本数 |
--experimental-compaction-sleep-interval |
10ms | 压缩批次之间的休眠间隔，降低 IO 冲击 |
调优建议：对于高写入负载集群，建议设置
--experimental-compaction-batch-limit=500 和 --experimental-compaction-sleep-interval=50ms，以平滑压缩对 IO 的冲击。同时将 --auto-compaction-retention 设置为业务查询窗口的 2~3 倍，避免频繁压缩。
4.7 压缩状态监控
运维人员可以通过以下指标监控压缩的健康状况：
- etcd_server_compactions_total：累计压缩次数，用于观察压缩频率。
- etcd_server_compaction_revision：当前已压缩到的 revision，应随时间单调递增。
- etcd_server_compaction_pending_duration_seconds：压缩操作耗时，异常升高可能表示存储层存在瓶颈。
- etcd_mvcc_db_total_size_in_bytes：BoltDB 文件大小，压缩后若未碎片整理，该值不会下降。
监控告警建议：当
etcd_server_compaction_pending_duration_seconds 超过 5 秒时，说明压缩压力过大，应考虑调整压缩批次参数或增加碎片整理频率。