2. Checkpoint 配置调优：间隔、超时、并发数、Pause 之间的配置策略
说实话，我见过太多团队把 Checkpoint 配置当成填空题来做了。随便填个间隔 60 秒，超时 10 分钟，然后上线跑。结果呢？要么频繁失败，要么反压飙升，要么作业重启到怀疑人生。
Checkpoint 的四个核心参数——间隔（interval）、超时（timeout）、并发数（max-concurrent）、Pause（min-pause）——它们不是孤立的。它们是一个联动系统。调一个，另外三个就得跟着动。
这一章，我把这几个参数的调优逻辑拆开讲。每个参数我都会给出一套我自己的经验值，以及我在生产环境里踩过的坑。
2.1 间隔（interval）：别让 Checkpoint 变成负担
间隔，就是两次 Checkpoint 之间的时间差。默认是 30 秒。但说实话，这个值在大多数生产场景下都太短了。
为什么？你想想看，如果一次 Checkpoint 要处理 10 秒，间隔 30 秒，那每 30 秒就有 10 秒在干 Checkpoint 的活。CPU 和网络带宽都被占着，业务数据处理的吞吐量自然就下来了。
我个人习惯的配置策略是这样的：
| 场景 | 推荐间隔 | 说明 |
|---|---|---|
| 实时风控 / 交易对账 | 10 ~ 30 秒 | 对延迟敏感，需要快速恢复 |
| 实时数仓 ETL | 60 ~ 180 秒 | 吞吐优先，允许分钟级恢复 |
| 批流一体 / 大状态作业 | 180 ~ 600 秒 | 状态大，频繁做 Checkpoint 成本太高 |
2.2 超时（timeout）：给 Checkpoint 一个死线
超时，就是一次 Checkpoint 最多能跑多久。超时了，这次 Checkpoint 就被判定为失败。
默认值是 10 分钟。嗯，这个值其实挺危险的。为什么？因为如果一次 Checkpoint 卡住了，比如某个算子反压严重，或者后端存储挂了，它会一直卡着直到超时。这期间，如果并发数配置不当，后续的 Checkpoint 也会被阻塞。
我曾经遇到过一个案例：某个作业的 Checkpoint 超时设了 30 分钟，结果一次 Checkpoint 卡了 25 分钟才失败。这 25 分钟里，整个作业的 Checkpoint 机制完全瘫痪。恢复的时候，要回退 25 分钟的数据，业务方直接炸了。
所以我的建议是：
- 超时时间 = 间隔 × 2。比如间隔 60 秒，超时设 120 秒。这样即使一次失败，也不会拖太久。
- 不要超过 5 分钟。除非你的状态真的特别大，否则超时超过 5 分钟，说明你的 Checkpoint 链路本身就有问题。
- 结合后端存储的响应时间。如果后端是 HDFS，注意 NameNode 的 RPC 超时；如果是 S3，注意请求限流。这些都会影响 Checkpoint 的实际耗时。
2.3 并发数（max-concurrent）：别让 Checkpoint 打架
并发数，就是同时允许多少个 Checkpoint 在跑。默认是 1。也就是说，一次只能做一个 Checkpoint，做完一个再做下一个。
这个参数，说白了就是控制 Checkpoint 的“车道数”。车道多了，能同时跑多个 Checkpoint，但也会抢占资源。车道少了，容易堵车。
我个人建议：
- 大多数场景保持默认值 1。因为 Checkpoint 之间是有依赖关系的。如果同时跑两个，后一个 Checkpoint 可能基于前一个还没完成的状态，导致数据不一致。
- 只有在间隔很短（比如 10 秒以内）且状态很小的时候，才考虑设成 2。比如实时风控场景，状态只有几 MB，一次 Checkpoint 几百毫秒就搞定了。这时候并发 2 可以提升容错响应速度。
- 不要超过 3。并发数超过 3，资源竞争会非常严重。我见过有人设成 5，结果 Checkpoint 失败率飙升到 40%。
2.4 Pause（min-pause）：给 Checkpoint 一个喘息的机会
Pause，全称是 minPauseBetweenCheckpoints。它定义了一次 Checkpoint 完成后，到下一次 Checkpoint 开始之间，至少要间隔多久。
这个参数很多人会忽略。但我觉得它才是四个参数里最容易被误解的。
举个例子：你设了间隔 60 秒，Pause 30 秒。如果一次 Checkpoint 跑了 40 秒，那它完成后，要等 30 秒才能开始下一次。也就是说，实际间隔变成了 70 秒。
为什么要设 Pause？因为 Checkpoint 会占用资源。如果一次 Checkpoint 刚做完，马上又开始下一次，那业务处理的时间窗口就被压缩了。Pause 就是强制给业务处理留出时间。
我的配置策略：
- Pause 至少是间隔的 50%。比如间隔 60 秒，Pause 至少 30 秒。
- 如果作业对延迟敏感，Pause 可以设小一点，比如间隔的 20%。但要注意监控 Checkpoint 的完成时间，别让它们挤在一起。
- 如果 Checkpoint 经常超时，可以适当增大 Pause。给业务处理留出更多时间，降低反压风险。
2.5 四个参数的联动策略
好了，四个参数都讲完了。但真正重要的是它们怎么配合。我画了一张图，把它们的联动关系展示出来：
从图上你能看到，间隔是核心。它决定了超时的上限，也影响了并发和 Pause 的配置范围。我个人的调优顺序是：
- 先定间隔。根据业务对延迟的要求，选一个合适的间隔。
- 再配超时。超时 = 间隔 × 2，不超过 5 分钟。
- 然后设 Pause。Pause = 间隔 × 50%，作为初始值。
- 最后微调并发。如果间隔很短（≤30 秒）且状态小，并发可以设 2。否则保持 1。
2.6 配置示例
最后，给出一份我常用的配置模板。你可以根据自己的场景微调：
// 实时风控场景：低延迟，小状态
CheckpointConfig config = env.getCheckpointConfig();
config.setCheckpointInterval(10_000); // 10 秒
config.setCheckpointTimeout(30_000); // 30 秒
config.setMaxConcurrentCheckpoints(2); // 并发 2
config.setMinPauseBetweenCheckpoints(5_000); // 5 秒
// 实时数仓 ETL 场景：中等延迟，中等状态
CheckpointConfig config = env.getCheckpointConfig();
config.setCheckpointInterval(120_000); // 2 分钟
config.setCheckpointTimeout(240_000); // 4 分钟
config.setMaxConcurrentCheckpoints(1); // 并发 1
config.setMinPauseBetweenCheckpoints(60_000); // 1 分钟
// 大状态批流一体场景：高吞吐，大状态
CheckpointConfig config = env.getCheckpointConfig();
config.setCheckpointInterval(300_000); // 5 分钟
config.setCheckpointTimeout(600_000); // 10 分钟
config.setMaxConcurrentCheckpoints(1); // 并发 1
config.setMinPauseBetweenCheckpoints(150_000); // 2.5 分钟