Flink-跟着问题读源码：CheckPoint超时问题总结_triggering checkpoint 耗时太长

最近一段时间处理业务数据量的增长和处理流程的复杂性，导致flink实时作业不仅仅局限于结果正确，更多的精力放在了性能优化上，接下来对近期CheckPoint时长优化进行总结。
我们都知道checkpoint的重要性，整体过程如下：

1. JobManager 向 Source 算子发送 Barrier ，初始化
   Checkpoint，即JM向Source发起Trigger操作；
2. 各个Source 算子一旦收到 Barrier 之后，开始Init自身的State，并同时向下游发送 Barrier；
3. 下游算子收到 Barrier 后，进行 Barrier Alignment
   处理，且若有多个input时并且收到所有的input的Barrier才会开始做Init
   State，同时继续往下游发送Bassier，直到sink算子
   (1.10之前需要Barrier对齐，1.11以后可以选择UnAlignment)；
4. 算子做自身的CP时，分为同步和异步，
   同步阶段的 Snapshot操作：
   a.对state做深拷贝。
   b.将写操作封装在异步的FutureTask中；
   异步阶段的 Snapshot：
   a.执行同步阶段创建的FutureTask
   b.向Checkpoint Coordinator发送ACK响应；
5. 各个算子(或者说Task) 做完 Checkpoint 之后，再上报 JobManager，JM收到所有算子的ACK，则认为这次CP
   完成了。

下面分别介绍几种遇到的CP超时问题。