Flink 之容错机制浅析

一、一致性检查点（Checkpoints）

1、从检查点恢复状态

1）Flink故障恢复机制的核心，就是应用状态的一致性检查点

2）有状态流应用的一致性检查点，其实就是所有任务的状态在某个时间点的一份拷贝（快照）注：这个时间点应该是所有任务都恰好处理完一个相同的输入的数据的时候。

3）在执行流应用程序的期间，Flink会定期保存状态的一致性检查点。

4）如果发生故障，Flin将会使用最近的检查点来一致恢复应用程序的状态，并从恢复点重新启动处理流程：

5）恢复流程

（1）传统做法

1. 遇到故障之后，第一步就是重启应用
2. 第二步是从 checkpoint 中读取状态，将状态重置；从检查点重新启动应用程序后，其内部状态与检查点完成时的状态完全相同
3. 第三步：开始消费并处理检查点到发生故障之间的所有数据。这种检查点的保存和恢复机制可以为应用程序状态提供“精确一次”（exactly-once）的一致性，因为所有算子都会保存检查点并恢复其所有状态，这样一来所有的输入流就都会被重置到检查点完成时的位置

（2）改进做法：检查点算法

2、Flink检查点算法

基于 Chandy-Lamport 算法的分布式快照；将检查点的保存和数据处理分离开，不暂停整个应用 *

检查点分界线（Checkpoint Barrier）
Flink 的检查点算法用到了一种称为分界线（barrier）的特殊数据形式，用来把一条流上数据按照不同的检查点分开。
分界线之前到来的数据导致的状态更改，都会被包含在当前分界线所属的检查点中；而基于分界线之后的数据导致的所有更改，就会被包含在之后的检查点中

1. 现在是一个有两个输入流的应用程序，用并行的两个 Source 任务来读取，source1和source2的偏移量分别为3和4。Sum even已经计算了 蓝1和黄1的和并向Sink 1发送计算结果；Sum odd已经按顺序计算了黄1、蓝1、黄3的和，并向Sink 2发送计算结果。

2. JobManager 会向每个 source 任务发送一条带有新检查点 ID 的消息，通过这种方式来启动检查点，此处检查点ID为2，说明之前已经存在检查点ID为1的检查点。在JobManager发起检查点的同时，sum到sink的流上的值会继续传递
   

3. 数据源接收到检查点ID后，会暂停向下游发出新的数据，而是先在状态后端触发本地状态的检查点保存，将它们的状态写入检查点，并向所有传出的下游流分区广播发出一个带有检查点ID的 barrier 。状态后端在将状态存入检查点之后，会返回通知给 source 任务，source 任务就会向 JobManager 确认检查点启动完成。source做完这些操作后会继续处理数据的常规操作。在此过程中，下游的数据继续进行计算、传递、保存。
   

4. 分界线对齐：barrier 向下游传递，sum 任务会等待所有输入分区的 同一ID的barrier 到达。对于barrier已经到达的分区，继续到达的数据会被暂时缓存；而barrier尚未到达的分区，数据会被正常处理。
   如图所示，蓝barrier2先到达，说明蓝色barrier2之前的数据都已经计算完成，但是由于黄barrier2尚未到达，所以需要等待，即使蓝4先到达，也不计算，只是先将蓝4缓存起来。在等待黄barri2的期间，如果有黄色数据到来，则正常处理，计算完毕将计算结果向下游传递。然后继续等待barrier2的到来。
   在此期间source端会继续处理数据。
   

5. 当sum任务收到所有输入分区的携带同一检查点ID的 barrier 时，sum任务就将先其状态保存到状态后端的检查点中，并继续向所有下游连接的任务广播检查点分界线barrier。
   

6. sum任务向下游转发检查点 barrier 后，任务开始处理之前缓冲的数据，在处理并发出所有的缓冲数据之后，任务就可以继续正常处理输入流了。
   

7. 检查点分界线会到达输出（sink）任务。当sink任务接收到barrier时，它也会先执行“分界线对齐”，然后将自己的状态保存到检查点，并向作业管理器确认已接收到barrier。当所有任务都确认已成功将状态保存到检查点时，本次检查点就真正完成了。这样，当发生故障时，我们就可以用已完成的检查点恢复应用程序了。
   

二、保存点（SavePoints）

1. 自定义的镜像保存功能
2. 创建保存点的算法和创建检查点的算法完全相同
3. 保存点会存储一些元数据
4. 保存点需要”手动“创建，即需要触发创建操作
5. Flink也不会自动清理保存点
6. 可以应用于：有计划的手动备份、更新应用程序、版本迁移、暂停和重启应用等
7. 其他特点：
   a) 便于升级应用服务版本: Savepoint 常在应用版本升级时使用，当前应用的新版本更新升级时，可以根据上一个版本程序记录的 Savepoint 内的服务状态信息来重启服务。它也可能会使用更早的 Savepoint 还原点来重启服务，以便于修复由于有缺陷的程序版本导致的不正确的程序运行结果。
   b) 方便集群服务移植: 通过使用 Savepoint，流服务应用可以自由的在不同集群中迁移部署。
   c) 方便Flink版本升级: 通过使用 Savepoint，可以使应用服务在升级Flink时，更加安全便捷。
   d) 增加应用并行服务的扩展性: Savepoint 也常在增加或减少应用服务集群的并行度时使用。
   e) 便于A/B测试及假设分析场景对比结果: 通过把同一应用在使用不同版本的应用程序，基于同一个 Savepoint 还原点启动服务时，可以测试对比2个或多个版本程序的性能及服务质量。
   f) 暂停和恢复服务: 一个应用服务可以在新建一个 Savepoint 后再停止服务，以便于后面任何时间点再根据这个实时刷新的 Savepoint 还原点进行恢复服务。
   g) 归档服务: Savepoint 还提供还原点的归档服务，以便于用户能够指定时间点的 Savepoint 的服务数据进行重置应用服务的状态，进行恢复服务。

三、检查点和保存点的区别与联系

1、都应用于故障恢复

2、检查点会自动创建；保存点需要用户或外部调度程序明确的触发才会创建。

3、保存点会比检查点多存储一些元数据信息。

4、使用保存点时需注意：状态的类型和名称中途不能改变；任务的拓扑结构中途不能改变（使用的算子不能变），可以通过添加uid的方式标识算子。

直达：Flink 之容错机制相关配置