增量快照核心机制：变更块追踪、元数据管理、快照链与依赖关系

增量快照听起来很玄乎，说白了就是「只记变化，不抄全本」。我刚开始接触分布式存储时，总觉得全量快照最省事——咔一下全盘复制，多简单。直到有一次线上环境数据量到了几十TB，全量快照跑了整整6个小时，业务方差点没把我电话打爆。嗯，从那以后，增量快照就成了我的必修课。

这一章，我们就把增量快照的三个核心机制拆开揉碎：变更块追踪怎么知道哪些数据变了？元数据管理怎么记录这些变化？快照链与依赖关系又如何保证数据一致性？

1. 变更块追踪：谁动了我的数据？

增量快照的第一步，就是搞清楚「从上一次快照到现在，哪些数据块被修改了」。我个人习惯把这个问题分成两个层面：追踪粒度和追踪时机。

1.1 追踪粒度：块大小怎么选？

你想想看，如果粒度太细（比如4KB），追踪精度高，但元数据量会爆炸。如果粒度太粗（比如1MB），元数据少了，但每次增量传输的数据量又太大。我在项目中遇到过最典型的场景：一个日志型应用，每次只写几个小文件，但文件系统块大小是1MB，结果每次增量快照都要传1MB的整块，实际变化只有几十KB。

这里我给出一个经验参考：

1.2 追踪时机：实时还是定期？

变更块追踪有两种主流实现方式：

• 实时追踪（Change Journal / 变更日志）：每次写入操作都记录到日志中。优点是零延迟，缺点是日志会持续增长，需要定期截断。
• 定期扫描（Dirty Block Bitmap / 脏块位图）：在快照触发时，扫描文件系统或存储层的修改标记。优点是实现简单，缺点是扫描本身有开销。

我个人更倾向于混合策略：平时用变更日志做实时记录，快照触发时用脏块位图做二次确认。这样既能保证实时性，又能避免日志丢失导致的数据遗漏。

2. 元数据管理：快照的「户口本」

变更块追踪只是第一步，追踪到的信息得有个地方存。这就是元数据管理的活儿。元数据说白了就是快照的「户口本」——记录着每个快照包含哪些数据块、这些数据块在什么位置、以及快照之间的依赖关系。

2.1 元数据应该存什么？

我习惯把元数据分成三类：

1. 快照元数据：快照ID、创建时间、快照类型（全量/增量）、状态（进行中/完成/失败）。
2. 块映射元数据：每个数据块的逻辑偏移、物理位置、校验和、引用计数。
3. 依赖元数据：当前快照依赖哪个父快照、父快照的哪些块被复用。

这里有一个关键点：引用计数。增量快照中，很多数据块是多个快照共享的。只有引用计数归零时，才能安全回收。我见过不少新手直接删快照，结果把还在被其他快照引用的数据块也删了，导致数据损坏。

2.2 元数据存储选型

元数据存储的选择直接影响快照性能。我整理了一个对比表：

我个人在大多数项目中会选择RocksDB + 本地缓存的组合。RocksDB的LSM-Tree结构对写操作非常友好，配合LRU缓存，读性能也能接受。如果元数据需要跨节点共享，再考虑上层的分布式协调层。

3. 快照链与依赖关系：增量快照的「家谱」

增量快照不是孤立的，它们之间有一条清晰的依赖链。这条链决定了你能恢复到哪个时间点，以及恢复时需要读取哪些数据块。

3.1 链式结构 vs 树状结构

最简单的快照链是线性链：全量快照 → 增量1 → 增量2 → 增量3。每个增量只依赖前一个快照。优点是实现简单，缺点是链越长，恢复性能越差——你得从全量开始，逐个应用增量。

更高级的是树状结构：允许从同一个全量快照出发，创建多个分支增量。这在测试环境或并行开发中非常有用。但代价是依赖关系更复杂，回收策略也更难设计。

3.2 依赖关系与数据一致性

快照链的核心约束是：子快照不能比父快照先删除。这听起来简单，但在分布式环境下，节点故障、网络分区都可能破坏这个约束。

我常用的做法是引入依赖图，用有向无环图（DAG）来管理快照之间的依赖。每个快照在创建时，都会记录它的父快照ID。删除时，先检查是否有子快照引用，如果有，要么拒绝删除，要么做「合并」操作——把子快照依赖的数据块合并到父快照中。

这里有一个我踩过的坑：

4. 核心逻辑总览

说了这么多，我们用一张图来总结增量快照的核心逻辑：

这张图把整个流程串起来了。从数据写入开始，经过变更追踪、元数据记录、快照链构建，最终完成增量快照。每一步都有对应的技术选型和避坑要点，我们在后续章节中会逐一深入。

5. 小结

增量快照的核心机制，说白了就是三件事：知道谁变了（变更块追踪）、记下怎么变的（元数据管理）、理清变的前后关系（快照链与依赖）。这三者缺一不可，任何一个环节出问题，都会导致数据恢复失败。

我个人觉得，增量快照最难的不是技术实现，而是对异常情况的处理。日志写满了怎么办？元数据损坏了怎么办？快照链断了怎么办？这些问题，我们在后面的性能调优实战中会一一拆解。