开启掘金成长之旅！这是我参加「掘金日新计划 12 月更文挑战」的第31天，点击查看活动详情

Flink中Checkpoint容错机制1

三、Flink Checkpoint 容错机制原理概述

Flink 供给了 Exactly once 特性，是依赖于带有 barrier 的分布式快照 + 可部分重发的数据源功用实现的。而分布式快照中，就保存了 operator 的状况信息。

Flink 的失利康复依赖于 检查点机制 + 可部分重发的数据源。

  • 一、检查点机制：Checkpoint 定时触发，产生快照，快照中记载了：
  1. 当时检查点开端时数据源（例如 Kafka）中音讯的 offset。
  2. 记载了一切有状况的 Operator 当时的状况信息（例如 sum 中的数值）。（Application/Job Operator / / Task）
  3. 浅显的解说：每隔一段时间，就给这个 job 中的一切 Task 的state 做一次耐久化，所以一切 Task State 的耐久化成功了，则意味着这个 job 在这个时间的 checkpoint 就成功了， 也就意味着给这个 job 在当时时间做了一次 checkpoint
  • 二、可部分重发的数据源：Flink 选择最近成功完成的检查点，然后体系重放整个分布式的数据流，然后给予每个 Operator 他们在该检查点快照中的状况。数据源被设置为从适宜方位开端从头读取流。例如在 Apache Kafka 中，那意味着告知顾客从偏移量 offset 开端从头消费。
  1. 浅显的解说：我从你哪儿拉取一部分数据履行消费，数据拉取成功了，可是消费失利。 我要重来一次。那到底从那个地方持续呢？

（1）假如数据源具有数据重放功用：那么没有消费处理成功的数据，就再拉取处理一次

（2）假如数据源不具有数据重放功用： 失利之后就再也拿不到之前拉取的数据了。数据丢掉了

分布式音讯体系：kafak rocketmq 都是具有数据重放才能的组件。

探讨一个问题：现在让你实现 Flink 的检查点机制的 功用，该怎么做？

图零 全体的：CheckPoint简单设计

Flink系列之Flink中Checkpoint容错机制
图一：当使命失利的时分

当使命运转失利的时分：

Flink系列之Flink中Checkpoint容错机制
拍照快照的时分，有两种结果是能够接受的：

假如符号放在 7 的后边： offset =7, sum_odd = 16, sum_even = 12  
假如符号放在 6 的后边： offset =6, sum_odd = 9, sum_even = 12
假如符号放在 5 的后边： offset =5, sum_odd = 9, sum_even = 6

假如直接把上图中的每个 Task 的状况直接保存，那么便是不合理的（有些数据，上游已经处理了，可是下流没有被处理）：

offset =7, sum_odd = 9, sum_even = 12 XXXXXXXXXXXX, 假如 job 从这个状况中履行康复，则 offset = 7 的这条数据就丢掉了，没有参加计算

就一个需求：需求确保每一条数据，都完好的通过了这条处理链路（Source —> Transform —-> Sink）

然后咱们重启使用，对应的状况数据已经丢掉了。

图二：重启使用

Flink系列之Flink中Checkpoint容错机制
图三：CheckPoint康复数据

Flink使用程序从checkpoint康复数据：

Flink系列之Flink中Checkpoint容错机制
图四：Flink使用程序持续运转

Flink使用程序持续运转：

Flink系列之Flink中Checkpoint容错机制

四、Flink CheckPoint 算法原理深入剖析

State 是办理一个 Task 的状况，那么一个 Flink Job 在运转过程中，是由许多的 Task 分布式并行运转组成的。保管和办理一个 Task 的状况，对于一个 Task 的容错来说，非常重要，同样，保存和办理这个 Job 的一切 Task 的状况，并保持一致，也同样非常重要。这是 Flink 的 Job 容错的最终解决方案。

Flink 容错机制的中心是对数据流做连续的分布式快照(snapshots)，咱们把每一次 take snapshot 动作称之为 Checkpoint。Checkpoint 是 Flink 实现容错机制最中心的功用，它能够根据装备周期性地根据 Stream 中各个 Operator/Task 的状况来生成快照，然后将这些状况数据定时耐久化存储下来，当 Flink 程序一旦意外崩溃时，从头运转程序时能够有选择地从这些快照进行康复，然后修正因为毛病带来的程序数据异常。

详细的概念（重要的总结）：Flink 的 Checkpoint 机制根据 chandy-lamport 算法，在某一个时间，对一个 Flink Job 的一切 Task 做一个快照拍照（逻辑上解说），而且将快照保存在 内存/磁盘 中永久保存，这姿态，假如 Flink Job 重启康复，就能够从毛病前最近一次的成功快照中进行状况康复，然后实现确保 Flink 数据流式数据的一致性。当然，为了配合 Flink 能实现状况快照，而且 job 状况康复，有必要数据源具有数据回放功用。

简单地说，Checkpoint 是一种分布式快照：在某一时间，对某个 Flink 作业一切的 Task 做一个快照（snapshot），而且将快照保存在 memory / filesystem 等存储体系中。这样，在使命进行毛病康复的时分，就能够还原到使命毛病前最近一次检查点的状况，然后确保数据的一致性。当然，为了确保 exactly-once / at-leastonce 的特性，还需求数据源支持数据回放。

实现 Checkpoint 的中心是：Stream Barrier，它和普通音讯无异，Stream barrier 作为一种符号信息刺进到数据流和正常数据一同活动。barriers 永久不会超过记载，数据流严厉有序，barrier 将数据流中的记载隔离成一系列的记载调集，并将一些调集中的数据加入到当时的快照中，而另一些数据加入到下一个快照中。每个 barrier 都带有快照的 ID，而且 barrier 之前的记载都进入了该快照。 barriers 不会中断流处理，非常轻量级。 来自不同快照的多个 barrier 能够同时在流中呈现，这意味着多个快照可能并发地发生。

Flink 使用程序中的音讯笼统其实是：BufferOrEvent（DataStream 数据流中的每条 记载 的数据笼统目标），它包括两个方面的信息：

01、Buffer：正常的待处理的数据
02、Event：嵌入到数据流中增强引擎流处理才能的特别音讯，包括 CheckpointBarrier 和 WaterMark
03、一个 DataStream 数据流中的数据其实有多种类型： data，checkpointbarrier，watermark

Flink 的 Checkpoint Coordinator 在需求触发检查点的时分要求数据源向数据流中注入 Stream Barrier（详细实现： CheckpointBarrier（checkpointID,timestamp）），当履行 Task 的 Operator 从他一切的 InputChannel 中都收到了 Stream Barrier 则会触发当时的 Operator 的快照拍照，并向其下流 Operator发送 Stream Barrier。当一切的 SinkOperator 都反馈完成了快照之后， Flink Checkpoint Coordinator 认为 Checkpoint 创立成功。

为了方便我们清楚了解 Checkpoint 的工作机制，在此供给了三张图：

图一：

Flink系列之Flink中Checkpoint容错机制

图二：

Flink系列之Flink中Checkpoint容错机制
图三：

Flink系列之Flink中Checkpoint容错机制

为什么要做对齐？

意图是为了 确保 一条数据假如被一个 Operator/Task 消费，那么就必定要被一切 Operator/Task 消费。不然假如一条数据 被 上游Operator/Task 消费了，可是没有被下流 Operator/Task 消费，那么就会呈现数据重复消费或许漏消费！



声明：
文章中代码及相关句子为自己根据相应了解编写，文章中呈现的相关图片为自己实践中的截图和相关技术对应的图片，若有相关异议，请联系删除。感谢。转载请注明出处，感谢。

落叶飘雪