标签：状态 barrier Flink 容错 source 任务 检查点
一、一致性检查点（Checkpoints）
Flink故障恢复机制的核心，就是应用状态的一致性检查点
有状态流应用的一致性检查点，其实就是所有任务的状态，在某个时间点的一份拷贝（一份快照）；这个时间点，应该是所有任务都恰好处理完一个相同的输入数据的时候
二、从检查点恢复状态
在执行流应用程序期间，Flink会定期保存状态的一致检查点
如果发生故障，Flink将会使用最近的检查点来一致恢复应用的状态，并重新启动处理流程
上图示例：6已处理完，正要处理7，发现任务挂了
第一步：就是重启应用
第二步：是从checkpoint中读取状态，将状态重置
从检查点重新启动应用程序后，其内部状态与检查点完成时的状态完全相同
从5之后的offset处开始消费读取
第三步：开始消费并处理检查点到发生故障之间的所有数据
这种检查点的保存和恢复机制可以为应用程序状态提供”精确一次“（Exactly-once）的一致性，因为所有算子都会保存检查点并恢复其所有状态，这样一来所有的输入流都会被重置到检查点完成时的位置
三、检查点的实现算法
Flink基于Chandy-Lamport算法的分布式快照（在某个数据后插入一个标记位，执行到此的时候做一次checkpoint） 将检查点的保存和数据处理分离开，不暂停整个应用 检查点分界线（Checkpoint Barrier） Flink的检查点算法用到了一种称为分界线（barrier）的特殊数据形式，用来把一条流上数据按照不同的检查点分开 分界线之前到来的数据导致的状态更改，都会被包含在当前分界线所属的检查点中；而基于分界线之后的数据导致的所有更改，就会被包含在之后的检查点中 JobManager控制分界线，插入分界线命令只发给source
现在是一个有两个输入流的应用程序，用并行的两个source任务来读取
JobManager会向每个source任务发送一条带有新检查点ID的消息，通过这种方式来启动检查点
source任务在当前数据处理完成之后，就会在这条数据之后插入一个barrier
数据源将它们的状态写入检查点，并发出一个检查点barrier
状态后端在状态存入检查点之后，会返回通知给source任务，source任务就会向JobManager确认检查点完成
并发source任务将各自目前已处理完的数据进行保存，并告知JobManager检查点已存储完成，barrier并向下游广播出去，后续任务还在执行
分界线对齐：barrier向下游传递，sum任务会等待所有输入分区的barrier到达
对于barrier已经到达的分区，继续到达的数据会被缓存；而barrier尚未到达的分区，数据会被正常处理
当收到所有输入分区的barrier时，任务就将其状态保存到状态后端的检查点中，然后将barrier继续向下游转发
向下游转发检查点barrier后，任务继续正常的数据处理
标签：状态,barrier,Flink,容错,source,任务,检查点 来源： https://www.cnblogs.com/EnzoDin/p/16671149.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。