checkpoint是啥
简单点说，就是将正在运行的任务的状态保存下来。这个状态包括任务中每个算子的state，缓存的数据（比如processFunction）等。可以保存在hdfs，磁盘等。
为什么需要checkpoint
当flink的任务或者机器挂掉了，重新启动任务时需要将任务恢复到原来的状态。当然这个恢复程度可以由你自己定，比如excatly-once，at-least-once等。
checkpoint 如何做到excatly-once？
以下场景选至《Flink基础教程》
初始状态
上图中的场景表示：
数据流：<word,time> ，根据word分区，统计word的总次数。
读到ckpt
当flink的数据源处理到ckpt时，他会将当前数据源的offset落盘。
下游算子接收到ckpt
当map算子接受到ckpt时，会将该算子的状态（中间结果）落盘，此时的中间结果为 b 的总数为5，c 的总数为1。
异常发生
次数处理c的算子实例挂掉了，任务需要重新启动。恢复过程如下
拓扑恢复
ckpt之前的数据不会被重放，数据源会从位置1，2，3重放，也就是说ckpt后面三个元素会被重放，此时算子的中间状态（<b,5>,<cm1>）也会被恢复。
聪明的同学可能会想到，这样做map算子虽然可能多次接收到同一个数据，但是其逻辑是正确的，所以flink内部确实实现的excatly-once。 但是，试想一个场景，如果map中每次的中间结果都会落盘，那拓扑重启时，map会接收到重复数据，也就意味着数据库会出现相同的操作。这是不行的，所以说光靠flink内部的exactly-once是不行滴。也需要端到端的保证，那么如何保证flink到存储介质的excatly-once语义呢，大体有两种方案：
- sink缓存数据，也等到接受到ckpt时一次性输出。
- 每次都输出，提供类似事务回滚的机制。
熟悉数据库事务的同学，应该会联想到两种事务隔离级别和上面一一对应：
- read-commit
- read-uncommit
本篇没有涉及到具体的细节，以下是我学习时遇到的问题：
- 每一个算子的实例都会接受到ckpt，那当前算子应该是等到所有实例都接受到了才会触发ckpt。
- 上游算子的ckpt已经触发了，如果下游还没接受到就任务重启了，那岂不是这部分数据下次就不会重现了。（应该是等最后一个算子接收到了ckpt，本次ckpt才算数）
