Flink：实时数据处理（8.容错机制）

1.⼀致性检查点（checkpoint）

• Flink 故障恢复机制的核⼼，就是应⽤状态的⼀致性检查点
• 有状态流应⽤的⼀致性检查点，其实就是所有任务的状态，在某个时间点的⼀份
  拷⻉（⼀份快照）；这个时间点，应该是所有任务都恰好处理完⼀个相同的输
  ⼊数据（其实就是检查点屏障）的时候

2.从检查点恢复状态

• 在执⾏流应⽤程序期间，Flink 会定期保存状态的⼀致检查点
• 如果发⽣故障， Flink 将会使⽤最近的检查点来⼀致恢复应⽤程序的状态，并
  重新启动处理流程

遇到故障之后，第⼀步就是重启应⽤

第⼆步是从 checkpoint 中读取状态，将状态重置
从检查点重新启动应⽤程序后，其内部状态与检查点完成时的状态完全相同

第三步：开始消费并处理检查点到发⽣故障之间的所有数据
• 这种检查点的保存和恢复机制可以为应⽤程序状态提供“精确⼀次”（exactly-once）的⼀致性，因为所有算⼦都会保存检查点并恢复其所有状态，这样⼀来所有的输⼊流就都会被重置到检查点完成时的位置

3.Flink 检查点算法（Chandy-Lamport算法）

3.1 ⼀种简单的想法（同步的思想）

• 暂停应⽤，保存状态到检查点，再重新恢复应⽤（Spark Streaming）

3.2 Flink 的改进实现（异步的思想）

• 基于 Chandy-Lamport（微软⾸席科学家）算法的分布式快照算法
• 将检查点的保存和数据处理分离开，不暂停整个应⽤

3.3 检查点分界线（Checkpoint Barrier，检查点屏障）

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

3.4 图示详解

检查点操作是⾃动执⾏的，并且检查点⽂件不覆盖

现在是⼀个有两个输⼊流的应⽤程序，⽤并⾏的两个 Source 任务来读取

JobManager 会向每个 source 任务发送⼀条带有新检查点 ID 的消息，通过这种
⽅式来启动检查点

数据源将它们的状态写⼊检查点，并发出⼀个检查点 barrier
• 状态后端在状态存⼊检查点之后，会返回通知给 source 任务，source 任务就会
向 JobManager 确认检查点完成

分界线对⻬：barrier 向下游传递，sum 任务会等待所有输⼊分区的 barrier 到达
• 对于barrier已经到达的分区，继续到达的数据会被缓存
• ⽽barrier尚未到达的分区，数据会被正常处理

当收到所有输⼊分区的 barrier 时，任务就将其状态保存到状态后端的检查点
中，然后将 barrier 继续向下游转发

向下游转发检查点 barrier 后，任务继续正常的数据处理

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

4.保存点（save points）

• Flink 还提供了可以⾃定义的镜像保存功能，就是保存点（savepoints）
• 原则上，创建保存点使⽤的算法与检查点完全相同，因此保存点可以认为就是具
  有⼀些额外元数据的检查点
• Flink不会⾃动创建保存点，因此⽤户（或者外部调度程序）必须明确地触发创建
  操作，savepoint是⼿动执⾏的
• 保存点是⼀个强⼤的功能。除了故障恢复外，保存点可以⽤于：有计划的⼿动备
  份，更新应⽤程序，版本迁移，暂停和重启应⽤，等等
• $ flink savepoint jobId