什么是数据的一致性
这所说的数据一致性指，在一个 Flink 任务遇到不可坑因素整体死掉或者部分死掉，已经外部存储介质死掉后，将死掉的部分重写启动后，计算结果和出现故障之前一致，不会产生任何的影响。
如果要实现这种效果，无论发生什么，所有算子做到如下要求：
- source 算子中，一条记录只向下游发送一次。
- 在聚合算子、合集算子、转换算子中一条数据只处理一次。
- 在 sink 算子中，一条数据只向外部存储介质中写入一次。
只要做到这些，我们就可以说，我们整个任务的数据是一致的。
今天就把 Flink 自己封装的 Kafka 的生产这和消费者拿出来看看，source 和 sink 是如何做数据一致性的。
刻舟求剑
大家都知道刻舟求剑的寓言故事。这个故事告诉做记号得重要性。同理，当我们每处理一条记录，我们就记录下来。
例如，类似如下格式的日志。
2021年6月16日10点32分 primary_key1 of a record每当算子处理完一条消息，就记录下如上所示的日志。加入这个算子的实例失败了，当我们重新启动的时候吧，我们可以查找此日志，查到这个日志，我们就可以找到我们在失败之前处理到哪里了，然后从哪里开发处理数据。
这是一个非常简单的情况。我们知道 Flink 是一个分布式系统，任务上的多个算子会被安排到不同的服务器上跑。一个分布式系统要想做“记号”那可不是简单。我们就来看看 Flink 是如何做的。下面的图片展示了 Flink 做“记号”的过程。这个过程就叫“二次提交”。
二次提交的流程：
- JM 发送 checkpoint trigger
- 执行 snapshotState 方法，这里会执行 producer 的 flush 方法。这个方法会将 producer 缓存里面的数据发送完。
- TM 将 barrier 的快照保存到 backend 里面，包括 kafka transaction id 和 checkpoint id 的对应关系。
- 发送 checkpoint ACK 给 JM。
- 当所有的算子实例执行完对应的 checkpoint 以后 JM 调用算子的 notifyCheckpointComplete() 方法，进行后续对状态的处理。如果有一个 TM 没有发送对应的 ACK ，那么，这次 checkpoint 都不能算执行完成，如果超过了时间，JM 会调用各个算子的 notifyCheckpointAborted 方法，取消这次 chekcpoint。
Flink 在类 TwoPhaseCommitFunction 中实现了二次提交的逻辑， TwoPhaseCommitFunction 是一个抽象类，所以只说它还是不给你完全的解释 FlinkKafkaProducer 的数据一致性。
第一阶段-准备阶段：
当一个 barrier 过来后，一个 producer 实例调用 snapshotSate() ,将transactionId、checkpointId 保存在本地的 pendingCommitTransaction 里面，并且开启 kafka 的一个事务，最后将 transactionID 放到 backend。这一步的目的是将单个算子里面记录一下，写到那个 transacton id 了，
第二阶段-提交：
当所有的 producer 实例都完成了在同一个 barrier 里面的 snaptshot ，JobMannager 会收到各个 producer 实例的 ack ，然后JobMannager 回调 producer.notifyCompleteCheckpoint() , 这个函数的处理逻辑是将 pendingCommitTransactiond 中等待提交的事务ID删除掉，并将在本次 barrier 中的 transactionId 提交给 Kafka Coordinator。这样就完成了一次 checkpoint 和 kafka 一次事务。这就保证了当一个完整的 checkpoint 执行结束后，Flink kafka Producer 才会提交 tranaction id ，如果发生什么异常(例如宕机)，checkpoint 无法完成，可能会重新启动任务，只要 transaction 没有提交，即使我们使用同一个 transaction 提交了重复的数据，也不会造成 kafka 里面数据重复，因为 Kafka coodinator 会悄悄的为我们去重的。
优点：模型简单，容易实现。
缺点：严重依赖 JobManager ，存在单节点故障隐患。
