Flink测试资源异常总结及checkpoint机制

异常 

The heartbeat of TaskManager with id *****  timed out.

原因：此错误是container心跳超时，出现此种错误一般有两种可能：

1、分布式物理机网络失联，这种原因一般情况下failover后作业能正常恢复，如果出现的不频繁可以不用关注；

2、failover的节点对应TM的内存设置太小，GC严重导致心跳超时，建议调大对应节点的内存值

解决方案：加大flink程序的运行内存;延长心跳超时时间

在我的flink工作中，我尝试将heartbeat.timeout从50秒增加到3分钟，不起作用，并且异常不断出现。在我的例子中，出现心跳超时异常的原因是，当堆内存耗尽时，任务管理器会崩溃。因此，我尝试将taskmanager.memory.managed.fraction从0.4改为0.05，这反过来增加了堆内存。现在，心跳失败的频率已经降低，管道也能够从失败中重新启动。

异常:

org.apache.flink.util.FlinkRuntimeException: Exceeded checkpoint tolerable failure threshold.

原因 CheckpointTimeout 设置的Checkpoin超时时间内未完成任务 导致的超时异常。

解决 1，增加超时时间 2，增加机器性能  3，减少数据处理量 ：source并行度 和窗口数据量减少，sink 并行度增加
 

在Checkpoint有较多超时情况时，基于目前的Checkpoint机制，主要有以下几种情况调整：

1. 降低Source的并发度、拉取频率、拉取量；
2. 提高checkpoint发送频率；
3. 提高同时能够进行的checkpoint数量；
4. 提高checkpoint超时时间；
5. 启用非对齐checkpoint：Job会变为有状态，使用无状态重启可能造成数据丢失；
6. 容忍Checkpoint失败：在checkpoint失败时不会重启Job

该方式只是允许checkpoint失败，在checkpoint失败时不会重启Job，遇到逻辑异常或未捕获异常时仍然会重启Job； 由于允许失败，所以在遇到未捕获异常时可能导致自动恢复的offset更旧，从而导致需要处理的数据更多。

以上的方式，主要方向是降低每个checkpoint需要处理的数据量，使得每一个checkpoint可控；

我们都知道checkpoint的重要性，整体过程如下：

JobManager 向 Source 算子发送 Barrier ，初始化
Checkpoint，即JM向Source发起Trigger操作；
各个Source 算子一旦收到 Barrier 之后，开始Init自身的State，并同时向下游发送 Barrier；
下游算子收到 Barrier 后，进行 Barrier Alignment
处理，且若有多个input时并且收到所有的input的Barrier才会开始做Init
State，同时继续往下游发送Bassier，直到sink算子
(1.10之前需要Barrier对齐，1.11以后可以选择UnAlignment)；
算子做自身的CP时，分为同步和异步，
同步阶段的 Snapshot操作：
a.对state做深拷贝。
b.将写操作封装在异步的FutureTask中；
异步阶段的 Snapshot：
a.执行同步阶段创建的FutureTask
b.向Checkpoint Coordinator发送ACK响应；
各个算子(或者说Task) 做完 Checkpoint 之后，再上报 JobManager，JM收到所有算子的ACK，则认为这次CP
完成了。
下面分别介绍几种遇到的CP超时问题。
1、计算量大，CPU密集，导致TaskManager内线程一直在processElement而没有时间做CP；（逻辑处理的算子根本无法将接收到的数据在合适的时间内计算完毕）

2、数据倾斜。解决办法：重新设置并行度；两阶段聚合

Flink中State管理与恢复之CheckPoint原理及三种checkpoint使用方式对比 - 古堡里一片荒芜 - 博客园 (cnblogs.com)