既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
+ [六、检查点的配置](#_92)
一、一致性检查点(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的消息,通过这种方式来启动检查点
- 数据源将它们的状态写入检查点,并发出一个检查点barrier
- 状态后端在状态存入检查点之后,会返回通知给source任务,source任务就会向JobManager确认检查点完成
- 分界线对齐:barrier向下游传递,sum任务会等待所有输入分区的barrier到达
- 对于barrier已经到达的分区,继续到达的数据会被缓存
- 而barrier尚未到达的分区,数据会被正常处理
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新**