CodeWalk

Flink增量Checkpoint原理与配置

作者：专业代码师 · 2026-05-30 12:55

Flink的增量Checkpoint（Incremental Checkpoint）是如何工作的？请说明增量Checkpoint的数据结构、与全量Checkpoint的差异、以及RocksDB增量快照的实现细节。在生产环境中配置增量Checkpoint需要注意哪些问题？

回答

专业代码师

1. 工作原理

增量Checkpoint基于RocksDB内部快照机制，每次只上传自上次Checkpoint以来发生变化的SST文件：

第一次CK：完整快照（全量SST文件）
后续CK：仅上传新增/修改的SST文件
恢复时：base CK + 增量SST序列

2. 核心数据结构

  • Shared State Registry（共享状态注册表）：
    • 记录每个SST文件的引用计数
    • 文件未被任何Checkpoint引用时删除
  • BackendState：
    • RocksDB的备份快照指针
    • 文件句柄和元数据

3. 实现细节

// Flink内部实现
class RocksDBIncrementalSnapshot {
    // 1. 触发RocksDB内部快照
    RocksDB.checkpoint();  // RocksDB原生
    // 2. 遍历WAL和Memtable，刷写为SST
    // 3. 对比上次CK，提取变化SST文件列表
    // 4. 上传新SST文件到DFS
    // 5. 更新Shared State Registry
}

4. 与全量Checkpoint对比

维度全量Checkpoint增量Checkpoint
存储空间每次全量仅变化量
上传时间大（GB级）小（MB级）
恢复时间一次下载需合并连续CK
文件管理简单需GC清理孤儿文件

5. 配置注意事项

# 启用增量Checkpoint
state.backend.incremental: true

# 清理策略：建议默认
# Flink自动清理不再被引用的SST文件
# 保留Checkpoint数：至少保留2个增量Checkpoint用于恢复
state.checkpoints.num-retained: 5

# 最小文件大小（避免小文件过多）
state.backend.rocksdb.writebuffer.size: 64mb

关键痛点：

  • 长时间运行后SST文件数量膨胀
  • 恢复时需扫描多个CK链，可能变慢
  • 建议定期做全量Checkpoint（如每天一次）