Flink Checkpoint机制

checkpoint是啥

简单点说，就是将正在运行的任务的状态保存下来。这个状态包括任务中每个算子的state，缓存的数据（比如processFunction）等。可以保存在hdfs，磁盘等。

为什么需要checkpoint

当flink的任务或者机器挂掉了，重新启动任务时需要将任务恢复到原来的状态。当然这个恢复程度可以由你自己定，比如excatly-once，at-least-once等。

checkpoint 如何做到excatly-once？

以下场景选至《Flink基础教程》

初始状态

上图中的场景表示：
数据流： ，根据word分区，统计word的总次数。

读到ckpt

当flink的数据源处理到ckpt时，他会将当前数据源的offset落盘。

下游算子接收到ckpt

当map算子接受到ckpt时，会将该算子的状态（中间结果）落盘，此时的中间结果为 b 的总数为5，c 的总数为1。

异常发生

次数处理c的算子实例挂掉了，任务需要重新启动。恢复过程如下

拓扑恢复

ckpt之前的数据不会被重放，数据源会从位置1，2，3重放，也就是说ckpt后面三个元素会被重放，此时算子的中间状态（,）也会被恢复。

聪明的同学可能会想到，这样做map算子虽然可能多次接收到同一个数据，但是其逻辑是正确的，所以flink内部确实实现的excatly-once。 但是，试想一个场景，如果map中每次的中间结果都会落盘，那拓扑重启时，map会接收到重复数据，也就意味着数据库会出现相同的操作。这是不行的，所以说光靠flink内部的exactly-once是不行滴。也需要端到端的保证，那么如何保证flink到存储介质的excatly-once语义呢，大体有两种方案：

1. sink缓存数据，也等到接受到ckpt时一次性输出。
2. 每次都输出，提供类似事务回滚的机制。

熟悉数据库事务的同学，应该会联想到两种事务隔离级别和上面一一对应：

1. read-commit
2. read-uncommit

本篇没有涉及到具体的细节，以下是我学习时遇到的问题：

1. 每一个算子的实例都会接受到ckpt，那当前算子应该是等到所有实例都接受到了才会触发ckpt。
2. 上游算子的ckpt已经触发了，如果下游还没接受到就任务重启了，那岂不是这部分数据下次就不会重现了。（应该是等最后一个算子接收到了ckpt，本次ckpt才算数）