Flink数据流容错原理

介绍

Flink提供一种容错原理能够恢复数据流应用状态，这个原理确保在失败发生的时候，能够使数据流应用处理数据exactly once。当然也可以以at least once的方式处理数据。
容错原理是持续画分布式流数据流转的snapshot，因为流应用拥有少的状态，所以这些snapshots非常轻量级，在频繁画snapshot的情况下，对性能没太大影响。流应用的状态存储在一个可配置的地方（例如，master node或者HDFS）。
如果程序失败（例如，由于机器，网络，软件原因失败），Flink停止分布式流数据流转，系统然后重新启动operators，重置这些operators到最新的成功的checkpoint，输入流也会重置到当时snapshot的点。确保重新启动后要处理的数据并不是之前checkpointing的数据。
默认，checkpointing是关闭状态
为了实现该机制充分保证，数据流源（例如消息队列）能够返回到定义的点，Kafka就具有这种能力，Flink连接kafka的connector就是利用这个能力
由于Flink的checkpoints是通过分布式snapshots实现的，单词snapshot和checkpoint是可互换的

Checkpointing

Flink容错原理核心就是记录分布式数据流和operator状态的一致性snapshots。这些snaphosts作为一致性checkpoints，当有失败 发生时，系统可以返回到checkpoints。Flink记录snapshots的原理是使用Lightweight Asynchronous Snapshots for Distributed Dataflows。

Barriers

Flink分布式snapshotting的核心元素就是stream barriers，这些barriers注入到数据流中，随着数据一起流转。Barriers并不会超越数据，严格的按照顺利流转。一个barrier切割数据流中的数据为两部分，一部分是进入当前snapshot的数据，另一部分是进入下一个snapshot的数据。每个barrier会携带一个snapshot的ID，会推送barrier之前的数据到这个snapshot。Barriers并不会阻碍流数据的流转，因此非常轻量级。不同snapshots的多个barriers可以同时出现在流数据管道中，这意味多种snapshots可以并行发生。

barriers注入到并行的数据流转中，snapshot n注入的barriers的点（称为Sn）就是snapshot发生时，源数据流的点，例如，在kafka中，这个位置就是分区中最后一条记录的偏移量，这个位置Sn会被报告给checkpoint coordinator（Flink的JobManager）。
barriers然后往下流流转，当中间operator接收到所有输入流中snapshot n的barrier，它会发送snapshot n的barrier到输出流。只要一个sink operator（一个流 DAG的终点）接收到所有输入流中snapshot n的barrier，它会承认snapshot n到checkpoint coordinator，当所有的sinks都承认这个snapshot后，就表示已经完成。
只要snapshot n完成后，job并不会再请求source中在Sn之前的数据，因为在在Sn之前的数据已经全部流转完成了。

需要接收多个输入流的operators需要在snapshot barriers上对齐输入流，上图展示该过程：

1. 只要operator接收到一个输入流的snapshot barrier n，它并不会处理该输入流的接下来数据，直到它也接收到其他输入流的snapshot barrier n，否则的话，会混合属于snapshot n+1和snapshot n的数据。
2. 报告barrier n的输入流暂时被搁置，从这些输入流已经接收到的数据并不会被处理，而是放到一个input buffer。
3. 只要最后的输入流已经报告barrier n，operator发出所以待定输出的数据，然后发出一个snapshot n barriers。

State

operator包含不同形式的状态，这些状态也是snapshots的一部分，Operator state以不同的形式展现：

1. 用户自定义状态：这些状态可以通过transform方法（例如，map()，filter()）创建和修改
2. 系统状态：这些状态是数据缓存，这些数据缓存是operator计算的一部分。典型的例子是window buffers，系统为一个window收集数据，直到window计算完成，才会清除。

Operators直到从所有输入流中接收到所有snapshot barriers才会快照他们的状态，但是在发送barriers到输出流之前。因为一个snapshot的状态可能非常大 ，所以存储在一个可配置的state backend。默认是在JobManager的内存，但是对于生产环境，应该使用一个分布式可靠的存储，例如HDFS。当状态存储后，operator承认这个checkpoint，发送snapshot barrier到输出流，继续处理。
最终的snapshot包含：

1. 对于每个并行的流数据源，当snapshot开始时，流数据源在数据流的位置
2. 对每个operator，一个指针指向存储的状态
   

Exactly Once vs At Least Once

对齐步骤可能会增加对流应用的延迟，通常这种额外延迟仅仅是几毫秒，但是也会存在异常的延迟显著提高。对于那些需要超级低延迟的应用来说，Flink在checkpoint的时候可以选择跳过流对齐。一个operator从每个输入流看到checkpoint barrier就会记录snapshots。
当对齐跳过时，一个operator仍然会处理接收到的数据，甚至当对于checkpoint n的一些barriers来到之后，这种情况下，在获取checkpoint n的snapshot之前，也会继续处理属于checkpoint n+1的数据。在恢复之前的时候，这些记录将会重复执行，因为他们既包含在checkpoint n中，也会在checkpoint n之后重新执行。
对齐操作仅仅发生在多个predecessors（joins）的operators和拥有多个senders（当流重组后）的operators中，由于这样，对于像map()，flatmap()，filter()这样的操作甚至在at least once的情况下也会实现exactly once