2024年最新【Flink】（八）容错机制_6，HR的话扎心了

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

文章目录

• • 一、一致性检查点（Checkpoints）
    • 二、从检查点恢复状态
    • 三、检查点的实现算法
    • 四、Flink 检查点算法
    • • 4.1 检查点分界线（Checkpoint Barrier）
    • 五、保存点（Savepoints）
    • 六、检查点的配置

一、一致性检查点（Checkpoints）

Flink 具体如何保证 exactly-once 呢? 它使用一种被称为"检查点"（checkpoint）的特性，在出现故障时将系统重置回正确状态。

假设你和两位朋友正在数项链上有多少颗珠子。你捏住珠子，边数边拨，每拨过一颗珠子就给总数加一。你的朋友也这样数他们手中的珠子。当你分神忘记数到哪里时，怎么办呢? 如果项链上有很多珠子，你显然不想从头再数一遍，尤其是当三人的速度不一样却又试图合作的时候，更是如此(比如想记录前一分钟三人一共数了多少颗珠子，回想一下一分钟滚动窗口)。

于是，你想了一个更好的办法: 在项链上每隔一段就松松地系上一根有色皮筋，将珠子分隔开; 当珠子被拨动的时候，皮筋也可以被拨动; 然后，你安排一个助手，让他在你和朋友拨到皮筋时记录总数。用这种方法，当有人数错时，就不必从头开始数。相反，你向其他人发出错误警示，然后你们都从上一根皮筋处开始重数，助手则会告诉每个人重数时的起始数值，例如在粉色皮筋处的数值是多少。

Flink 检查点的作用就类似于皮筋标记。数珠子这个类比的关键点是: 对于指定的皮筋而言，珠子的相对位置是确定的; 这让皮筋成为重新计数的参考点。总状态(珠子的总数)在每颗珠子被拨动之后更新一次，助手则会保存与每根皮筋对应的检查点状态，如当遇到粉色皮筋时一共数了多少珠子，当遇到橙色皮筋时又是多少。当问题出现时，这种方法使得重新计数变得简单。

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

二、从检查点恢复状态

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

• 遇到故障后，第一步就是重新启动

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

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

三、检查点的实现算法

• 一种简单的想法

  • 暂停应用，保存状态到检查点，再重新恢复应用

• Flink 的改进实现

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

四、Flink 检查点算法

4.1 检查点分界线（Checkpoint Barrier）

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

• 现在是一个有两个输入流的应用程序，用并行的两个Source任务来读取

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

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

需要这份系统化资料的朋友，可以戳这里获取