大数据开发：Flink容错机制Task Failover策略

在Flink的容错机制当中，作业执行层面的容错，有一个非常重要的策略，就是Task Failover策略，这是针对于计算层面的最小执行层面，在大数据流计算场景下，Task错误非常常见。那么Flink是怎么处理的呢，今天的大数据开发分享，我们就来讲讲这个Task Failover策略。

Task Failover策略

作为计算的最小执行单位，Task错误是十分常见的，比如机器故障、用户代码抛出错误或者网络故障等等都可能造成Task错误。对于分布式系统来说，通常单个Task错误的处理方式是将这个Task重新调度至新的worker上，不影响其他Task和整体Job的运行，然而这个方式对于流处理的Flink来说并不可用。

Flink的容错机制主要分为从checkpoint恢复状态和重流数据两步，这也是为什么Flink通常要求数据源的数据是可以重复读取的。对于重启后的新Task来说，它可以通过读取checkpoint很容易地恢复状态信息，但是却不能独立地重流数据，因为checkpoint是不包含数据的，要重流数据只可以要求依赖到的全部上游Task重新计算，通常来说会一直追溯到数据源Task。

要做到细粒度的错误恢复机制，减小单个Task错误对于整体作业的影响，Flink需要实现一套更加复杂的算法，也就是FLIP-1[2]引入的Task Failover策略。Task Failover策略目前有三个，分别是：

RestartAll、RestartIndividualStrategy和RestartPipelinedRegionStrategy。

RestartAll：重启全部Task，是恢复作业一致性的最安全策略，会在其他Failover策略失败时作为保底策略使用。目前是默认的Task Failover策略。

RestartPipelinedRegionStrategy：重启错误Task所在Region的全部Task。Task Region是由Task的数据传输决定的，有数据传输的Task会被放在同一个Region，而不同Region之间没有数据交换。

RestartIndividualStrategy：恢复单个Task。因为如果该Task没有包含数据源，这会导致它不能重流数据而导致一部分数据丢失。考虑到至少提供准确一次的投递语义，这个策略的使用范围比较有限，只应用于Task间没有数据传输的作业。不过也有部分业务场景可能需要这种at-most-once的投递语义，比如对延迟敏感而对数据一致性要求相对低的推荐系统。

总体来说，RestartAll较为保守会造成资源浪费，而RestartIndividualStrategy则太过激进不能保证数据一致性，而RestartPipelinedRegionStrategy重启的是所有Task里最小必要子集，其实是最好的Failover策略。

而实际上Apache社区也正准备在1.9版本将其设为默认的Failover策略[3]。不过值得注意的是，在1.9版本以前RestartPipelinedRegionStrategy有个严重的问题是在重启Task时并不会恢复其状态，所以请在1.9版本以后才使用它，除非你在跑一个无状态的作业。

关于大数据开发，Flink容错机制Task Failover策略，以上就为大家做了简单的介绍了。Flink的容错机制，在Task层面来说，基本上就执行这个策略，了解清楚之后对于后续的学习也有好处。