一、课程导论：什么是Checkpoint？为什么需要增量Checkpoint？

大家好，我是你们这门课的老朋友。在分布式系统和存储领域摸爬滚打了十几年，我踩过的坑，可能比你们写过的代码还多（笑）。今天咱们开篇，先聊聊一个最基础、但也最容易被忽视的概念——Checkpoint。

说白了，Checkpoint就是给系统拍一张“快照”。你想想看，一个分布式系统跑着跑着，突然断电了、进程挂了、网络抖动了，怎么办？如果没有Checkpoint，一切归零，从头再来。这在单机小应用上还能忍，但在生产环境里，那可是灾难级别的。

1.1 什么是Checkpoint？

Checkpoint，我习惯叫它“存档点”。它把系统在某个时刻的完整状态——包括内存里的数据、正在处理的任务、中间计算结果——全部持久化到可靠的存储上。这样一旦系统崩溃，我们就可以从最近的存档点恢复，而不是从头开始。

举个例子，你玩一个RPG游戏，打了三个小时的Boss，终于快通关了。这时候游戏崩溃了。如果你没有存档，那三个小时白费。但如果你每半小时存一次档，最多只损失半小时的进度。Checkpoint就是这个“存档”机制。

在分布式系统里，Checkpoint的应用场景太多了：

• 流计算引擎（如Flink、Spark Streaming）：记录每个算子的状态和偏移量
• 分布式数据库（如TiDB、CockroachDB）：记录事务日志和存储引擎的快照
• 消息队列（如Kafka、Pulsar）：记录消费进度和分区状态
• 机器学习训练：保存模型参数和优化器状态

我记得有一次，帮一家金融科技公司排查问题。他们的实时风控系统每五分钟做一次全量Checkpoint，每次要写几十GB的数据。结果呢？Checkpoint还没写完，下一轮又开始了，磁盘IO直接被打满，业务延迟飙升。这就是典型的“全量Checkpoint之痛”。

1.2 为什么需要增量Checkpoint？

全量Checkpoint的问题，说白了就是“太笨重”。每次都要把整个状态完整地写一遍，不管数据有没有变化。这在状态量小的时候还好，一旦状态量上了TB级别，全量Checkpoint就成了系统的瓶颈。

我给大家算一笔账：

对比维度	全量Checkpoint	增量Checkpoint
每次写入数据量	全部状态	仅变化部分
存储空间占用	高（每次都是完整副本）	低（只存差异）
写入耗时	长（与状态量成正比）	短（与变化量成正比）
恢复复杂度	低（一次读取即可）	高（需要合并多个增量）
适用场景	状态量小、变化频繁	状态量大、变化稀疏

看到没？全量Checkpoint的恢复虽然简单，但写入代价太高。而增量Checkpoint正好相反——写入快、省空间，但恢复时需要把多个增量片段拼起来。

我曾经在一个日志分析平台上遇到过这样的场景：系统每天处理几百亿条日志，状态量维持在几百GB。全量Checkpoint每次要写十几分钟，期间业务几乎不可用。后来我们改成了增量Checkpoint，每次只写最近几秒的变化，写入时间从十几分钟降到了几秒钟。嗯，效果立竿见影。

1.3 全量恢复与增量恢复的区别

恢复，是Checkpoint的最终目的。你存了那么多快照，不就是为了在出问题时能快速恢复吗？

全量恢复，就是直接从最近的一个全量Checkpoint中读取完整状态。简单粗暴，一步到位。但前提是——你得有最近的全量Checkpoint。如果全量Checkpoint的间隔很长，那恢复出来的状态可能已经“过时”了。

增量恢复，则需要先加载一个基础的全量Checkpoint，然后按时间顺序依次应用所有增量Checkpoint，直到恢复到目标时间点。这个过程有点像“搭积木”——先搭好底座，再一层层往上加。

我画了一张图，帮大家理解这两种恢复方式的流程差异：

从图上可以看得很清楚：全量恢复是“一步到位”，增量恢复是“层层叠加”。

1.4 本章小结

好了，咱们把这一章的核心点捋一捋：

• Checkpoint 就是系统的“存档点”，用于故障恢复
• 全量Checkpoint 写入慢、占空间，但恢复简单
• 增量Checkpoint 写入快、省空间，但恢复需要合并
• 实际工程中，我推荐“定期全量 + 频繁增量”的混合策略

这一章是基础，但也是整个课程的基石。后面的章节，我们会深入增量Checkpoint的实现细节、一致性保证、性能优化等话题。嗯，路还长，咱们一步步来。