Flink的容错机制

检查点

检查点是Flink容错机制的核心。这里所谓的检查，其实是针对故障恢复的结果而言的。在有状态的流处理中，任务继续处理新数据，并不需要之前的计算结果，而是需要任务之前的状态。当故障恢复之后继续处理，应该与发送故障前完全一致，我们需要检查结果的正确性，因此，checkpoint又称一致性检查点

检查点的保存

• 检查点保存：周期性地触发保存
• 保存的时间点：当所有任务都恰好处理完一个相同的输入数据时，将它们的状态保存下来

SingleOutputStreamOperator<Tuple2<String, Long>> wordCountStream =env.addSource(...)
                                                             .map(word -> Tuple2.of(word, 1L))
                                                             .returns(Types.TUPLE(Types.STRING, Types.LONG));
                                                             .keyBy(t -> t.f0);
                                                             .sum(1);

数据源为一个个单词，源任务从外部数据源读取数据，并记录当前的偏移量，作为算子状态保存下来，然后将数据发给下游的Map任务，它会将单词转换成（word,count）二元组，初始count=1L，也就是（“hello”,1）这样的形式，这是一个无状态的算子任务。进而以word作为键进行分区，调用sum()方法对count值进行求和，Sum算子会把当前求和的结果作为按键分区状态保存下来。

当我们需要保存检查点（checkpoint）时，就是在所有任务处理完同一条数据后，对状态做个快照保存下来。把快照写入外部存储中，由状态后端的配置项检查点存储（CheckpointStorage）来决定，有作业管理器的堆内存（JobManagerCheckpointStorage）和文件系统（FileSystemCheckpointStorage）两种选择，一般写入持久化的分布式文件系统

从检查点恢复状态

在运行流处理程序时，Flink会周期性地保存检查点，当发送故障时，就需要找到最近一次成功保存的检查点来恢复状态。我们处理完三个数据后保存了一个检查点，之后继续运行，又正常处理了一个数据flink，在处理第五个数据hello时发送了故障，这里Source任务已经处理完毕，偏移量为5，Map任务已经完成，而Sum任务在处理中发生了故障，此时状态并未保存，接下来需要从检查点来恢复状态

（1）重启应用

遇到故障后，第一步是重启，将所有任务的状态清空

（2）读取检查点，重置状态

找到最近一次保存的检查点，从中读出每个算子任务状态的快照，分别填充到对应的状态中。这里恢复到刚好处理完第三个数据的时候，这里key为flink并没有数据到来，故初始为0

（3）重放数据

从检查点恢复状态后还有一个问题，如果直接继续处理数据，那么保存检查点之后 -> 发生故障这段时间内的数据，也就是第4、5个数据（“flink”、“hello”）相当于丢掉了，这会造成计算结果错误

为了不丢弃数据，应该从保存检查点后开始重新读取数据，通过Source任务向外部数据源重新提交偏移量

（4）继续处理数据

接下来正常处理数据，当处理到第5个数据时，就已经追上了发生故障时的系统状态。我们既没有丢掉数据也没有重复计算数据，保证了计算结果的正确性，在分布式系统中，实现了精确一次（exactly-once）的状态一致性保。另一方面，想要正确地从检查点中读取并恢复状态，必须知道每个算子任务状态的类型和它们的先后顺序（拓扑结构），在改动程序、修复Bug时要保证状态的拓扑顺序和类型不变。状态的拓扑结构在JobManager上可由JobGraph分析得到，而检查点保存的定期触发也是由JobManager控制的，所以故障恢复的过程需要JobManager的参与

检查点算法

Flink保存检查点的时间点，是所有任务都处理完同一个输入数据的时候，但不同的任务处理数据的速度不同，当第一个Source任务处理到某个数据时，后面的Sum任务可能还在处理之前的数据，而且数据经过任务处理之后类型和值都会发生变化，面对着面目全非的数据，不同的任务怎么知道处理的是同一个呢？

一个简单的想法是：当接到JobManage发出的保存检查点的指令后，Source算子任务处理完当前数据就暂停等待，不再读取新的数据。我们就可以保证所有任务刚好处理完最后一个数据，这时把所有状态保存起来，合并之后就是一个检查点了。但先保存完状态的任务需要等待其他任务时，就导致了资源的闲置和性能的降低

更好的做法是，在不暂停整体流处理的前提下，将状态备份保存到检查点，在Flink中采用了基于Chandy-Lamport算法的分布式快照

1、检查点分界线（Barrier）

借鉴水位线的设计，在数据流中插入一个特殊的数据结构，专门用来表示触发检查点保存的时间点，收到保存检查点的指令后，Source任务可以在当前数据流中插入这个结构，之后的所有任务只要遇到它就开始对状态做持久化快照保存。这种特殊的数据形式，把一条流上的数据按照不同的检查点分隔开，叫做检查点的分界线（Checkpoint Barrier）

检查点分界线中带有一个检查点ID，这是当前保存的检查点的唯一标识。在JobManager中有一个检查点协调器（checkpoint coordinator），专门用来协调处理检查点的相关工作，定期向TaskManager发出指令，要求保存检查点；TaskManager会让所有的Source任务把自己的偏移量（算子状态）保存起来，并将带有检查点ID的分界线插入到当前的数据流中，然后像正常的数据一样像下游传递，之后Source任务就可以继续读入新的数据了

每个算子任务只要处理到这个分界线，就把当前的状态进行快照，下游任务做快照时，不会影响上游任务的处理，每个任务的快照保存并行不悖，不会有暂停等待的时间。

2、分布式快照算法

Flink使用了Chandy-Lamport算法的一种变体，被称为异步分界线快照（asynchronous barrier snapshotting）算法。算法的核心思想是两个原则：

• 当上游任务向多个并行下游任务发送barrier时，需要广播出去
• 当多个上游任务向同一个下游任务传递barrier时，需要在下游任务执行分界线对齐（barrier alignment）操作，也就是等所有并行分区的barrier都到齐，才开始状态的保存

为了详细解释检查点算法的原理，以下对wordcount程序进行扩展，考虑所有算子并行度为2的场景

接下来时检查点保存的算法，具体过程如下：

（1）JobManager发送指令，触发检查点的保存；Source任务保存状态，插入分界线

JobManager会周期性地向每个TaskManager发送一条带有新检查点ID的消息，通过这种方式启动检查点，收到指令后，TaskManager会在所有Source任务中插入一个分界线，并将偏移量保存到远程的持久化存储中

（2）状态快照保存完成，分界线向下游传递

状态存入持久化存储之后，会返回通知给Source任务，Source任务就会向JobManager确认检查点完成，然后像数据一样把barrier向下游任务传递，由于Source和Map之间食一对一的传输关系，所以barrier可以直接传递给对应的Map任务，之后Source任务就可以继续读取新的数据了

（3）向下游多个并行子任务广播分界线，执行分界线对齐

Map任务没有状态，故直接将barrier继续向下游传递，这时由于进行了keyBy分区，故需要将barrier广播到下游并行的两个Sum任务。同时，Sum任务可能收到来自上游两个并行Map任务的barrier，所以需要执行分界线对齐操作

（4）分界线对齐后，保存状态到持久化存储

各个分区的分界线都对齐后，就可以对当前状态做快照，保存到持久化存储，存储完成之后，同样将barrier向下游继续传递，并通知JobManager保存完毕。这个过程中，每个任务保存自己的状态都是相对独立的，互不影响

（5）先处理缓存数据，然后正常继续处理

完成检查点保存之后，任务就可以继续正常处理数据了。这时如果有等待分界线对齐时缓存的数据，需要先做处理，然后再按照顺序依次处理新到的数据

当JobManager收到所有任务成功保存状态的信息，就可以确认当前检查点成功保存，之后遇到故障就可以从这里恢复了

由于分界线对齐要求先到达的分区做缓存等待，一定程度上会影响处理的速度，当出现背压（backpressure）时，下游任务回堆积大量的缓冲数据，检查点可能需要很久才可以保存完毕。为了应对这种场景，Flink1.11之后提供了不对齐的检查点保存方式，可以将未处理的缓冲数据（in-flight data）也保存进检查点。这样，当我们遇到一个分区barrier时就不需要等待对齐，而是可以直接启动状态的保存

检查点配置

检查点的作用是为了故障恢复，我们不能因为保存检查点占据了大量时间、导致数据处理性能明显降低，为了兼顾错性和处理性能，可以在代码中对检查点进行各种配置

1、启动检查点

默认情况下，Flink程序是禁用检查点的，为Flink应用开启自动保存快照的功能，需要在代码中显示地调用执行环境enableCheckpointing()方法

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// 每隔 1 秒启动一次检查点保存
env.enableCheckpointing(1000);

传入一个长整型的毫秒数，表示周期性保存检查点间隔时间，不传参默认500毫秒。检查点的间隔时间是对处理性能和故障恢复速度的一个权衡，如果我们希望对性能的影响更小，可以调大间隔时间；而如果希望故障重启后迅速赶上实时地数据处理，就需要将间隔时间设小一些

2、检查点存储

检查点具体的持久化存储位置，取决于检查点存储（CheckpointStorage）的设置，默认设置，存储在JobManager的堆内存中，而对于大状态的持久化保存，Flink提供了在其他存储位置进行保存的接口

具体可以通过调用检查点配置setCheckpointStorage()来配置，需要传入一个CheckpointStorage的实现类。Flink主要提供了两种CheckpointStorage：作业管理器的堆内存（JobManagerCheckpointStorage）和文件系统（FileSystemCheckpointStorage）

// 配置存储检查点到 JobManager 堆内存
env.getCheckpointConfig().setCheckpointStorage(new JobManagerCheckpointStorage());
// 配置存储检查点到文件系统
env.getCheckpointConfig().setCheckpointStorage(new FileSystemCheckpointStorage("hdfs://namenode:40010/flink/checkpoints"));

对于实际生产应用，将CheckpointStorage配置为高可用的分布式文件系统（HDFS，S3等）

3、其他高级配置

检查点还有很多可以配置的选项，可以通过获取检查点配置（CheckpointConfig）来进行设置

CheckpointConfig checkpointConfig = env.getCheckpointConfig();

（1）检查点模式（CheckpointingMode）

设置检查点一致性的保证级别，有精确一次（exactly-once）和至少一次（at-least-once）两个选项。默认级别为exactly-once，而对于大多数低延迟的流处理程序，至少一次就够用了，处理效率会更高

（2）超时时间（checkpointTimeout）

指定检查点保存的超时时间，超时没完成就会被丢弃掉，传入一个长整型毫秒数作为参数。

（3）最小间隔时间（minPauseBetweenCheckpoints）

用于指定在上一个检查点完成之后，检查点协调器（checkpoint coordinator）最快等多久可以保存下一个检查点的指令。这意味着即使已经达到了周期触发的时间点，但只要距离上一个检查点完成的间隔不够，就依然不能开启下一次检查点的保存。这为正常处理数据留下了充足的间隙，当指定这个参数时，maxConcurrentCheckpoints的值强制为1

（4）最大并发检查点数量（maxConcurrentCheckpoints）

用于指定运行中的检查点最多可以由多少个，由于每个任务的处理进度不同，完全可能出现后面的任务还没完成，前一个检查点的保存、前面任务已经开始保存下一个检查点。

若前面设置了minPauseBetweenCheckpoints，则maxConcurrentCheckpoints这个参数就不起作用了

（5）开启外部持久化存储（enableExternalizedCheckpoints）

用于开启检查点的外部持久化，默认在作业失败时不会自动清理，如果想释放空间需要自己手动清理。里面传入的参数ExternalizedCheckpointCleanup指定了当作业取消的时候外边的检查点该如何清理

• DELETE_ON_CANCELLATION：在作业取消的时候会自动删除外部检查点，但是如果是作业失败退出，则会保留检查点
• RETAIN_ON_CANECLLATION：作业取消的时候也会保留外部检查点

（6）检查点异常时是否让整个任务失败（failOnCheckpointingErrors）

用于指定在检查点发生异常的时候，是否应该让任务直接失败退出，默认为true，如果设置为false，则任务回丢弃掉检查点然后继续运行

（7）不对齐检查点（enableUnalignedCheckpoints）

不再执行检查点的分界线对齐操作，启用之后可以大大减少产生背压时的检查点保存时间。这个设置要求检查点模式（CheckpointingMode）必须为exactly-once，并且并发的检查点个数为1

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// 启用检查点，间隔时间 1 秒
env.enableCheckpointing(1000);
CheckpointConfig checkpointConfig = env.getCheckpointConfig();
// 设置精确一次模式
checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
// 最小间隔时间 500 毫秒
checkpointConfig.setMinPauseBetweenCheckpoints(500);
// 超时时间 1 分钟
checkpointConfig.setCheckpointTimeout(60000);
// 同时只能有一个检查点
checkpointConfig.setMaxConcurrentCheckpoints(1);
// 开启检查点的外部持久化保存，作业取消后依然保留
checkpointConfig.enableExternalizedCheckpoints(
 ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
// 启用不对齐的检查点保存方式
checkpointConfig.enableUnalignedCheckpoints();
// 设置检查点存储，可以直接传入一个 String，指定文件系统的路径
checkpointConfig.setCheckpointStorage("hdfs://my/checkpoint/dir")

保存点

除了检查点外，Flink还提供了另一个非常独特的镜像保存功能——保存点（Savepoint）

一个存盘的备份，它的原理和算法与检查点完全相同，只是多了一些额外的元数据，事实上，保存点就是通过检查点的机制来创建流式作业状态的一致性镜像（consistent image）

保存点中的状态快照，是以算子ID和状态名称组织起来的，相当于一个键值对，从保存点启动应用程序时，Flink会将保存点的状态数据重新分配给相应的算子任务

1、保存点的用途

保存点与检查点最大的区别，就是触发的时机，检查点是由Flink自动管理的，定期创建，发生故障之后自动读取进行恢复，这是一个自动存盘的功能；而保存点不会自动创建，必须由用户明确地手动触发保存操作，所以就是手动存盘。因此两者尽管原理一致，但用途就有所差别了：检查点主要用来做故障恢复，就是容错机制的核心；保存点则更加灵活，可以用来做有计划的手动备份和恢复。

保存点可以当做一个强大的运维工具来使用，我们可以在需要的时候创建一个保存点，然后停止应用，做一些处理调整之后再从保存点重启，它适用的具体场景如下：

• 版本管理和归档存储：对重要的节点进行手动备份，设置为某一版本，归档（archive）存储应用程序的状态

• 更新Flink版本：目前Flink的底层架构已经非常稳定，当Flink版本升级时，程序本身一般是兼容的，这时不需要重新执行所有的计算，只要创建一个保存点，停掉应用、升级Flink后，从保存点重启就可以继续处理了

• 更新应用程序：在程序兼容的情况下，状态的拓扑结构和数据类型都是不变的，直接更新应用程序，从之前的保存点加载

  （这个功能非常有用，我们可以及时修复应用程序中的逻辑bug，更新之后接着处理；也可以用于不同业务逻辑的场景，比如A/B测试等）

• 调整并行度：应用运行的过程中，发现需要的资源不足或已经有了大量剩余，也可以通过保存点重启的方式，将应用程序的并行度增大或减少

• 暂停应用程序：有时我们不需要调整集群或更新程序，只是单纯地希望把应用暂停、释放一些资源来处理更重要的应用程序，使用保存点就可以灵活实现应用的暂停和重启，可以对有限的集群资源做最好的优化配置

注意：保存点能够在程序更改的时候依然兼容，前提是状态的拓扑结构和数据类型不变。保存点中状态都是以算子ID-状态名称这样的key-value组织起来的，算子ID可以在代码中直接调用SingleOutputStreamOperator的uid()方法来进行指定：

DataStream<String> stream = env
     .addSource(new StatefulSource())
     .uid("source-id")
     .map(new StatefulMapper())
     .uid("mapper-id")
     .print();

对于没有设置ID的算子，Flink默认会自动进行设置，在重新启动应用后可能会导致ID不同而无法兼容以前的状态，为了方便后续的维护，强烈建议在程序中为每一个算子手动指定ID

2、使用保存点

保存点的使用非常简单，可以使用命令行工具来创建保存点，也可以从保存点来恢复作业

（1）创建保存点

在命令行中为运行的作业创建一个保存点镜像，只需要执行：

bin/flink savepoint :jobId [:targetDirectory]

这里jobId需要填充做镜像保存的作业ID，目标路径taretDirectory可选，表示保存点存储的路径

对于保存点的默认路径，可以通过配置文件flink-conf.yaml中的state.savepoints.dir项来设定：

state.savepoints.dir: hdfs:///flink/savepoints

对于单独的作业，可以在程序代码中通过执行环境来设置：

env.setDefaultSavepointDir("hdfs:///flink/savepoints");

由于创建保存点一般都是希望更改环境之后重启，所以创建之后往往紧接着就是停掉作业的操作。除了运行的作业创建保存点，我们可以在停掉一个作业时直接创建保存点：

bin/flink stop --savepointPath [:targetDirectory] :jobId

（2）从保存点重启应用

我们已经知道，提交启动一个Flink作业，使用的命令是flink run；现在要从保存点重启一个应用，其实本质是一样的：

bin/flink run -s :savepointPath [:runArgs]

状态一致性

一致性的概念和级别

在分布式系统中，一致性是一个非常重要的概念；在事务中，一致性也是重要的一个特性。Flink中的一致概念，主要用在故障恢复的描述中

一致性就是结果的正确性。对于分布式系统而言，强调的是不同节点中相同数据的副本应该总是一致的，从不同节点读取时总能得到相同的值。多个节点并行处理不同的任务，我们要保证计算结果时正确的，必须不漏掉任何一个数据，而且也不会重复处理同一个数据，在发生故障、需要恢复状态进行回滚时就需要更多的保障机制了，通过检查点的保存来保证状态恢复后结果的正确，故主要讨论的是状态一致性

状态一致性的三种级别：最多一次（AT-MOST-ONCE）、至少一次（AT-LEAST-ONCE）、精确一次（EXACTLY-ONCE）

• 最多一次：当任务发生故障时，最简单的做法就是直接重启，别的什么都不干；既不恢复丢失的状态，也不重放丢失的数据。每个数据再正常情况下被处理一次，遇到时就会丢掉，这就是最多一次处理
• 至少一次：在实际应用中，我们一般会希望至少不要丢掉数据，所有数据都不会丢、都能被处理，有些数据可能会被重复处理。这种一致性级别叫做至少一次
• 精确一次：最严格的一致性保证，意味着所有数据不仅不会丢失，而且只被处理一次，不会重复处理

端到端的状态一致性

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

端到端精确一次

对于Flink内部来说，检查点机制可以保证故障恢复后数据不丢，并且只处理一次，已经可以做到exactly-once的一致性语义了

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

输入端保证

Flink读取的外部数据源。对于一些数据源来说，并不提供数据的缓冲或是持久化保存，数据被消费之后就彻底不存在了。对于这样的数据源，故障后我们即使通过检查点恢复之前的状态，可保存检查点之后到发送故障期间的数据已经不能重发了，这就会导致数据丢失，只能保证at-most-once的一致性语义，相当于没有保证。

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

数据可重复 + 检查点 达到at-least-once一致性语义的基本要求

输出端保证

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

为了实现端到端的exactly-once，我们还需要对外部存储系统、以及Sink连接器有额外的要求，有两种方法：幂等写入、事务写入

幂等写入

幂等操作，就是说一个操作可以重复执行很多次，但只导致一次结果更改，也就是说，后面再重复执行就不会对结果起作用了。例如在数学领域，对e^x求导不变；在数据处理领域，对HashMap的插入操作，如果是相同的键值对，重复插入不起作用

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

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

事务写入

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

事务写入的基本思想是：用一个事务来进行数据向外部系统的写入，这个事务是与检查点绑定在一起的，当Sink任务遇到barrier时，开始保存状态的同时就开启了一个事务，接下来所有数据的写入都在这个事务中，待到检查点保存完毕时，将事务提交，所有写入的数据就真正可用了，若中间过程出现故障，状态会回退到上一个检查点，而当前事务没有正常关闭，所以也会回滚，写入到外部的数据就被撤销了

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

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

• 1、先把结果数据作为日志状态保存起来
• 2、进行检查点保存时，也会将这些结果一并做持久化存储
• 3、在收到检查点完成的通知时，将所有结果一次性写入外部系统

在Flink中DataStream API提供了一个模板类GenericWriteAheadSink，用来实现这种事务型的写入方式。

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

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

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

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

• 1、当第一条数据到来时，或者收到检查点的分界线时，Sink任务都会启动一个事务
• 2、接下来收到的所有数据，都会通过这个事务写入外部系统；这时由于事务没有提交，所以数据尽管写入了外边系统，但是不可用，是预提交的状态
• 3、当Sink任务收到JobManager发来检查点完成的通知时，正式提交事务，写入的结果就真正可用了

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

Flink 提供了 TwoPhaseCommitSinkFunction 接口，方便我们自定义实现两阶段提交的 SinkFunction 的实现

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

• 外部系统必须提供事务支持，或者Sink任务必须能够模拟外边系统上的事务
• 在检查点的间隔期间，必须能够开启一个事务并接受数据写入
• 在收到检查点完成的通知之前，事务必须是等待提交的状态，在故障恢复的情况下，这可能需要一些时间。如果这个时候外边系统关闭事务，那么未提交的数据就会丢失
• Sink任务必须能够在进程失败后恢复事务
• 提交事务必须是幂等操作

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

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

在流处理的应用中，最佳的数据源当然是可重置偏移量的消息队列了，它不仅可以提供数据重放的功能，而且天生就是以流的方式存储和处理数据的，所以作为大数据工具中消息队列的代表，Kafka可以说与Flink是天作之后，实际项目中也经常会看到以Kafka作为数据源和写入的外部系统的应用。

1、整体介绍

端到端的exactly-once，我们从三个组件的角度来进行分析：

（1）Flink内部

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

（2）输入端

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

（3）输出端

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

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

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

2、具体步骤

这是一个Flink与Kafka构建的完整数据管道，Source任务从Kafka读取数据，经过一系列处理（比如窗口计算），然后由Sink任务将结果再写入Kafka。

Flink 与 Kafka 连接的两阶段提交，离不开检查点的配合，这个过程需要 JobManager 协调各个 TaskManager 进行状态快照，而检查点具体存储位置则是由状态后端（State Backend）来 配置管理的。一般情况，我们会将检查点存储到分布式文件系统上

（1）启动检查点保存

检查点保存的启动，标志着我们进入了两阶段提交协议的预提交阶段，JobManager 通知各个 TaskManager 启动检查点保存，Source 任务会将检查点分界线（barrier）注入数据流。这个 barrier 可以将数据流中的数据，分为进入当前检查点的集合和进入下一个检查点的集合

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

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

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

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

对于Kakfa而言，提交的数据会被标记为未确认（uncommitted），这个过程就是所谓的预提交

（4）检查点保存完成，提交事务

当所有算子的快照都完成，也就是这次的检查点保存最终完成，JobManager会向所有任务确认通知，告诉大家当前检查点已经成功保存。当Sink任务收到确认通知后，就会正式提交之前的事务，把之前未确认的数据标为已确认，接下来就可以正常消费了。

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

3、需要的配置

• 1、必须启用检查点
• 2、在FlinkKafkaProducer的构造函数中传入参数Semantic.EXACTYL_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 任务认 为还可以继续等待。如果接下来检查点保存成功，发生故障后回滚到这个检查点的状态，这部分数据就被真正丢掉了。所以这两个超时时间，前者应该小于等于后者