3. 快照机制详解：快照触发条件、创建过程与磁盘I/O影响

etcd 的快照（Snapshot）是 Raft 日志压缩的核心手段。随着集群运行，Raft 日志会持续增长，若不加以控制，将导致日志回放过慢、磁盘空间耗尽、节点重启恢复时间过长。快照机制通过定期“截断”历史日志，将当前状态持久化为一个完整的状态文件，从而在保证数据完整性的同时实现日志瘦身。

3.1 快照触发条件：定时与日志数量双阈值

etcd 的快照触发并非单一条件，而是由 定时触发 和 日志数量触发 两个维度共同控制，任一条件满足即触发快照。这种双阈值设计兼顾了时间维度的可预测性与日志维度的空间控制。

此外，etcd 还支持 手动触发快照，通过 etcdctl snapshot save 命令或 API 调用，用于运维场景下的数据备份或节点迁移。

3.2 快照创建过程：从 Raft 日志到持久化文件

快照的创建是一个多阶段、原子化的过程，涉及 Raft 层、MVCC 层和文件系统层的协同。下图展示了快照创建的核心流程与数据流转。

3.3 快照对磁盘 I/O 的影响：写放大与延迟波动

快照创建过程对磁盘 I/O 的影响主要体现在以下三个方面：

1. 顺序写放大：快照文件需要将整个内存状态写入磁盘，文件大小通常为几百 MB 到数 GB。虽然写入模式是顺序的，但大量数据一次性写入会占用磁盘带宽，影响同时进行的业务读写。
2. fsync 同步开销：快照文件写入完成后，etcd 会执行 fsync 确保数据落盘。对于 HDD 磁盘，fsync 延迟可能达到几十毫秒；对于 SSD，通常为几毫秒，但仍会造成短暂的写入延迟抖动。
3. 与 WAL 写入的竞争：快照写入期间，WAL（Write-Ahead Log）仍在持续追加。两者共享磁盘 I/O 带宽，可能导致 WAL 写入延迟升高，进而影响 Raft 提交延迟。

3.4 快照文件的生命周期与清理策略

etcd 不会无限保留快照文件。每个节点默认保留 5 个 最新快照文件（可通过 --max-snapshots 配置）。当新快照生成后，最旧的快照文件会被自动删除。这一机制在保证有足够历史快照用于节点恢复的同时，避免了磁盘空间的无限占用。

快照文件存储在 etcd 数据目录下的 member/snap/ 子目录中，命名格式为 0000000000000001-0000000000000001.snap，其中第一个数字为快照对应的 Raft term，第二个数字为快照包含的最后一条日志的索引。

# 查看快照文件列表
ls -lh /var/lib/etcd/member/snap/

# 输出示例
-rw-r--r-- 1 etcd etcd 1.2G Jan 15 10:30 0000000000000005-0000000000a00001.snap
-rw-r--r-- 1 etcd etcd 1.1G Jan 15 11:00 0000000000000005-0000000000b00001.snap
-rw-r--r-- 1 etcd etcd 1.3G Jan 15 11:30 0000000000000005-0000000000c00001.snap
-rw-r--r-- 1 etcd etcd 1.2G Jan 15 12:00 0000000000000005-0000000000d00001.snap
-rw-r--r-- 1 etcd etcd 1.1G Jan 15 12:30 0000000000000005-0000000000e00001.snap