Flink容错机制（二）

目录

10.2 状态一致性

10.2.1 一致性的概念和级别

 10.2.2 端到端的状态一致性

10.3 端到端精确一次（end-to-end exactly-once）

10.3.1 输入端保证

10.3.2 输出端保证

10.3.3 Flink 和 Kafka 连接时的精确一次保证

---

10.2 状态一致性

之前讲到检查点又叫作“一致性检查点”，是 Flink 容错机制的核心。接下来我们就对状 态一致性的概念进行展开，结合理论和实际应用场景，讨论一下 Flink 流式处理架构中的应对 机制。

10.2.1 一致性的概念和级别

在分布式系统中，一致性（consistency）是一个非常重要的概念；在事务（transaction） 中，一致性也是重要的一个特性。Flink 中一致性的概念，主要用在故障恢复的描述中，所以更加类似于事务中的表述。那到底什么是一致性呢？

简单来讲，一致性其实就是结果的正确性。对于分布式系统而言，强调的是不同节点中相同数据的副本应该总是“一致的”，也就是从不同节点读取时总能得到相同的值；而对于事务而言，是要求提交更新操作后，能够读取到新的数据。对于 Flink 来说，多个节点并行处理不同的任务，我们要保证计算结果是正确的，就必须不漏掉任何一个数据，而且也不会重复处理 同一个数据。流式计算本身就是一个一个来的，所以正常处理的过程中结果肯定是正确的；但 在发生故障、需要恢复状态进行回滚时就需要更多的保障机制了。我们通过检查点的保存来保证状态恢复后结果的正确，所以主要讨论的就是“状态的一致性”。

一般说来，状态一致性有三种级别：

⚫ 最多一次（AT-MOST-ONCE）

当任务发生故障时，最简单的做法就是直接重启，别的什么都不干；既不恢复丢失的状态， 也不重放丢失的数据。每个数据在正常情况下会被处理一次，遇到故障时就会丢掉，所以就是 “最多处理一次”。

我们发现，如果数据可以直接被丢掉，那其实就是没有任何操作来保证结果的准确性；所 以这种类型的保证也叫“没有保证”。尽管看起来比较糟糕，不过如果我们的主要诉求是“快”， 而对近似正确的结果也能接受，那这也不失为一种很好的解决方案。

⚫ 至少一次（AT-LEAST-ONCE）

在实际应用中，我们一般会希望至少不要丢掉数据。这种一致性级别就叫作“至少一次” （at-least-once），就是说是所有数据都不会丢，肯定被处理了；不过不能保证只处理一次，有些数据会被重复处理。

在有些场景下，重复处理数据是不影响结果的正确性的，这种操作具有“幂等性”。比如， 如果我们统计电商网站的 UV，需要对每个用户的访问数据进行去重处理，所以即使同一个数据被处理多次，也不会影响最终的结果，这时使用 at-least-once 语义是完全没问题的。当然， 如果重复数据对结果有影响，比如统计的是 PV，或者之前的统计词频 word count，使用at-least-once 语义就可能会导致结果的不一致了。

为了保证达到 at-least-once 的状态一致性，我们需要在发生故障时能够重放数据。最常见的做法是，可以用持久化的事件日志系统，把所有的事件写入到持久化存储中。这时只要记录 一个偏移量，当任务发生故障重启后，重置偏移量就可以重放检查点之后的数据了。Kafka 就是这种架构的一个典型实现。

⚫ 精确一次（EXACTLY-ONCE）

最严格的一致性保证，就是所谓的“精确一次”（exactly-once，有时也译作“恰好一次”）。 这也是最难实现的状态一致性语义。exactly-once 意味着所有数据不仅不会丢失，而且只被处理一次，不会重复处理。也就是说对于每一个数据，最终体现在状态和输出结果上，只能有一 次统计。 exactly-once 可以真正意义上保证结果的绝对正确，在发生故障恢复后，就好像从未发生 过故障一样。

很明显，要做的 exactly-once，首先必须能达到 at-least-once 的要求，就是数据不丢。所以 同样需要有数据重放机制来保证这一点。另外，还需要有专门的设计保证每个数据只被处理一 次。Flink 中使用的是一种轻量级快照机制——检查点（checkpoint）来保证 exactly-once 语义。

 10.2.2 端到端的状态一致性

我们已经知道检查点可以保证 Flink 内部状态的一致性，而且可以做到精确一次 （exactly-once）。那是不是说，只要开启了检查点，发生故障进行恢复，结果就不会有任何问题呢？

没那么简单。在实际应用中，一般要保证从用户的角度看来，最终消费的数据是正确的。 而用户或者外部应用不会直接从 Flink 内部的状态读取数据，往往需要我们将处理结果写入外 部存储中。这就要求我们不仅要考虑 Flink 内部数据的处理转换，还涉及从外部数据源读取， 以及写入外部持久化系统，整个应用处理流程从头到尾都应该是正确的。

所以完整的流处理应用，应该包括了数据源、流处理器和外部存储系统三个部分。这个完 整应用的一致性，就叫作“端到端（end-to-end）的状态一致性”，它取决于三个组件中最弱的 那一环。一般来说，能否达到 at-least-once 一致性级别，主要看数据源能够重放数据；而能否 达到 exactly-once 级别，流处理器内部、数据源、外部存储都要有相应的保证机制。

10.3 端到端精确一次（end-to-end exactly-once）

实际应用中，最难做到、也最希望做到的一致性语义，无疑就是端到端（end-to-end）的 “精确一次”（exactly-once）。我们知道，对于 Flink 内部来说，检查点机制可以保证故障恢复后数据不丢（在能够重放的前提下），并且只处理一次，所以已经可以做到 exactly-once 的一 致性语义了。

需要注意的是，我们说检查点能够保证故障恢复后数据只处理一次，并不是说之前统计过某个数据，现在就不能再次统计了；而是要看状态的改变和输出的结果，是否只包含了一次这个数据的处理。由于检查点保存的是之前所有任务处理完某个数据后的状态快照，所以重放的数据引起的状态改变一定不会包含在里面，最终结果中只处理了一次。

所以，端到端一致性的关键点，就在于输入的数据源端和输出的外部存储端。

10.3.1 输入端保证

输入端主要指的就是 Flink 读取的外部数据源。对于一些数据源来说，并不提供数据的缓冲或是持久化保存，数据被消费之后就彻底不存在了。例如 socket 文本流就是这样， socket服务器是不负责存储数据的，发送一条数据之后，我们只能消费一次，是“一锤子买卖”。对 于这样的数据源，故障后我们即使通过检查点恢复之前的状态，可保存检查点之后到发生故障 期间的数据已经不能重发了，这就会导致数据丢失。所以就只能保证 at-most-once 的一致性语 义，相当于没有保证。

想要在故障恢复后不丢数据，外部数据源就必须拥有重放数据的能力。常见的做法对数据进行持久化保存，并且可以重设数据的读取位置。一个最经典的应用就是 Kafka。在 Flink的 Source 任务中将数据读取的偏移量保存为状态，这样就可以在故障恢复时从检查点中读取出来，对数据源重置偏移量，重新获取数据。

数据源可重放数据，或者说可重置读取数据偏移量，加上Flink的Source算子将偏移量作为状态保存进检查点，就可以保证数据不丢。这是达到 at-least-once 一致性语义的基本要求， 当然也是实现端到端 exactly-once 的基本要求。

10.3.2 输出端保证

有了 Flink 的检查点机制，以及可重放数据的外部数据源，我们已经能做到 at-least-once了。但是想要实现 exactly-once 却有更大的困难：数据有可能重复写入外部系统。

因为检查点保存之后，继续到来的数据也会一一处理，任务的状态也会更新，最终通过Sink 任务将计算结果输出到外部系统；只是状态改变还没有存到下一个检查点中。这时如果 出现故障，这些数据都会重新来一遍，就计算了两次。我们知道对 Flink 内部状态来说，重复 计算的动作是没有影响的，因为状态已经回滚，最终改变只会发生一次；但对于外部系统来说， 已经写入的结果就是泼出去的水，已经无法收回了，再次执行写入就会把同一个数据写入两次。

所以这时，我们只保证了端到端的 at-least-once 语义。

为了实现端到端 exactly-once，我们还需要对外部存储系统、以及 Sink 连接器有额外的要求。能够保证 exactly-once 一致性的写入方式有两种：

⚫ 幂等写入

⚫ 事务写入

我们需要外部存储系统对这两种写入方式的支持，而 Flink 也为提供了一些 Sink 连接器接口。

1. 幂等（idempotent）写入

所谓“幂等”操作，就是说一个操作可以重复执行很多次，但只导致一次结果更改。也就 是说，后面再重复执行就不会对结果起作用了。

数学中一个典型的例子是，ex 的求导下操作，无论做多少次，得到的都是自身。

而在数据处理领域，最典型的就是对 HashMap 的插入操作：如果是相同的键值对，后面 的重复插入就都没什么作用了。

这相当于说，我们并没有真正解决数据重复计算、写入的问题；而是说，重复写入也没关系，结果不会改变。所以这种方式主要的限制在于外部存储系统必须支持这样的幂等写入：比 如 Redis 中键值存储，或者关系型数据库（如 MySQL）中满足查询条件的更新操作。

需要注意，对于幂等写入，遇到故障进行恢复时，有可能会出现短暂的不一致。因为保存点完成之后到发生故障之间的数据，其实已经写入了一遍，回滚的时候并不能消除它们。如果 有一个外部应用读取写入的数据，可能会看到奇怪的现象：短时间内，结果会突然“跳回”到 之前的某个值，然后“重播”一段之前的数据。不过当数据的重放逐渐超过发生故障的点的时 候，最终的结果还是一致的。

2. 事务（transactional）写入

如果说幂等写入对应用场景限制太多，那么事务写入可以说是更一般化的保证一致性的方式。

之前我们提到，输出端最大的问题就是“覆水难收”，写入到外部系统的数据难以撤回。 自然想到，那怎样可以收回一条已写入的数据呢？利用事务就可以做到。

我们都知道，事务（transaction）是应用程序中一系列严密的操作，所有操作必须成功完 成，否则在每个操作中所做的所有更改都会被撤消。事务有四个基本特性：原子性(Atomicity)、 一致性(Correspondence)、隔离性(Isolation)和持久性(Durability)，这就是著名的 ACID。

在 Flink 流处理的结果写入外部系统时，如果能够构建一个事务，让写入操作可以随着检 查点来提交和回滚，那么自然就可以解决重复写入的问题了。所以事务写入的基本思想就是： 用一个事务来进行数据向外部系统的写入，这个事务是与检查点绑定在一起的。当 Sink 任务 遇到 barrier 时，开始保存状态的同时就开启一个事务，接下来所有数据的写入都在这个事务 中；待到当前检查点保存完毕时，将事务提交，所有写入的数据就真正可用了。如果中间过程 出现故障，状态会回退到上一个检查点，而当前事务没有正常关闭（因为当前检查点没有保存完），所以也会回滚，写入到外部的数据就被撤销了。

具体来说，又有两种实现方式：预写日志（WAL）和两阶段提交（2PC）

（1）预写日志（write-ahead-log，WAL）

我们发现，事务提交是需要外部存储系统支持事务的，否则没有办法真正实现写入的回撤。 那对于一般不支持事务的存储系统，能够实现事务写入呢？

预写日志（WAL）就是一种非常简单的方式。具体步骤是：

①先把结果数据作为日志（log）状态保存起来。

②进行检查点保存时，也会将这些结果数据一并做持久化存储。

③在收到检查点完成的通知时，将所有结果一次性写入外部系统。

我们会发现，这种方式类似于检查点完成时做一个批处理，一次性的写入会带来一些性能 上的问题；而优点就是比较简单，由于数据提前在状态后端中做了缓存，所以无论什么外部存 储系统，理论上都能用这种方式一批搞定。在 Flink 中 DataStream API 提供了一个模板类GenericWriteAheadSink，用来实现这种事务型的写入方式。

需要注意的是，预写日志这种一批写入的方式，有可能会写入失败；所以在执行写入动作 之后，必须等待发送成功的返回确认消息。在成功写入所有数据后，在内部再次确认相应的检 查点，这才代表着检查点的真正完成。这里需要将确认信息也进行持久化保存，在故障恢复时，只有存在对应的确认信息，才能保证这批数据已经写入，可以恢复到对应的检查点位置。

但这种“再次确认”的方式，也会有一些缺陷。如果我们的检查点已经成功保存、数据也 成功地一批写入到了外部系统，但是最终保存确认信息时出现了故障，Flink 最终还是会认为 没有成功写入。于是发生故障时，不会使用这个检查点，而是需要回退到上一个；这样就会导 致这批数据的重复写入。

（2）两阶段提交（two-phase-commit，2PC）

前面提到的各种实现 exactly-once 的方式，多少都有点缺陷，有没有更好的方法呢？自然 是有的，这就是传说中的两阶段提交（2PC）。

顾名思义，它的想法是分成两个阶段：先做“预提交”，等检查点完成之后再正式提交。 这种提交方式是真正基于事务的，它需要外部系统提供事务支持。

具体的实现步骤为：

①当第一条数据到来时，或者收到检查点的分界线时，Sink 任务都会启动一个事务。

②接下来接收到的所有数据，都通过这个事务写入外部系统；这时由于事务没有提交，所以数据尽管写入了外部系统，但是不可用，是“预提交”的状态。

③当 Sink 任务收到 JobManager 发来检查点完成的通知时，正式提交事务，写入的结果就真正可用了。

当中间发生故障时，当前未提交的事务就会回滚，于是所有写入外部系统的数据也就实现了撤回。这种两阶段提交（2PC）的方式充分利用了 Flink 现有的检查点机制：分界线的到来， 就标志着开始一个新事务；而收到来自 JobManager 的 checkpoint 成功的消息，就是提交事务 的指令。每个结果数据的写入，依然是流式的，不再有预写日志时批处理的性能问题；最终提交时，也只需要额外发送一个确认信息。所以 2PC 协议不仅真正意义上实现了 exactly-once， 而且通过搭载 Flink 的检查点机制来实现事务，只给系统增加了很少的开销。 Flink 提供了 TwoPhaseCommitSinkFunction 接口，方便我们自定义实现两阶段提交的SinkFunction 的实现，提供了真正端到端的 exactly-once 保证。

不过两阶段提交虽然精巧，却对外部系统有很高的要求。这里将 2PC 对外部系统的要求 列举如下：

⚫ 外部系统必须提供事务支持，或者 Sink 任务必须能够模拟外部系统上的事务。

⚫ 在检查点的间隔期间里，必须能够开启一个事务并接受数据写入。

⚫ 在收到检查点完成的通知之前，事务必须是“等待提交”的状态。在故障恢复的情况 下，这可能需要一些时间。如果这个时候外部系统关闭事务（例如超时了），那么未提交的数据就会丢失。

⚫ Sink 任务必须能够在进程失败后恢复事务。

⚫ 提交事务必须是幂等操作。也就是说，事务的重复提交应该是无效的。

可见，2PC 在实际应用同样会受到比较大的限制。具体在项目中的选型，最终还应该是一致性级别和处理性能的权衡考量。

10.3.3 Flink 和 Kafka 连接时的精确一次保证

在流处理的应用中，最佳的数据源当然就是可重置偏移量的消息队列了；它不仅可以提供数据重放的功能，而且天生就是以流的方式存储和处理数据的。所以作为大数据工具中消息队 列的代表，Kafka 可以说与 Flink 是天作之合，实际项目中也经常会看到以 Kafka 作为数据源 和写入的外部系统的应用。在本小节中，我们就来具体讨论一下 Flink 和 Kafka 连接时，怎样 保证端到端的 exactly-once 状态一致性。

1. 整体介绍

既然是端到端的 exactly-once，我们依然可以从三个组件的角度来进行分析：

（1）Flink 内部 Flink 内部可以通过检查点机制保证状态和处理结果的 exactly-once 语义。

（2）输入端

输入数据源端的 Kafka 可以对数据进行持久化保存，并可以重置偏移量（offset）。所以我 们可以在 Source 任务（FlinkKafkaConsumer）中将当前读取的偏移量保存为算子状态，写入到 检查点中；当发生故障时，从检查点中读取恢复状态，并由连接器 FlinkKafkaConsumer 向 Kafka重新提交偏移量，就可以重新消费数据、保证结果的一致性了。

（3）输出端

输出端保证 exactly-once 的最佳实现，当然就是两阶段提交（2PC）。作为与 Flink 天生一 对的 Kafka，自然需要用最强有力的一致性保证来证明自己。 Flink 官方实现的 Kafka 连接器中，提供了写入到 Kafka 的 FlinkKafkaProducer，它就实现 了 TwoPhaseCommitSinkFunction 接口：

public class FlinkKafkaProducer<IN> extends TwoPhaseCommitSinkFunction<IN, 
FlinkKafkaProducer.KafkaTransactionState, 
FlinkKafkaProducer.KafkaTransactionContext> { 
... 
}

也就是说，我们写入 Kafka 的过程实际上是一个两段式的提交：处理完毕得到结果，写入Kafka 时是基于事务的“预提交”；等到检查点保存完毕，才会提交事务进行“正式提交”。如果中间出现故障，事务进行回滚，预提交就会被放弃；恢复状态之后，也只能恢复所有已经确认提交的操作。

2. 具体步骤

为了方便说明，我们来考虑一个具体的流处理系统，由 Flink 从 Kafka 读取数据、并将处 理结果写入 Kafka

这是一个 Flink 与 Kafka 构建的完整数据管道，Source 任务从 Kafka 读取数据，经过一系 列处理（比如窗口计算），然后由 Sink 任务将结果再写入 Kafka。 Flink 与 Kafka 连接的两阶段提交，离不开检查点的配合，这个过程需要 JobManager 协调 各个 TaskManager 进行状态快照，而检查点具体存储位置则是由状态后端（State Backend）来 配置管理的。一般情况，我们会将检查点存储到分布式文件系统上。

实现端到端 exactly-once 的具体过程可以分解如下：

（1）启动检查点保存

检查点保存的启动，标志着我们进入了两阶段提交协议的“预提交”阶段。当然，现在还 没有具体提交的数据。

JobManager 通知各个 TaskManager 启动检查点保存，Source 任务会将检 查点分界线（barrier）注入数据流。这个 barrier 可以将数据流中的数据，分为进入当前检查点 的集合和进入下一个检查点的集合。

（2）算子任务对状态做快照

分界线（barrier）会在算子间传递下去。每个算子收到 barrier 时，会将当前的状态做个快照，保存到状态后端。

Source 任务将 barrier 插入数据流后，也会将当前读取数据的偏移量作 为状态写入检查点，存入状态后端；然后把 barrier 向下游传递，自己就可以继续读取数据了。接下来 barrier 传递到了内部的 Window 算子，它同样会对自己的状态进行快照保存，写入远程的持久化存储。

（3）Sink 任务开启事务，进行预提交

分界线（barrier）终于传到了 Sink 任务，这时 Sink 任务会开启一个事 务。接下来到来的所有数据，Sink 任务都会通过这个事务来写入 Kafka。这里 barrier 是检查点 的分界线，也是事务的分界线。由于之前的检查点可能尚未完成，因此上一个事务也可能尚未 提交；此时 barrier 的到来开启了新的事务，上一个事务尽管可能没有被提交，但也不再接收 新的数据了。

对于 Kafka 而言，提交的数据会被标记为“未确认”（uncommitted）。这个过程就是所谓 的“预提交”（pre-commit）。

（4）检查点保存完成，提交事务当所有算子的快照都完成，也就是这次的检查点保存最终完成时，JobManager 会向所有任务发确认通知，告诉大家当前检查点已成功保存。

当 Sink 任务收到确认通知后，就会正式提交之前的事务，把之前“未确认”的数据标为 “已确认”，接下来就可以正常消费了。

在任务运行中的任何阶段失败，都会从上一次的状态恢复，所有没有正式提交的数据也会回滚。这样，Flink 和 Kafka 连接构成的流处理系统，就实现了端到端的 exactly-once 状态一致性。

3. 需要的配置

在具体应用中，实现真正的端到端 exactly-once，还需要有一些额外的配置：

（1）必须启用检查点；

（2）在 FlinkKafkaProducer 的构造函数中传入参数 Semantic.EXACTLY_ONCE；

（3）配置 Kafka 读取数据的消费者的隔离级别（可读取 ==》不可读取）

这里所说的 Kafka，是写入的外部系统。预提交阶段数据已经写入，只是被标记为“未提交”（uncommitted），而 Kafka 中默认的隔离级别 isolation.level 是 read_uncommitted，也就是可以读取未提交的数据。这样一来，外部应用就可以直接消费未提交的数据，对于事务性的保证就失效了。所以应该将隔离级别配置为 read_committed，表示消费者遇到未提交的消息时，会停止从分区中消费数据，直到消息被标记为已提交才会再次恢复消费。当然，这样做的话，外部应用消费数据就会有显著的延迟。

（4）事务超时配置 Flink 的 Kafka连接器中配置的事务超时时间 transaction.timeout.ms 默认是 1小时，而Kafka集群配置的事务最大超时时间 transaction.max.timeout.ms 默认是 15 分钟。所以在检查点保存 时间很长时，有可能出现 Kafka 已经认为事务超时了，丢弃了预提交的数据；而 Sink 任务认 为还可以继续等待。如果接下来检查点保存成功，发生故障后回滚到这个检查点的状态，这部分数据就被真正丢掉了。所以这两个超时时间，前者应该小于等于后者。

（事务超时时间《=kafka集群配置的事务最大超时时间）