【Flink】容错机制和状态一致性

容错机制

一致性检查点(Checkpoints)

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

• 在Flink中不能把当前所有分区的数据直接存下来，因为是有状态的流式计算所以除了当前处理的数据之外还应该有当前的状态。因为在状态编程中，我们可能会自定义状态，所以直接保存当前的数据和他的状态是不行的，还要知道在具体的操作流程里面到底执行到哪了，这样的话太复杂了，做不到。其实核心的一点就是要知道当前数据到底处理完没有。Flink提出的是不要保存当前所有的数据了，不管当前处理的数据是什么（如果要考虑就要考虑对应的每一个状态到底改变过没有），就考虑同一个数据，所有任务都处理完之后把那个状态取出来。

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

• 假设数据是由自然数构成的数据，source读取，按照奇偶数来进行分区求和。此时source的状态就是5（或者是偏移量），sum求和完成。那么就可以把这个三个保存为一个快照。source的快照就是当前的自然数，两个sum就是之前的累加求和。至于为什么不保存数据，而是保存数据的状态，是因为保存数据的话，那么恢复时就需要从头开始计算

跳转顶部

---

检查点状态的恢复

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

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

---

• 遇到故障之后，第一步就是重启应用，此时所有的状态都是空的

---

• 第二步是从 checkpoint 中读取状态，将状态重置

• 从检查点重新启动应用程序后，其内部状态与检查点完成时的状态完全相同

---

• 第三步：开始消费并处理检查点到发生故障之间的所有数据

• 这种检查点的保存和恢复机制可以为应用程序状态提供“精确一次”（exactly-once）的一致性，因为所有算子都会保存检查点并恢复其所有状态，这样一来所有的输入流就都会被重置到检查点完成时的位置

跳转顶部

---

检查点的算法

• 检查点分界线（Checkpoint Barrier）

  1️⃣：Flink 的检查点算法用到了一种称为分界线（barrier）的特殊数据形式，用来把一条流上数据按照不同的检查点分开

  2️⃣：分界线之前到来的数据导致的状态更改，都会被包含在当前分界线所属的检查点中；而基于分界线之后的数据导致的所有更改，就会被包含在之后的检查点中

• 现在是一个有两个输入流的应用程序，用并行的两个 Source 任务来读取
  
• JobManager 会向每个 source 任务发送一条带有新检查点 ID 的消息，通过这种方式来启动检查点

• 数据源将它们的状态写入检查点，并发出一个检查点 barrier

• 状态后端在状态存入检查点之后，会返回通知给 source 任务，source 任务就会向 JobManager 确认检查点完成

• 分界线对齐：barrier 向下游传递，sum 任务会等待所有输入分区的 barrier 到达

• 对于barrier已经到达的分区，继续到达的数据会被缓存

• 而barrier尚未到达的分区，数据会被正常处理

• 当收到所有输入分区的 barrier 时，任务就将其状态保存到状态后端的检查点中，然后将 barrier 继续向下游转发
  
• 向下游转发检查点 barrier 后，任务继续正常的数据处理

• Sink 任务向 JobManager 确认状态保存到 checkpoint 完毕

• 当所有任务都确认已成功将状态保存到检查点时，检查点就真正完成了

---

总结来说：就是是由barrier把一条流上的的数据按照不同的检查点来分割开来。分界线之前的数据的状态更改包含在当前分界线所属的检查点，barrier之后的数据状态的更改属于之后的检查点，每个任务遇到barrier就保存自己的状态，如果有多个分区，那么就有多个barrier，在保存数据状态时要保证所有的Barrie都到齐

• 检查点算法的流程

  1️⃣：JobManager触发Checkpoint，发出一个标记，这个标记会带着一个数，他发送给所有的source任务，source接收到消息之后就会在当前的数据流里面插入Barrier。

  2️⃣：source任务见到了barrier就把当前刚处理完的状态（偏移量）保存了，然后把barrier广播往下游发送，同时向JobManager确认检查点已经保存好了

  3️⃣：如果上游其中一个分区的barrier到了，接下来要做的是Barrier的对齐，没到齐之前，已经来了barrier的流新的数据又来了不能直接做计算，而是先缓存起来，而barrier还没有到达的上游分区来的数据会被正常处理

  4️⃣：上游所有输入分区的barrier都到齐时，任务就将其状态保存到状态后端的检查点中，将barrier继续向下游转发

  5️⃣：直到Sink 任务向 JobManager 确认状态保存到 checkpoint 完毕。当所有任务都确认已成功将状态保存到检查点时，检查点就真正完成了

跳转顶部

---

保存点

• Flink 还提供了可以自定义的镜像保存功能，就是保存点（savepoints）

• 原则上，创建保存点使用的算法与检查点完全相同，因此保存点可以认为就是具有一些额外元数据的检查点

• Flink不会自动创建保存点，因此用户（或者外部调度程序）必须明确地触发创建操作

• 保存点是一个强大的功能。除了故障恢复外，保存点可以用于：有计划的手动备份，更新应用程序，版本迁移，暂停和重启应用，等等

• 检查点的创建

  手动创建保存点:
  bin/flink savepoint :jobId [:targetDirectory]
  
  创建yarn上的保存点
  bin/flink savepoint :jobId [:targetDirectory] -yid :yarnAppId
  
  取消保存点
  bin/flink cancel -s [:targetDirectory] :jobId
  
  保存点恢复，和检查点恢复方法一样的
  bin/flink run -s :savepointPath [:runArgs]
  

• 检查点(checkpoint)的目录是依赖JobID的，每次运行任务都是一个唯一的JobID，所以要找到上一次任务的JobID才能找到检查点。保存点(savepoint)需要手动触发，并且在指定目录下还生成一个唯一的子目录。根据JobID可以在任务失败后，简单的重新执行任务即可恢复到失败前的检查点。

跳转顶部

---

状态一致性

状态一致性简介

• 有状态的流处理，内部每个算子任务都可以有自己的状态

• 对于流处理器内部来说，所谓的状态一致性，其实就是我们所说的计算结果要保证准确。

• 一条数据不应该丢失，也不应该重复计算

• 在遇到故障时可以恢复状态，恢复以后的重新计算，结果应该也是完全正确的。

跳转顶部

---

一致性的分类

• AT-MOST-ONCE（最多一次）：当任务故障时，最简单的做法是什么都不干，既不恢复丢失的状态，也不重播丢失的数据。At-most-once 语义的含义是最多处理一次事件。

• AT-LEAST-ONCE（至少一次）：在大多数的真实应用场景，我们希望不丢失事件。这种类型的保障称为 atleast-once，意思是所有的事件都得到了处理，而一些事件还可能被处理多次。

• EXACTLY-ONCE（精确一次）：恰好处理一次是最严格的保证，也是最难实现的。恰好处理一次语义不仅仅
  意味着没有事件丢失，还意味着针对每一个数据，内部状态仅仅更新一次。

跳转顶部

---

一致性检查点（checkpoint）

• Flink 使用了一种轻量级快照机制 —— 检查点（checkpoint）来保证 exactly-once 语义

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

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

跳转顶部

---

端到端（end-to-end）状态一致性

跳转顶部

---

端到端的精确一次（exactly-once）保证

• 目前我们看到的一致性保证都是由流处理器实现的，也就是说都是在Flink 流处理器内部保证的；而在真实应用中，流处理应用除了流处理器以外还包含了数据源（例如 Kafka）和输出到持久化系统

• 端到端的一致性保证，意味着结果的正确性贯穿了整个流处理应用的始终；每一个组件都保证了它自己的一致性

• 整个端到端的一致性级别取决于所有组件中一致性最弱的组件

---

• 内部保证 —— checkpoint

• source 端 —— 可重设数据的读取位置

• sink 端 —— 从故障恢复时，数据不会重复写入外部系统

  1️⃣：幂等写入

  2️⃣：事务写入

---

• 所谓幂等操作，是说一个操作，可以重复执行很多次，但只导致一次结果更改，也就是说，后面再重复执行就不起作用了
  

---

• 事务（Transaction）
  1️⃣：应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消

  2️⃣：具有原子性：一个事务中的一系列的操作要么全部成功，要么一个都不做

• 实现思想：构建的事务对应着 checkpoint，等到 checkpoint 真正完成的时候，才把所有对应的结果写入 sink 系统中

• 实现方式

  1️⃣：预写日志

  2️⃣：两阶段提交

---

• 预写日志（Write-Ahead-Log，WAL）

  1️⃣：把结果数据先当成状态保存，然后在收到 checkpoint 完成的通知时，一次性写入 sink 系统

  2️⃣：简单易于实现，由于数据提前在状态后端中做了缓存，所以无论什么sink 系统，都能用这种方式一批搞定

  3️⃣：DataStream API 提供了一个模板类：GenericWriteAheadSink，来实现这种事务性 sink

---

• 两阶段提交（Two-Phase-Commit，2PC）

  1️⃣：对于每个 checkpoint，sink 任务会启动一个事务，并将接下来所有接收的数据添加到事务里

  2️⃣：然后将这些数据写入外部 sink 系统，但不提交它们 —— 这时只是“预提交”

  3️⃣：当它收到 checkpoint 完成的通知时，它才正式提交事务，实现结果的真正写入

跳转顶部

---