flink exactly-once实现原理海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

这一讲解Flink“精确一次”的语义实现原理，同时这也是面试的必考点。

Flink的“精确一次”处理语义是，Flink提供了一个强大的语义保证，也就是说在任何情况下都能保证数

据对应用产生的效果只有一次，不会多也不会少。

那么Flink是如何实现“端到端的精确一次处理”语义的呢？

背景

通常情况式计算系统都会为用户提供指定数据处理的可靠模式功能，用来表明在实际生产运行中

会对数据处理做哪些保障。一般来说，流处理引擎通常为用户的应用程序提供三种数据处理语义：最多

一次、至少一次和精确一次。

最多一次（At-most-Once）：这种语义理解起来很简单，用户的数据只会被处理一次，不管成功

还是失败，不会重试也不会重发。

至少一次（At-least-**Once）**：这种语义下，系统会保证数据或至少被处理一次。如果中

间发生错误或者丢失，那么会从重新发送一条然后进入处理系统，所以同一个或者消息会

被处理多次。

精确一次（Exactly-**Once）**：表示每一条数据只会被精确地处理一次，不多也不少。

Exactly-Once是Flink、Spark等流处理系统的特性之一，这种语义会保证每一条消息只被流处理

系统处理一次。“精确一次”语义是Flink1.4.0版本引入的一个重要特性，而且，Flink号称支持“端到端

的精确一次”语义。

在这里我们解释一下“端到端（EndtoEnd）的精确一次”，它指的是Flink应用从Source端开始到

Sink端结束，数据必须经过的起始点和结束点。Flink自身是无法保证外部系统“精确一次”语义的，所

以Flink若要实现所谓“端到端（EndtoEnd）的精确一次”的要求，那么外部系统必须支持“精确一次”

语义；然后借助Flink提供的分布式快照和两阶段提交才能实现。

分布式快照机制

我们在之前的课程中讲解过Flink的容错机制，Flink提供了失败恢复的容错机制，而这个容错机制的核

心就是持续创建分布式数据流的快照来实现。

同Spark相比，Spark仅仅是针对Driver的故障恢复Checkpoint。而Flink的快照可以到算子级别，

并且对全局数据也可以做快照。Flink的分布式快照受到Chandy-Lamport分布式快照算法启发，同时进

行了量身定做，有的同学可以搜一下。

Barrier

Flink分布式快照的元一是Barrier（数据栅栏），我们也可以把Barrier简单地理解成一个标

记，该标记是严格有序的，并且随着数据流往动。每个Barrier都带有自己的ID，Barrier极其轻

量，并不会干扰正常的数据处理。

如上图所示，假如我们有一个从左向右流动的数据流，Flink会依次生成snapshot1、snapshot2、

snapshot3……Flink中有一个专门的“协调者”负责收集每个snapshot的位置信息，这个“协调者”也

是高可用的。

Barrier会随着正常数据继续往动，每当遇到一个算子，算子会一个标识，这个标识的时

间是上游所有的输入流都接收到snapshotn。与此同时，当我们的sink算子接收到所有上游流发送的

Barrier时，那么就表明这一批数据处理完毕，Flink会向“协调者”发送确认消息，表明当前的

snapshotn完成了。当所有的sink算子都确认这批数据成功处理后，那么本次的snapshot被标识为

完成。