Flink是如何保证exactly-once的

前言

（1）流式计算分为有状态计算和无状态计算。

无状态的计算观察每个独立事件，并根据最后一个时间输出结果。

有状态的计算则会基于多个时间输出结果。

（2）在流处理中，需要保持数据一致性处理，而一致性处理分为3级别。

at-most-once：故障发生之后，技术结构可能丢失。

at-least-once：计数结果可能大于正确值，绝不会少于正确值。

exactly-once：系统保证在发生故障后得到的计数结果与正确值一致。

最先保证exactly-once的系统在性能和表现力这两个方面付出了很大的代价。为了保证exactly-once，这些系统无法单独对每条记录运用应用逻辑，而是同事处理多条记录，保证对每一批的处理要么全部成功，要么全部失败。这就导致在得到结果前，必须等待一批记录处理结构。因此用户不得不使用两个流处理框架，结果使基础设施更加复杂。而Flink最大的一个价值，就在于它既保证了exactly-once，也具有低延迟和高吞吐的处理能力。

检查点：保证exactly-once

检查点是Flink最有价值的创新之一，它使Flink可以保证exactly-once，并且不需要牺牲任何性能。

下面介绍一下检查点是如何保证exactly-once的？

首先在数据进行流处理的过程中分，会有检查点屏障。它们由算子处理，但是不参与计算，而是会触发与检查点相关的行为。当读取输入流的数据源遇到检查点屏障时，它将其在输入流中的位置保存到稳定存储中。如果输入流来自消息传输系统，这个位置就是偏移量。检查点屏障像普通记录一样在算子之间流动。当算子的状态和检查点屏障的位置备份被确认之后，该检查点操作标记为完成。我们无须停止或阻断计算的条件下，在一个逻辑时间点（对应检查点屏障在输入流中的位置）为计算状态拍下了快找。通过确保备份的状态和位置指向同一个逻辑时间点，从而保证exactly-once。值得注意的是，当没有出现故障时，Flink检查点的开销极小，检查点操作的速度由稳定存储的可用带宽决定。如果检查点操作失败，Flink会丢弃检查带你并继续正常执行，因为之后的某一个检查点可能会成功。虽然恢复时间可能更长，但是对于状态的保证依旧准确。只有在一系列的检查点操作失败之后，Flink才会抛出错误。