一文读懂Flink容错数据流

Flink容错数据流概念

有状态的函数和操作需要存储计算相关的数据，这使得状态成为复杂计算的关键。在 Flink 中的每一种函数和操作都可以成为有状态的。为了达到很好的容错，Flink 的容错机制持续的记录分布式的数据流的快照。这些快照是非常轻量化的，因此高频的记录快照并不会影响性能。当进程由于机器，网络甚至是软件异常而失败的时候，Flink 会停止数据流。系统重启操作同时将他们恢复到最近的快照点。输入流也会被设置到记录快照点那个时间点，通俗点说就是一条记录不会存在于快照中同时还在数据流中等待被处理。

问题1:哪些函数是有状态的？问题2:为什快照是非常轻量化的？问题3:快照如何设置异步的？问题4:如何在配置中设置多个快照问题5:快照支持哪几种方式，如何配置问题6:Checkpoint和Snapshots如何使用

Checkpointing

Flink 容错机制的核心就是，记录分布式的数据流和状态的一致性快照。通过这些快照，系统可以从失败中恢复回来

屏障Barriers

Flink分布式快照的一个核心元素是流屏障。这些屏障被注入到数据流中，并将记录作为数据流的一部分。障碍永远不会超过记录，它们严格按照顺序流动。一个屏障将数据流中的记录分隔为进入当前快照的记录集和进入下一个快照的记录集。每个屏障都携带快照的ID，快照将快照的记录推到它前面。屏障不会中断流，因此非常轻。来自不同快照的多个屏障可以同时出现在流中，这意味着各种快照可能同时发生。

流屏障被注入流源上的并行数据流。快照n的屏障被注入的位置(我们称之为Sn)是源流中快照覆盖数据的位置。例如，在Apache Kafka中，这个位置将是分区中最后一条记录的偏移量。这个位置Sn报告给检查点协调器(Flink的作业管理器)。

这些屏障随后流向下游。当中间操作符从其所有输入流接收到快照n的屏障时，它将快照n的屏障发送到其所有输出流。一旦接收操作符(流DAG的末尾)从其所有输入流接收到barrier n，它就向检查点协调器确认快照n。在所有接收都确认快照之后，就认为快照已经完成。

当一个操作对象接收多个流的情况下，需要按照以下逻辑，对输入流做对齐操作。

1.只有操作对象接收到屏障n便不在继续处理此输入流的数据，一直等到其它的输入流也收到屏障n。避免不同批次快照数据会混合起来2.属于快照n的数据流会被放入临时的buffer中3.一旦最后一个流接收到屏障n，操作对象开始发送全部缓存的数据，包括屏障n自身4.最后，恢复接收并处理全部的输入的数据。5.处理buffer的数据优先于处理流中数据。

State

当操作对象包含状态的时候，这些状态必须连同快照一并被记录下来。操作对象接收到全部输入流的同一屏障后，会将自身状态记录下来。在这一点上，任何来自记录数据的更新都会生效，并且不在依赖这些记录数据。状态被记录后，操作对象确认记录的快照，然后会将快照屏障发送到输出流。

1.每一个输入流在记录快照时候的偏移量或者准确位置2.一个操作对象的自身状态

第一步：start checkpoint message，获取当前checkpoint位置：6791，同时向下游发送barriers第二步：checkpoint in progress，ack记录source的postions为6791的位置，发送给master，并在收到上游2个并发依赖的barrier之后写入一个snapshots在statebackend中，同时告诉master记录checkpoint data中继续向下游发送next barrier第三步：checkpoint completed 当下游收到3个并发依赖的barrier之后，会在checkpoint data中更新sink已经发送完毕

提高吞吐Exactly Once vs. At Least Once

checkpoint时的对齐步骤可能增加流式程序的等待时间。通常，这种额外的延迟大约为几毫秒，但也会见到一些延迟显着增加的情况。对于要求所有记录始终具有超低延迟（几毫秒）的应用程序，Flink可以在checkpoint期间跳过流对齐。一旦操作算子看到每个输入流的checkpoint barriers，就会写 checkpoint 快照。当跳过对齐时，即使在 checkpoint n的某些 checkpoint barriers 到达之后，操作算子仍继续处理所有输入。这样，操作算子还可以在创建 checkpoint n 的状态快照之前，继续处理属于checkpoint n + 1的数据。在还原时，这些记录将作为重复记录出现，因为它们都包含在 checkpoint n 的状态快照中，并将作为 checkpoint n 之后数据的一部分进行重复处理

异步状态快照

注意：上面描述的机制意味着操作符在状态后端存储状态快照时停止处理输入记录。每次捕获快照时，此同步状态快照都会引入延迟。可以让操作员在存储状态快照时继续处理，从而有效地让状态快照在后台异步发生。要做到这一点，操作符必须能够生成一个状态对象，该对象应该以一种对操作符状态的进一步修改不会影响该状态对象的方式存储。例如，在RocksDB中使用的即写即拷数据结构具有这种行为。在接收到其输入上的检查点屏障之后，操作符启动对其状态的异步快照复制。它立即向输出发出屏障，并继续进行常规的流处理。一旦后台复制过程完成，它向检查点协调器(JobManager)确认检查点。检查点现在只有在所有接收到屏障和所有有状态操作符确认它们的完整备份(可能是在屏障到达接收点之后)之后才完成。

数据恢复

恢复机制非常清晰明了，一旦失败发生，Flink 会选择最新的快照 k。系统会重新部署全部的数据流。将每一个操作对象的状态恢复为快照中记录的内容。数据源也会被重置到快照点的位置。如果快照是增量式的。那么操作对象会恢复到最新的全量状态，然后开始应用一系列的增量快照的更新数据。

代码验证-Flink本地环境搭建

https://flink.apache.org/downloads.html

1.下载flink相关安装包2.解压flink的压缩包，查看里面目录结构

修改flink-conf.yaml，设置flink的checkpoint允许保留20个历史的checkpointstate.checkpoints.num-retained: 20

启动flink./bin/start-cluster.sh登录flink页面http://localhost:8081/#/overview

代码验证-测试代码

跟着这个博客练习就行了，里面有测试代码，我就不贴了https://blog.csdn.net/javajxz008/article/details/86218148这篇博客介绍的是yarn-cluster模式的，咱们由于有了本地环境，直接用yarn alone模式j举行保持状态和通过状态启动可以参考这个博客https://www.jianshu.com/p/8e74c7cdd463

总结

信心是靠动手锻炼出来的，尽量花时间去实操一下。

公益项目

2019年9月10号教师节组建的公益星球，在此感谢🙏三位嘉宾无偿支持。

邀请你的小伙伴来学习吧