flink exactly-once系列之最终一致性

flink exactly-once系列目录：

一、两阶段提交概述 二、两阶段提交实现分析 三、StreamingFileSink分析 四、事务性输出实现 五、最终一致性实现

flink 实现端到端的Exactly-Once 常见两种方案：

1. 幂等性 幂等性要求输出的结果数据具有唯一性，也就是要求具有唯一键或者联合唯一键，这类应用最常见的就是窗口聚合结果数据输出，并且结果带上窗口信息，由于窗口不会重复并且多次计算结果也不会改变（对于EventTime）, 只需要接收端能够保证唯一性即可，例如Redis/HBase 的Key, Mysql中Unique Key
2. 事务性 事务性输出保证需要接收端提供事务支持，通过两阶段提交方式实现，在前几篇中做过着重分析，也是比较复杂的实现方式，除了对Kafka/HDFS支持实现，通常应用于结果之间具有关联性的场景

今天给大家带来端到端Exactly-Once中第三种实现方案：最终一致性，最终一致性实现方案相对来说是比较简单的，其依托Flink 的Checkpoint机制与内部状态存储来实现，Flink本身是支持内部Exactly-Once语义，那我们可以将所有的结果数据都保存在状态中，数据到输出端的过程仅仅是从状态中取数据的过程，当任务失败重启，Flink状态可恢复到最近一次成功checkpoint点，如果在该checkpoint点之后已经有数据输出，那么就可能会出现状态数据与输出端数据不一致的情况，但是随着任务的执行，通过覆盖的形式输出，最终保证状态与输出端的数据的一致性。

看一个常见的例子wordcount单词计数：

    env.addSource(consumer)
 .map((_,1))
 .keyBy(_._1)
 .sum(1)
 .print()

sum算子就是在状态中保存了所有的单词与单词数量的数据，每次单词处理只需要将在状态中对应的数量取出来加一并且更新到状态中，然后输出即可，状态内部永远都保存着正确的结果数据，如果使用两阶段提交事务性输出，那么其实现的复杂程度是远远比这个要高的。这种实现方案需要注意的是结果数据都保存在状态中，那么需要合理设置状态TTL，控制状态的大小。

对于Flink端到端Exactly-Once实现方案中，每一种都有其应用场景与使用限制，在实际中根据实际的使用场景来选择。