Flink笔记整理（七）
文章目录
九、容错机制
在Flink中，有一套完整的容错机制来保证故障后的恢复，其中最重要的就是检查点。
9.1 检查点（Checkpoint）
检查点的保存
-
周期性的触发保存
"随时存档"确实恢复起来方便，可是需要我们不停地做存档操作。如果每处理一条数据就进行检查点的保存，当大量数据同时到来时，就会耗费很多资源来频繁做检查点，数据处理的速度就会受到影响。所以在Flink中，检查点的保存是周期性触发的，间隔时间可以进行设置。
保存的时间点
我们应该在所有任务（算子）都恰好处理完一个相同的输入数据的时候，将它们的状态保存下来。
这样做可以实现一个数据被所有任务（算子）完整地处理完，状态得到了保存。 如果出现故障，我们恢复到之前保存的状态，故障时正在处理的所有数据都需要重新处理；我们只需要让源（source）任务向数据源重新提交偏移量、请求重放数据就可以了。当然这需要源任务可以把偏移量作为算子状态保存下来，而且外部数据源能够重置偏移量；kafka就是满足这些要求的一个最好的例子。 -
保存的具体流程
检查点的保存，最关键的就是要等所有任务将"同一个数据"处理完毕。下面我们通过一个具体的例子，来详细描述一下检查点具体的保存过程。
回忆一下我们最初实现的统计词频的程序------word count。这里为了方便，我们直接从数据源读入已经分开的一个个单词，例如这里输入的是：
"hello"，"world"，"hello"，"flink"，"hello"，"world"，"hello"，"flink"...
我们所需要的就是每个任务都处理完"hello"之后保存自己的状态。
从检查点恢复状态
检查点算法
在Flink中，采用了基于Chandy-Lamport算法的分布式快照，可以在不暂停整体流处理的前提下，将状态备份保存到检查点。
检查点分界线（Barrier）
借鉴水位线的设计，在数据流中插入一个特殊的数据结构，专门用来表示触发检查点保存的时间点。收到保存检查点的指令后，Source任务可以在当前数据流中插入这个结构；之后的所有任务只要遇到它就开始对状态做持久化快照保存。由于数据流是保持顺序依次处理的，因此遇到这个标识就代表之前的数据都处理完了，可以保存一个检查点；而在它之后的数据，引起的状态改变就不会体现在这个检查点中，而需要保存到下一个检查点。
这种特殊的数据形式，把一条流上的数据按照不同的检查点分隔开，所以就叫做检查点的"分界线"（Checkpoint Barrier）。
9.2 状态一致性
9.3 端到端精确一次（End-To-End Exactly-Once）
端到端精确一次（End-To-End Exactly-Once）
总结
