在面试时被问到这个问题，当时有点蒙圈没答好，现在记录下来好以后复习：
在 Flink 里，如果 checkpoint 时间间隔（interval）设置得太小，会带来一系列性能和稳定性方面的影响，主要包括：
1. 计算资源被 Checkpoint 占用过多
-
原理：每次 checkpoint 都会触发状态快照（state snapshot）写入持久化存储（如 HDFS、S3、RocksDB 本地+远程），这是一个 IO 密集操作，还会涉及数据序列化、网络传输。
-
影响：
-
CPU 用于业务逻辑计算的时间减少
-
IO 带宽被 checkpoint 数据占用
-
延迟增加，因为算子线程要等待 barrier 对齐（barrier alignment）
2. Barrier 对齐等待时间增加
-
如果上游多个分区流速不同，Flink 在做 checkpoint 时需要等待所有输入流的 barrier 对齐。
-
频繁 checkpoint 会导致算子更频繁进入 barrier 对齐状态，导致吞吐下降。
3. 状态后端压力过大
-
以 RocksDB StateBackend 为例：
-
每次 checkpoint 都会触发 RocksDB 的 SST 文件刷写（flush）和元数据更新
-
频繁刷写会增加磁盘 IO 竞争和后台 compaction 压力
-
如果状态数据较大，频繁 checkpoint 会让 RocksDB compaction 线程长期占用 CPU/IO
4. 反而可能导致 checkpoint 堆积 / 失败
-
原因：
-
Checkpoint 需要在指定超时时间内完成，如果间隔太小，上一个 checkpoint 还没完成，下一个就开始了，可能导致多个 checkpoint 并发执行（如果
maxConcurrentCheckpoints > 1），进而造成存储、网络压力飙升。
-
在极端情况下，会触发 checkpoint 超时、失败，甚至导致作业频繁重启。
5. 延迟敏感任务反而变慢
-
在低延迟实时任务中，业务逻辑和 checkpoint 操作会竞争资源，如果 checkpoint 太频繁，反而可能 吞吐下降、延迟上升。
6. 容错收益递减
-
理论上，checkpoint 间隔越短，失败恢复时丢失的数据就越少。
-
但在实际生产中，checkpoint 间隔小于 5 秒往往收益很低，而性能损耗却非常明显（尤其是状态数据大的任务）。
-
如果作业不是超高可用的金融级场景，过于频繁 checkpoint 意义不大。