Flink 容错机制

精确一次&有效一次：没有引擎保证精确一次只能说事件发生多次 我们只能反映一次给状态后端一次 有效一次有效一次实现策略：1-->At-least-once+去重：每个算子维护一个事务日志 跟踪已处理事件 重放失败事件 在进入下一个算子之前 删除重复事件故障不会随着拓扑大小而增加  需要大量的存储和基础设施来支持 每个算子的性能的开销2-->At-least-once+幂等：依赖sink端存储的去重性 和 数据特性  实现简单 开销较低  缺点依赖存储和数据特性太强3-->分布式快照：借助于Flink 本身自带的Checkpoint 较小的资源开销  缺点Barrier同步 故障时需要全局暂停和回滚 拓扑越大 性能潜在越大

故障时Flink需要重启 / 恢复故障的Task 以及受到影响的Task

两阶段提交(Two-phase Commit，简称2PC)：将两阶段提交协议中的公共逻辑进行提取和封装一目的：分布式系统架构下的所有节点在进行事务提交时要保持一致性（即要么全部成功，要么全部失败）两角色：协调者（Coordinator） 负责统筹并下达命令工作参与者（Participants） 负责认真干活并响应协调者的命令三条件：分布式系统中必须存在一个协调者和多个参与者 正常相互通信所有节点都采用预写日志方式，且日志可以可靠存储所有节点不会永久性损坏，允许可恢复性的短暂损坏

DAG：流或事件处理应用程序可以或多或少分布式下的有向无环图DAG：真实环境有多个source  多个Operator 多个sink组成每个节点并行度都有差异 都会出故障为了保证数据的容错和一致性

Barrier对齐等到上游所有的并行子分区barrier都到齐 才去保存当前任务的状态缺点：先到达的分区要做缓存等待，会造成数据堆积（背压）

Source

preCommit阶段消费数据时  协调者向所有参与者发起是否可以执行预提交操作，等待所有参与者的响应  然后所有参与者执行事务操作 存储checkPoint并持久化  如果参数者事务操作执行成功  对协调者返回同意 反之 返回终止

Flink 容错机制 / EOS

端到端的STS

Flink的容错机制任务失败重启 不丢失以前的信息数据源得支持重发机制

Chandy-Lamport  / 分布式快照特定时间点记录下来的分布式系统的全局状态包含所有进程的状态以及所有channel的状态

Chandy-Lamport算法思想

SavePoint

精确一次  exactly once每一条消息只被流处理系统处理一次每个算子的所有状态都会定期做 checkpoint发生故障 每个算子的所有状态都回滚到最新的全局一致checkpoint 点回滚期间 暂停所有处理 源也会重置最近的偏移量

转换

恢复策略通过 flink-conf.yaml 中的  jobmanager.execution.failover-strategy配置项进行配置1.全图重启Restart All Failover Strategy-->Task 发生故障时会重启作业中的所有 Task 进行故障恢复2.当前region  Restart Pipelined Region Failover Strategy：会将作业中的所有task划分为多个区域 当task故障时 会找到当前范围region进行重启如果有些数据损坏 丢失 需要重启产生数据的部分

Initiating a snapshot创建snapshot 可以由任意进程发起 发起时 记录自己进程状态 生成一个标识信息marker 发送给下游 继续接收上游的消息

Flink是带状态的处理系统 状态会不断更新如果集群突然崩溃 为了保证数据的容错性和一致性需要通过恢复状态 恢复到崩溃前才能继续处理

Check Point

注：Flink 由 JobManager 协调各个 TaskManager 进行 Checkpoint 存储， Checkpoint 保存在 StateBackend（状态后端） 中，默认 StateBackend 是内存级 的，也可以改为文件级的进行持久化保存Flink消费到Kafka数据之后，就会开启一个Kafka的事务，正常写入Kafka分区日志标记但未提交，也就是预提交（Per-commit）一旦所有的Operator完成各自的Per-commit，他们会发起一个commit操作如果有任意一个Per-commit失败，所有其他的Per-commit必须停止，并且Flink会回滚到最近成功完成的CheckPoint当所有的Operator完成任务时，Sink端就收到checkpoint barrier（检查点分界线），Sink保存当前状态，存入Checkpoint，通知JobManager，并提交外部事物，用于提交外部检查点的数据JobManager收到所有任务通知，发出确认信息，表示Checkpoint已经完成，Sink收到JobManager的确认信息，正式提交这段时间的数据外部系统（Kafka）关闭事务，提交的数据可以正常消费了

Barrier  span style=\

Flink Sink端到端的前提：数据不能重复1.文本型的存储 txt word2.数据库型的存储

commit阶段协调者获取到所有消息 都是同意才发出提交请求  参与者完成操作 释放事务期间占用的资源  向协调者发送事务完成消息   协调者反馈消息 完成事务如果一个失败或超时了发出回滚请求  参与者进行最近的checkPoint回滚 释放事务期间占用的资源  向协调者发送回滚完成消息 协调者反馈消息 取消事务

手动提交1.上面都是定时自动拍摄快照   Checkpoint 的生命周期由 Flink 管理2.有些时候我们可能会手动拍摄快照   由用户创建，拥有和删除3.应用场景：升级 Flink 版本，调整用户逻辑，改变并行度，以及进行红蓝部署等

重启策略：没有定义重启策略  默认集群的重启策略通过flink-conf.yaml 来设置默认的重启策略 配置参数 restart-strategy1.固定延迟重启策略-->给定的次数尝试重启 超过次数 重启失败  重启有间隔2.故障率重启策略-->故障发生之后重启 每个时间间隔重启的次数超过了指定的次数 重启失败3.不重启策略-->作业直接失败，不尝试重启4.备用重启策略-->使用群集定义的重启策略 没有定义其他重启策略，默认选择固定延时重启策略

容错策略

简化Chandy-Lamport算法思想 只存储状态将数据进行分割 拍快照的定期生成一个检查点（自增ID）跟随数据一起流动 广播给下游的所有算子 当算子收到barrier 说明上一批数据已经走完 开始拍摄快照 存储到HDFS持久化下一批数据继续传输 保证实时性

Flink Source端到端的前提：能够进行重复消费kafka Source：能够记录偏移量 能够重放数据  将偏移量记录在State中 与下游的算子一起 经过checkPoint机制 实现快照统一

Sink

注意点：1.SavePoint是全局状态 对于还在处理的很大状态的实时任务 会有影响不要太频繁2.Savepoint 进行恢复时，需要检查这次 Savepoint 目录文件是否可用可能会有保存到HDFS上失败 任务会启动不起来

事务写入：要么全部成功 要么全部失败 四大特性ACID结合 事务 和 checkPoint机制 保证只对外输出保证一次影响将待输出的数据保存下来 先不提交 等到checkPoint结束时 上下游算子数据都是一致的时候将之前的全部提交commit到外部系统瑕疵：checkPoint成功 事务失败                         事务成功 checkPoint后续操作失败能提供精确一次 但牺牲延迟 输出数据不在是实时写入 而是分批次提交

Propagating a snapshot:系统中其他进程开始逐个创建 snapshot 的过程

基于分布式快照算法:  Chandy-Lamportflink 实现了整个数据流中各算子的状态数据快照统一一次 checkpoint 后所持久化的各算子的状态数据，确保是经过了相同数据的影响数据在中间任何过程失败，则重启恢复后，所有算子的 state 数据都能回到这条数据从未处理过时的状态Flink 的快照可以到算子级别，并且对全局数据也可以做快照

采用幂等写入方式-->只支持KV结构  插入的值必须是可确定性计算的任意多次向一个系统写入相同数据，只对目标系统产生一次结果影响   对于幂等性写入 故障恢复的时候 会出现短暂的不一致保存点完成之后 发生故障之间的数据 其实已经写了一遍 回滚的时候不能消除他们外部应用现在读取的时候 会突然跳回之前的某个值 然后重播一段以前的数据但是当重播到故障点的时候 数据还是一致的

Terminating a snapshot: 算法结束条件所有的进程都收到 marker 信息并且记录下自己的状和 channel 的状态（包含的message）

最多一次  a most once有可能数据丢失从失败处的下个数据开始恢复程序 之前的失败数据处理就不管了

触发方式1.flink savepoint 命令触发 Savepoint2.使用 flink cancel -s 命令，取消作业时，并触发 Savepoint3.使用 Rest API 触发 Savepoint，格式为：*/jobs/:jobid /savepoints*

数据处理语义

预写日志-->不支持事务的存储系统 使用WAL 通用性强 不能百分百精确一次事务提交是需要外部存储系统支持事务的，否则没有办法真正实现写入的回撤1.将结果数据作为日志状态保存起来2.进行检查点保存的时候 将结果数据持久化3.收到检查点完成通知时 一并写入外部系统 注意点：采用批写入的方式 会写入失败  执行写入的时候 等待成功的返回确认消息成功写入数据后 会二次确认相应的检查点 这才真正的完成需要将确认消息也持久化 用于后面的故障恢复 有确认消息才能保证数据成功二次确认缺陷：检查点和写入都成功 确认消息失败 会导致重复写入WAL预习日志会先写内存，而内存是易失介质

End-to-End Exactly-Once端到端的精确一次注入系统 中间处理 到输出结果的整个流程中 每个环节都处理成功 失败回滚与exactly once区别：数据源和输出的程序都只保证一次

详细流程

流程详解

反压时候 barrier 无法随着数据往下游流动  造成反压的时候无法做出 Checkpoint恢复性能取决于 检查点的间隔  间隔越大 重放的数据就会越多Barrier对不齐-->又回到了最初的原点解决Barrier对齐 先到达的分区缓存 缓存压力太大 更容易让节点崩掉短暂停顿-->在整个过程中对所有 buffer 和 state 标注让先到达的分区的数据继续往下走 给这些数据做一些标记 不做缓存等待

最小一次  At least once数据可能重复应用程序完全处理之前丢失，则将从源头重放或重新传输事件