flink 四大基石之checkpoint

flink 四大基石之checkpoint
checkpoint这是 Flink 最重要的一个特性。Flink 基于 Chandy-Lamport 算法实现了一个分布式的一致性的快照，从而提供了一致性的 语义。Chandy-Lamport 算法实际上在 1985 年的时候已经被提出来，但并没有 被很广泛的应用，而 Flink 则把这个算法发扬光大了。
checkpoint可以理解为是对所有的operator的状态的一个全局的保留.例如一个程序包含source,transformation,sink这三个步骤,那么checkpoint执行一次就是保留这三个步骤的状态,这就是完整实现一次checkpoint.
checkpoint 是把 state 数据定时持久化存储了，则表示 了一个 Flink Job 在一个特定时刻的一份全局状态快照，即包含了所有 task/operator 的状态.
checkpoint的执行流程:

算子是有一个输入的时候

1. 每个需要 checkpoint 的应用在启动时，Flink 的 JobManager 为其创建一个 CheckpointCoordinator(检查点协调器)，CheckpointCoordinator 全权负责本应用的快照制作,
   2.CheckpointCoordinator(检查点协调器) 周期性(根据你设置的多久checkpoint的时间)的向该流应用的所有 source 算子发送 barrier(屏障)
   3.收到barrier的算子，便暂停数据处理过程(时间比较短)，然后将 自己的当前状态制作成快照，并保存到指定的持久化存储中(这个过程是异步进行)，最后向 CheckpointCoordinator 报告自己快照制作情况，同时向自身所有下游算 子广播该 barrier，恢复数据处理
   4.下游算子收到 barrier 之后，会暂停自己的数据处理过程，然后将自身的 相关状态制作成快照，并保存到指定的持久化存储中，最后向 CheckpointCoordinator 报告自身快照情况，同时向自身所有下游算子广 播该 barrier，恢复数据处理。
   5.每个算子按照步骤 3 不断制作快照并向下游广播，直到最后 barrier 传递 到 sink 算子，快照制作完成.
   6.当 CheckpointCoordinator 收到所有算子的报告之后，认为该周期的快照 制作成功; 否则，如果在规定的时间内没有收到所有算子的报告，则认为 本周期快照制作失败.

2算子是有多个输入的时候
1. 算子 C 有 A 和 B 两个输入源
2. 在第 i 个快照周期中，由于某些原因(如处理时延、网络时延等)输入源 A 发出的 barrier 先到来，这时算子 C 暂时将输入源 A 的输入通道阻塞， 仅收输入源 B 的数据。
3. 当输入源 B 发出的 barrier 到来时，算子 C 制作自身快照并向 CheckpointCoordinator 报告自身的快照制作情况，然后将两个 barrier 合并为一个，向下游所有的算子广播。
4. 当由于某些原因出现故障时，CheckpointCoordinator 通知流图上所有算 子统一恢复到某个周期的 checkpoint 状态，然后恢复数据流处理。分布 式 checkpoint 机制保证了数据仅被处理一次(Exactly Once)。

   checkpoint也是将各个算子的状态(state->存在在 java 的堆内存中，TaskManage 节点的内存中。 operator ->表示一些算子在运行的过程中会产生的一些中间结果。)checkpoint就是将这些持久化到存储介质中,目前有三种存储的状态可选:MemStateBackend,FsStateBackend,RocksDBStateBackend.
   1>MemStateBackend
   该持久化存储主要是将快照存储到jobManager的内存中,仅适合作为测试以及快照的数据量非常小的时候使用,并不适合大规模的商业部署,
 MemoryStateBackend 的局限性： 默认情况下，每个状态的大小限制为 5 MB。可以在 MemoryStateBackend 的构造 函数中增加此值。 无论配置的最大状态大小如何，状态都不能大于 akka 帧的大小（请参阅配置）。 聚合状态必须适合 JobManager 内存。 建议 MemoryStateBackend 用于： 本地开发和调试。 状态很少的作业，例如仅包含一次记录功能的作业（Map，FlatMap，Filter，...）， kafka 的消费者需要很少的状态
 2>FsStateBackend
  该持久化存储主要将快照数据保存到文件系统中，目前支持的文件系统主要是 HDFS 和本地文件。如果使用 HDFS，则初始化 FsStateBackend 时，需要传入以 “hdfs://”开头的路径(即: new FsStateBackend("hdfs:///hacluster/checkpoint"))， 如果使用本地文件，则 需要传入以“file://”开头的路径(即:new FsStateBackend("file:///Data"))。在分布式情况下，不推荐使用本地文件。 如果某 个算子在节点 A 上失败，在节点 B 上恢复，使用本地文件时，在 B 上无 法读取节点 A 上的数据，导致状态恢复失败。 建议 FsStateBackend： 具有大状态，长窗口，大键 / 值状态的作业。 所有高可用性设置。
 3>RocksDBStateBackend
 RocksDBStatBackend 介于本地文件和 HDFS 之间，平时使用 RocksDB 的功能，将 数 据持久化到本地文件中，当制作快照时，将本地数据制作成快照，并持久化 到 FsStateBackend 中(FsStateBackend 不必用户特别指明，只需在初始化时传 入 HDFS 或本地路径即可，如 new RocksDBStateBackend("hdfs:///hacluster/checkpoint")或 new RocksDBStateBackend("file:///Data"))。 如果用户使用自定义窗口(window)，不推荐用户使用 RocksDBStateBackend。在 自定义窗口中，状态以 ListState 的形式保存在 StatBackend 中，如果一个 key 值中有多个 value 值，则 RocksDB 读取该种 ListState 非常缓慢，影响性能。用 户可以根据应用的具体情况选择 FsStateBackend+HDFS RocksStateBackend+HDFS。