Flink随笔：一个关于SnapShot机制的算法

在Flink中提供了一种基于点检查(Check Point)机制和SnapShot的容错回复机制。这个机制的提出与应用是因为考虑到现实应用中因为追求低时延性而发生的丢包，或者是单点故障恢复等等一系列的问题。因此Flink会动态地去保存各个算子和相应时间下的状态量，以备在发生故障时进行恢复。

所谓SnapShot算法，顾名思义，可以理解为在某一个时刻对全局的算子和事件进行一次拍照以储存相应的状态量。

贴一下我参考的文献：

在这篇文献中，提出了一种snapshot的算法：
【ABS算法for Acyclic dataflow】
一个中心的协调者周期性地注入stage barrier进入每一个数据源中，之后就把这些barrier广播给其下游的所有输出中。如果一个非源项的任务算子在一次接收input的时候拿到了这个barrier，那么它就会锁住这一个input，直到这个任务算子拿到了上一级的所有input，那么这个任务算子就会进行一次snapshot，然后进行解锁，于是所有的数据可以直接进入下游。

注意：只有在一个任务算子拿到了上一级的所有输入时，才会进行拍照并解锁barrier。这么做的原因是，Flink始终是一个面向于事务流的分布式处理软件，如果不使用Barrier来进行约束，就会出现这样的情况：在上游的某些数据还没有流入算子中的时候，Flink就已经拍照，如果这样去进行容错恢复，那么这个没有来得及进入算子的数据就会因为没有被及时记录下来而产生丢包。

一个好的snapshot算法必须要保证两个特点：
1.Termination:即能够有最终的结果(无环)，由于通道(channel)和非循环执行的拓扑，可以很容易地保证。
2.Feasibility:由于通道(channel)的先进先出机制(FIFO)，也可以很容易地保证。

【ABS算法for Acyclic dataflow】
考虑到以上的算法并不适用于循环数据流的处理模式。提出了针对有迭代的数据处理的算法。

由于数据一直在执行一个循环，会出现一个deadlock，最终的Termination是没有办法保证的。

一旦一个任务算子拿到了上一级的所有input，那么这个算子就会本地记录下所有的上一级数据状态，然后解锁。在最终得到的这一级snapshot中，也包括了预先已经进入循环被染色的数据。

一个好的snapshot算法必须要保证两个特点：
1.Termination:由于得到barrier就立即解锁释放给下一级，而不需要等待所有的input，可以保证。
2.Feasibility:由于通道(channel)的先进先出机制(FIFO)，也可以很容易地保证。

（以前一直以为Flink的SnapShot就只是单纯地拍照储存一下数据而已…现在看来，只要是考虑到“实时性”和“分布式”的问题，相应的工作都不好做啊。）