Flink借助Kafka实现端到端精准一次

一、端到端精准一次

先来讲讲状态一致性

状态一致性概念：

一致性其实就是结果的正确性。对于分布式系统而言，强调的是不同节点中相同数据的副本应该总是“一致的”。

而对于 Flink 来说，多个节点并行处理不同的任务，我们要保证计算结果是正确的，就必须不漏掉任何一个数据，而且也不会重复处理同一个数据。流式计算本身就是一个一个来的，所以正常处理的过程中结果肯定是正确的；但在发生故障、需要恢复状态进行回滚时就需要更多的保障机制了。

状态一致性分类：

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

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

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

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

在实际应用中，我们一般会希望至少不要丢掉数据。这种一致性级别就叫作“至少一次”（at-least-once），就是说是所有数据都不会丢，肯定被处理了，不过不能保证只处理一次，有些数据会被重复处理。 在有些场景下，重复处理数据是不影响结果的正确性的，这种操作具有“幂等性”。了保证达到 at-least-once 的状态一致性，我们需要在发生故障时能够重放数据。最常见的做法是，可以用持久化的事件日志系统，把所有的事件写入到持久化存储中。这时只要记录一个偏移量，当任务发生故障重启后，重置偏移量就可以重放检查点之后的数据了。Kafka 就是这种架构的一个典型实现。

• 精确一次（EXACTLY-ONCE）

最严格的一致性保证，就是所谓的“精确一次”（exactly-once，有时也译作“恰好一次”）。

这也是最难实现的状态一致性语义。exactly-once 意味着所有数据不仅不会丢失，而且只被处理一次，不会重复处理。也就是说对于每一个数据，最终体现在状态和输出结果上，只能有一次统计。 exactly-once 可以真正意义上保证结果的绝对正确，在发生故障恢复后，就好像从未发生过故障一样。 很明显，要做的 exactly-once，首先必须能达到 at-least-once 的要求，就是数据不丢。所以同样需要有数据重放机制来保证这一点。另外，还需要有专门的设计保证每个数据只被处理一次。

Flink 中使用的是一种轻量级快照机制——检查点（checkpoint）来保证 exactly-once 语义。

端到端一致性概念：

• 什么叫端到端的一致性？跟状态一致性有什么区别？

  在Flink流处理应用中，总共有四大模块，执行环境,数据源、流处理器和外部存储系统四个部分。
  

  如果做到状态一致性中的至少一次(AT-LEAST-ONCE)程度，主要看数据源能够重放数据。

  做到状态一致性中的精确一次(EXACTLY-ONCE)程度，流处理器、数据源、外部存储都要有保证机制。

  保证了这三大模块的一致性，就叫作“端到端（end-to-end）的状态一致性”。

• 具体的方案是什么？

  • 在流处理器中使用检查点保证精准一致性
  • 在数据源端使用数据偏移量进行“数据重放”保证精准一致性
  • 在输出端，做幂等写入、或者事务写入，防止消息的重复消费

  

(1)数据源端如何保证

选择可以进行“数据重放”的数据源。

先来举例，典型的**不能进行“数据重放”**的数据源

例如socket 文本流， socket 服务器是不负责存储数据的，发送一条数据之后，我们只能消费一次，是“一锤子买卖”。对于这样的数据源，故障后我们即使通过检查点恢复之前的状态，可保存检查点之后到发生故障期间的数据已经不能重发了，这就会导致数据丢失。所以就只能保证 at-most-once 的一致性语义，相当于没有保证。

有没有能够进行“数据重放”的数据源呢？

一个最经典的应用就是 Kafka。在 Flink 的 Source 任务中将数据读取的偏移量保存为状态，这样就可以在故障恢复时从检查点中读取出来，对Kafka中的数据源重置偏移量，重新获取数据。

(2)输出端如何保证

• 幂等写入

所谓“幂等”操作，就是说一个操作可以重复执行很多次，但只导致一次结果更改。

缺点：

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

• 事务写入

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

• 为什么需要事务呢？

因为幂等写入最大的问题就是“覆水难收”，无法收回外部系统的数据，造成“短暂的不一致性”

⭐️所以事务出现的原因就在于，通过严格控制sink输出，有问题的数据先不输出到外部应用，不给外部应用重复消费的机会，而不是幂等写入的重复的数据处理两次

事务实现的两种方式：

• 预写日志

具体步骤：

• sink里使用接口GenericWriteAheadSink
• 先把结果数据作为日志（log）状态保存起来
• 进行检查点保存时，也会将这些结果数据一并做持久化存储
• 在收到检查点完成的通知时，将所有结果一次性写入外部系统。
• 进行二次确认，一旦外部系统写入失败，再将保存的checkPoint删除

优点：

• 实现简单
• 在二次确认的时候外部系统写入失败，还得重新保存检查点。

⭐️缺点：

• 日志写入到外部系统是批处理，不符合流式处理的思想
• 假设日志写入外部系统失败，检查点保存的就得删除

• 两阶段提交2PC（还行）

大概思路：

构建的事务对应着checkpoint，等到checkpoint真正完成的时候，才提交输出的数据。

具体步骤：

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

其实这里就有个疑问，为什么2pc保护的是检查点后面的新数据，而不是检查点之前的数据？

首先明确sink和其他算子任务的区别。就是sink是处理数据的最后一部分，一旦处理barrier时，之前的数据输出了就输出了，无所谓，最后一步已经走完了。

那么在检查点保存的时候，系统故障，保存检查点失败，那么恢复检查点的时候，恢复的是上次成功保存检查点的数据偏移量，如果不对新数据进行保护，可能就会把之前有可能sink过的部分数据重新消费一次，造成重复消费。

⭐️(3)借助Kafka实现端到端一致

1)各个端如何进行修改:

1) Flink 内部

• 启用检查点

2)输入端

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

3)输出端

• 在sink时， FlinkKafkaProducer 的构造函数中传入参数 Semantic.EXACTLY_ONCE，表示精准一次。

4)Kafka

• 配置写入外部系统时消费者的事务隔离级别 为read_committed

  Kafka 中默认的隔离级别 isolation.level 是 read_uncommitted，也就是可以读取未提交的数据。这样一来，flink在计算完结果输出数据后，外部应用就可以直接读取未提交的数据，对于事务性的保证就失效了。所以应该将隔离级别配置 为 read_committed，表示消费者遇到未提交的消息时，会停止从分区中消费数据，直到消息被标记为已提交才会再次恢复消费。当然，这样做的话，外部应用读取flink输出的数据就会有显著的延迟。

• 配置Flink与Kafka配置的事务提交的超时时间

  Flink的Kafka连接器中配置的事务超时时间transaction.timeout.ms默认是1小时

  而Kafka 集群配置的事务最大超时时间 transaction.max.timeout.ms 默认是 15 分钟

  所以最后要配置的事务时间，应该小于Kafka配置的事务最大超时时间

2)示例代码：

pom文件中引入依赖：

<properties>
        <maven.compiler.source>8maven.compiler.source>
        <maven.compiler.target>8maven.compiler.target>
        <flink.version>1.13.0flink.version>
        <java.version>1.8java.version>
        <scala.binary.version>2.12scala.binary.version>
        <slf4j.version>1.7.30slf4j.version>

    properties>
    <dependencies>
        <dependency>
            <groupId>org.apache.flinkgroupId>
            <artifactId>flink-connector-kafka_2.12artifactId>
            <version>${flink.version}version>
        dependency>
        
        <dependency>
            <groupId>org.apache.flinkgroupId>
            <artifactId>flink-connector-baseartifactId>
            <version>${flink.version}version>
        dependency>
        <dependency>
            <groupId>org.apache.kafkagroupId>
            <artifactId>kafka-clientsartifactId>
            <version>2.4.1version>
        dependency>
        
        <dependency>
            <groupId>org.apache.flinkgroupId>
            <artifactId>flink-connector-kafka_2.12artifactId>
            <version>${flink.version}version>
        dependency>

        
        <dependency>
            <groupId>org.apache.flinkgroupId>
            <artifactId>flink-javaartifactId>
            <version>${flink.version}version>
        dependency>
        <dependency>
            <groupId>org.apache.flinkgroupId>
            <artifactId>flink-streaming-java_${scala.binary.version}artifactId>
            <version>${flink.version}version>
        dependency>
        <dependency>
            <groupId>org.apache.flinkgroupId>
            <artifactId>flink-clients_${scala.binary.version}artifactId>
            <version>${flink.version}version>
        dependency>
        
        <dependency>
            <groupId>org.slf4jgroupId>
            <artifactId>slf4j-apiartifactId>
            <version>${slf4j.version}version>
        dependency>
        <dependency>
            <groupId>org.slf4jgroupId>
            <artifactId>slf4j-log4j12artifactId>
            <version>${slf4j.version}version>
        dependency>


    dependencies>

• Flink内部

  • 调用setCheckpointInterval设定多久一次存储检查点
  • 调用setCheckpointingMode设置语义是精准一次

  //1.flink内部保证精准一次：设置检查点
  CheckpointConfig checkpointConfig = env.getCheckpointConfig();
  //10s内保存一次检查点
  checkpointConfig.setCheckpointInterval(10000);
  //保存检查点的超时时间为5秒钟
  checkpointConfig.setCheckpointTimeout(5000);
  //新一轮检查点开始前最少等待上一轮保存15秒才开始
  checkpointConfig.setMinPauseBetweenCheckpoints(15000);
  //设置作业失败后删除检查点(默认)
  checkpointConfig.enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION);
  //设置检查点模式为精准一次(默认)
  checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
  

• 输入端

  • FlinkKafkaConsumer必须调用setCommitOffsetsOnCheckpoints方法

    执行Checkpoint的时候提交offset到Checkpoint，当重启Flink时，Flink作业会告诉kafka我要从哪个offset开始消费，这样我们的数据也就恢复

  Properties props_source = new Properties();
  props_source.setProperty("bootstrap.servers", "node1:9092");
  props_source.setProperty("group.id", "flink");
  props_source.setProperty("auto.offset.reset", "latest");
  //会开启一个后台线程每隔5s检测一下Kafka的分区情况
  props_source.setProperty("flink.partition-discovery.interval-millis", "5000");
  FlinkKafkaConsumer<String> kafkaSource = new FlinkKafkaConsumer<>("flink_kafka", new SimpleStringSchema(), props_source);
  kafkaSource.setStartFromLatest();
  //2.输入端保证：执行Checkpoint的时候提交offset到Checkpoint(Flink用)
  kafkaSource.setCommitOffsetsOnCheckpoints(true);
  DataStreamSource<String> kafkaDS = env.addSource(kafkaSource);
  

• 输出端

  • 设置Flink等待事务的超时时间，

  • 设置语义为精准一次

         Properties props_sink = new Properties();
          props_sink.setProperty("bootstrap.servers", "node1:9092");
          //3.1 设置事务超时时间，也可在kafka配置中设置
          props_sink.setProperty("transaction.timeout.ms", 1000 * 5 + "");
          FlinkKafkaProducer<String> kafkaSink = new FlinkKafkaProducer<>(
                  "flink_kafka2",
                  new KeyedSerializationSchemaWrapper<String>(new SimpleStringSchema()),
                  props_sink,
                  //3.2 设置输出的的语义为精准一次
                  FlinkKafkaProducer.Semantic.EXACTLY_ONCE
          );
          result.addSink(kafkaSink);
  

• 完整代码

  package com.ming.test1;
  import org.apache.commons.lang3.SystemUtils;
  import org.apache.flink.api.common.functions.FlatMapFunction;
  import org.apache.flink.api.common.functions.RichMapFunction;
  import org.apache.flink.api.common.serialization.SimpleStringSchema;
  import org.apache.flink.api.java.tuple.Tuple;
  import org.apache.flink.api.java.tuple.Tuple2;
  import org.apache.flink.runtime.state.filesystem.FsStateBackend;
  import org.apache.flink.streaming.api.CheckpointingMode;
  import org.apache.flink.streaming.api.datastream.DataStreamSource;
  import org.apache.flink.streaming.api.datastream.KeyedStream;
  import org.apache.flink.streaming.api.datastream.SingleOutputStreamOperator;
  import org.apache.flink.streaming.api.environment.CheckpointConfig;
  import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
  import org.apache.flink.streaming.connectors.kafka.FlinkKafkaConsumer;
  import org.apache.flink.streaming.connectors.kafka.FlinkKafkaProducer;
  import org.apache.flink.streaming.connectors.kafka.internals.KeyedSerializationSchemaWrapper;
  import org.apache.flink.util.Collector;
  
  import java.util.Properties;
  import java.util.Random;
  
  public class test {
      public static void main(String[] args) throws Exception {
          StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
  
          //1.flink内部保证精准一次：设置检查点
          CheckpointConfig checkpointConfig = env.getCheckpointConfig();
          //10s内保存一次检查点
          checkpointConfig.setCheckpointInterval(10000);
          //保存检查点的超时时间为5秒钟
          checkpointConfig.setCheckpointTimeout(5000);
          //新一轮检查点开始前最少等待上一轮保存15秒才开始
          checkpointConfig.setMinPauseBetweenCheckpoints(15000);
          //设置作业失败后删除检查点(默认)
          checkpointConfig.enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION);
          //设置检查点模式为精准一次(默认)
          checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
  
              env.setStateBackend(new FsStateBackend("file:///Users/xingxuanming/Downloads/flink-checkpoint/checkpoint"));
  
          Properties props_source = new Properties();
          props_source.setProperty("bootstrap.servers", "node1:9092");
          props_source.setProperty("group.id", "flink");
          props_source.setProperty("auto.offset.reset", "latest");
          //会开启一个后台线程每隔5s检测一下Kafka的分区情况
          props_source.setProperty("flink.partition-discovery.interval-millis", "5000");
          FlinkKafkaConsumer<String> kafkaSource = new FlinkKafkaConsumer<>("flink_kafka", new SimpleStringSchema(), props_source);
          kafkaSource.setStartFromLatest();
          //2.输入端保证：执行Checkpoint的时候提交offset到Checkpoint(Flink用)
          kafkaSource.setCommitOffsetsOnCheckpoints(true);
          DataStreamSource<String> kafkaDS = env.addSource(kafkaSource);
  
          SingleOutputStreamOperator<Tuple2<String, Integer>> wordAndOneDS = kafkaDS.flatMap(new FlatMapFunction<String, Tuple2<String, Integer>>() {
              @Override
              public void flatMap(String value, Collector<Tuple2<String, Integer>> out) throws Exception {
                  //value就是每一行
                  String[] words = value.split(" ");
                  for (String word : words) {
                      Random random = new Random();
                      int i = random.nextInt(5);
                      if (i > 3) {
                          System.out.println("出bug了...");
                          throw new RuntimeException("出bug了...");
                      }
                      out.collect(Tuple2.of(word, 1));
                  }
              }
          });
          KeyedStream<Tuple2<String, Integer>, Tuple> groupedDS = wordAndOneDS.keyBy(0);
          SingleOutputStreamOperator<Tuple2<String, Integer>> aggResult = groupedDS.sum(1);
          SingleOutputStreamOperator<String> result = (SingleOutputStreamOperator<String>) aggResult.map(new RichMapFunction<Tuple2<String, Integer>, String>() {
              @Override
              public String map(Tuple2<String, Integer> value) throws Exception {
                  return value.f0 + ":::" + value.f1;
              }
          });
  
          //3.输出端保证
          Properties props_sink = new Properties();
          props_sink.setProperty("bootstrap.servers", "node1:9092");
          //3.1 设置事务超时时间，也可在kafka配置中设置
          props_sink.setProperty("transaction.timeout.ms", 1000 * 5 + "");
          FlinkKafkaProducer<String> kafkaSink = new FlinkKafkaProducer<>(
                  "flink_kafka2",
                  new KeyedSerializationSchemaWrapper<String>(new SimpleStringSchema()),
                  props_sink,
                  //3.2 设置输出的的语义为精准一次
                  FlinkKafkaProducer.Semantic.EXACTLY_ONCE
          );
          result.addSink(kafkaSink);
  
          env.execute();
         }
  
  

  进行测试：

  先确认下，这里不用关闭应用程序，再重启应用程序来模拟故障，而是程序里模拟故障，用随机数直接throw Exeception

  进入到kafka的bin目录下

  • 启动zookeeper

    ./zookeeper-server-start.sh …/config/zookeeper.properties &

  • 启动kafka

    ./kafka-server-start.sh …/config/server.properties &

  • 创建主题

    kafka-topics.sh --bootstrap-server localhost:2181 --create --replication-factor 2 --partitions 3 --topic flink_kafka2

  • 打开控制台生产者

    kafka-console-producer.sh --broker-list localhost:9092 --topic flink_kafka

  • 打开控制台消费者

    kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic flink_kafka2

  来看最后的效果：

  此代码主要功能是对输入的字符串做分区和求和操作，例如，传入hello，world，hello三条数据，按照字符串进行分区，分为hello，world两个分区，求和是按照分区内所有汇总的字段进行求和，最后结果是(hello,2) (world,1)

我们假设，来了三条数据，hello，world，hello，处理了两条数据，此时算子状态为(hello,1) (world,1) 第三条数据来的时候“恰好”故障，检查点保存的偏移量是第一条数据hello，算子里保存的是(hello,1) 那么继续从第二条数据world开始消费，第二条数据处理成功，此时算子里保存的(hello,1) (world,1)，第三条数据处理成功，最终效果为(hello,2) (world,1)
3)最后补充下完整的流程：

（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 状态一致性。

二、前置知识

⭐️1.检查点(快照)

(1)概念：

其实就是所有任务的状态在某个时间点的一个快照（一份拷贝）。Flink 会定期保存检查点，在检查点中会记录每个算子的 id 和状态；如果发生故障，Flink 就会用最近一次成功保存的检查点来恢复应用的状态，重新启动处理流程，就如同“读档”一样。

⭐️默认情况下，检查点是被禁用的，需要在代码中手动开启。

(2)拓展问题：

1.什么时候进行保存？

当每隔一段时间检查点保存操作被触发时，就把每个任务当前的状态复制一份，按照一定的逻辑结构放在一起持久化保存起来，就构成了检查点。 在 Flink 中，检查点的保存是周期性触发的，间隔时间可以进行设置。

2.如何保存以及恢复的？

举个例子，看看完整的流程图：

首先，我们已经确认(hello,hello,world)三条数据在所有算子任务都处理完了，那么每个算子任务会把当前处理过程中的值保存到外部存储中，注意是每个算子任务。

由于全部处理完了3条数据，所以source保存的偏移量事3

第一个分区，处理了两条hello数据，所以保存的数据就是hello，2

第二个分区处理了一条world数据，所以保存的数据就是world，1

此时发生故障，系统宕机

重启应用后，所有算子的状态都是空的，第一件事就是读取检查点，也就是刚才检查点保存的值再读取到内存中

第二件事，通过数据源的偏移量，进行重放数据，因为处理完3条数据了，所以从第三条数据后面开始继续处理。

3.为什么检查点保存时机选择所有算子任务处理完同一批数据？

首先需要思考的一个问题：在算子A保存检查点的过程中，算子B正在处理新的数据，出现宕机，那我恢复的时候虽然明确知道哪条数据没有处理完，但是不确定执行到哪一个算子了，所以只能从头source放入数据，然后到算子A执行，但是算子A可能算出来这条数据的中间状态进行保存了， 相当于算子A要对这条数据处理两次。

举例：比如数据a，要进行处理1（求和），处理2（输出到存储文件）阶段，发生故障的时候在处理2阶段，处理1阶段已经保存了处理1阶段的值，难道恢复的时候，处理1阶段还要对数据的a再操作一次吗？

那我不选择处理完同一批数据，有没有什么其他解决方案？有，比较粗暴的方案。

粗暴的解决方案：

最简单的想法是，可以在某个时刻“按下暂停键”，让所有任务停止处理数据。无论是检查点前的还是检查点后面的，都不许处理保存检查点时来的新的数据，就算宕机故障，恢复后开始处理，大家的状态都还是准确的。

然而仔细思考就会发现这有很多问题。这种想法其实是粗暴地“停止一切来拍照”，在保存检查点的过程中，任务完全中断了，这会造成很大的延迟；我们之前为了实时性做出的所有设计就毁在了做快照上。

4.那怎么确认所有算子都处理完同一批数据？直接按照最后一个sink算子任务输出成功的数据作为偏移量不可以吗？

完全不可以，最后一个sink算子任务输出的时候，虽然保证之前的数据已经全部处理完了。但是有个问题是，你在输出的时候，上一个算子任务开始处理新的数据了，整个过程大家都是异步的，你sink的时候还能不让其他算子继续处理新数据了吗，所以真正要用到的偏移量。一定是“特殊标记”的上一条数据。

那特殊标记在Flink中有概念吗？

有，看下面的检查点算法实现。

5.保存检查点的时候，新来的数据到底该怎么办？

先缓存起来，不着急处理，等到检查点保存后再继续处理。

我们可以在source数据中插入一条分界线，一旦所有算子遇到这个分界线就先把分界线之前的数据都处理完，马上开始各自保存当前的快照，保存完往下个算子传递，相当于增加一个约束，“特殊标记前面的一定是都处理完的数据”）。

6.那么你既然要缓存不处理，不还是粗暴的方案？不让新数据处理执行，有什么意义吗？

有，记住，是每个算子任务都保留“自己”的快照，算子A保留快照的时候，不影响算子B处理数据，同样的，算子A已经保留完快照，算子B保留快照的时候，算子A可以允许处理新的数据。
相当于避免了粗暴方案中的“stop the world”

7.那如果任务某个算子任务是并发情况呢？你怎么传递这个特殊标记？

还是要看检查点算法，下游任务必须接收所有上游并发任务的标记过来，才能开始保存快照。

8.既然选择所有任务都处理完一个相同数据，如果有其中一个任务没保存下状态，其他任务都保存了怎么办？

构建一个“事务”，只要有一个任务没保存状态，所有任务保存的状态直接删除，重新发送分界线，重新开始保存

(3)检查点算法：

为什么需要检查点算法？

刚才看到了检查点的保存，是所有算子任务都接受到了“保存快照”的标记，那么，谁来发起保存检查点，谁来通知所有算子任务进行保存呢？
带着这个疑问，先来说说，这个“保存快照的标记”是什么？

1）检查点分界线（Barrier）

与水位线很类似，检查点分界线也是一条特殊的数据，由 Source 算子注入到常规的数据流中，它的位置是限定好的，不能超过其他数据，也不能被后面的数据超过。检查点分界线中带有一个检查点 ID，这是当前要保存的检查点的唯一标识。

这样，分界线就将一条流逻辑上分成了两部分：分界线之前到来的旧数据，都数据当前检查点应该保存的，而基于分界线之后的新数据，因为不确定有没有处理，则会被包含在之后的检查点中。

⭐️这个分界线如何进行传递？

• JobManager中的检查点协调器 定期向 TaskManager 发出指令，要求保存检查点
• TaskManager 会让所有的 Source 任务把自己的偏移量（算子状态）保存起来，并将带有检查点 ID 的分界线（barrier）插入到当前的数据流中，先等待Source任务把快照保存后，并向下游子任务传递barrier。之后 Source 任务就可以继续读入新的数据了。
• 每个算子任务只要处理到这个 barrier，就把当前的状态进行快照。

2）分布式快照算法

我们已经知道了这个特殊字段叫做分界线，那么通知下游的算子任务？此时需要分布式快照算法

⭐️⭐️算法的核心三个原则：

• 当上游任务向多个并行下游任务发送 barrier 时，需要广播出去
• 而当多个上游任务向同一个下游任务传递 barrier 时，需要在下游任务执行“分界线对齐”（barrier alignment）操作，说白了需要等到所有上游任务发送给自己的 barrier 都到齐，才开始“快照”的保存。
• ⭐️在barrier到来后，保存快照期间 新来的数据会进行缓存，不会处理也不会保存到检查点， 直到保存完快照才进行继续进行处理。

• 当多个上游任务向同一个下游任务传递 barrier什么意思？

  如上图所示，假设 sum1获取到map1，map2的barrier，就开始快照保存，sum2只获取map1的barrier，必须等待map2发送过来barrier才能开始快照保存

• ⭐️那等待所有上游任务发送给自己的 barrier的过程中，有新的数据进来怎么办？

  也会保存到检查点中,直到收到全部的barrier到来后，才不会放到检查点中。

(4)使用：

1）启用检查点：

• enableCheckpointing 传入一个保存检查点的间隔

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

2）配置检查点存储位置：

• setCheckpointStorage

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

env.getCheckpointConfig().setCheckpointStorage("hdfs://namenode:40010/flink/checkpoints"); 

⭐️3）其他参数：

• 检查点模式 setCheckpointingMode

  EXACTLY_ONCE 精准一次（默认）
  AT_LEAST_ONCE 最少一次

  对于大多数低延迟的流处理程序，at-least-once 就够用了，而且处理效率会更高。

• 检查点保存的超时时间 setCheckpointTimeout

  注意enableCheckpointing是多久触发一次检查点保存，setCheckpointTimeout是允许多长时间内保存完毕。

• 新一轮检查点保存开始，等待上一个检查点的时间 setMinPauseBetweenCheckpoint

  ⭐️如果设置的检查点保存超时时间小于保存检查点的时间间隔，这个设置就是生效的。

  这个跟enableCheckpointing的区别在于enableCheckpointing是多久触发一次检查点保存，setMinPauseBetweenCheckpoint是上一个检查点已经开始了，但是迟迟不久保存下来，第二个检查点必须等多长时间才能开始保存检查点。

• 作业失败时是否删除检查点 enableExternalizedCheckpoints

  RETAIN_ON_CANCELLATION 保留（默认）

  DELETE_ON_CANCELLATION 直接删除

• 检查点保存失败时停掉作业 setFailOnCheckpointingErrors

  true 停掉作业（默认）

  false 不停掉作业

• enableUnalignedCheckpoints

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

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
//获取检查点
CheckpointConfig checkpointConfig = env.getCheckpointConfig();

//设置检查点的保存，用hdfs
checkpointConfig.setCheckpointStorage("hdfs://my/checkpoint/dir");

//EXACTLY_ONCE表示精准一次  AT_LEAST_ONCE表示最少一次
checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);

//检查点保存的超时时间，超过10秒直接报失败
checkpointConfig.setCheckpointTimeout(10000L);

//检查点的保存时间间隔，20秒后开始下一轮的检查点保存
checkpointConfig.setMinPauseBetweenCheckpoints(20000L);

//最多并发几个运行的检查点
checkpointConfig.setMaxConcurrentCheckpoints(2);

//启用不对齐的检查方式
checkpointConfig.enableUnalignedCheckpoints(); 

//开启检查点的外部持久化，而且[默认]在作业失败的时候不会自动清理
checkpointConfig.enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);

⭐️(5)保存点

概念：

• 什么是保存点？

  也是一个存盘的备份，它的原理和算法与检查点完全相同，只是多了一些额外的元数据。

• 跟检查点的区别在哪里？

  检查点是由 Flink 自动管理的，定期创建，发生故障之后自动读取进行恢复，这是一个“自动存盘”的功能

  而保存点不会自动创建，必须由用户明确地手动触发保存操作，所以就是“手动存盘”。

适用场景：

• 版本管理和归档存储

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

• 更新应用程序

  我们不仅可以在应用程序不变的时候，更新 Flink 版本；还可以直接更新应用程序。前提是程序必须是兼容的，也就是说更改之后的程序，状态的拓扑结构、数据类型是不变的，这才能正常从之前的保存点去加载。

• 调整并行度

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

使用：

• 代码中设置uid

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

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

• 保存

  • savepoint 表示要开始执行保存点

  • jobId (必填) 就是当前作业id名称

  • **targetDirectory（选填）**表示持久化的目录

    不填则使用conf下的state.savepoints.dir 目录

  bin/flink savepoint :jobId [:targetDirectory] 
  

• 恢复

  • 这里只要增加一个-s 参数，指定保存点的路径就可以了

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

2.持久化保存状态

(1)概念

状态的存储、访问以及维护，都是由一个可插拔的组件决定的，这个组件就叫作状态后端（state backend）。状态后端主要负责两件事：一是本地的状态管理，二是将检查点（checkpoint）写入远程的持久化存储。

(2)流程

• 在应用进行检查点保存时，状态后端会在 JobManager 向所有 TaskManager 发出触发检查点的命令。
• TaskManger 收到之后，将当前任务的所有状态进行快照保存，持久化到远程的存储介质中。
• 完成之后向 JobManager 返回确认信息。
• 当 JobManger 收到所有 TaskManager 的返回信息后，就会确认当前检查点成功保存。

而这一切工作的协调，就是“状态后端” 来完成的

(3)分类

• ⭐️默认⭐️ 哈希表状态后端（HashMapStateBackend）

  将本地状态全部放入内存，保存在 Taskmanager 的 JVM 堆（heap）上，所以底层是一个哈希表（HashMap），这种状态后端也因此得名。

  优点：

  • 读写速度非常快

  缺点：

  • 占用taskManager运行内存。

  配置：

  文件配置：

  # 默认状态后端 
  state.backend: hashmap 
  # 存放检查点的文件路径 
  state.checkpoints.dir: hdfs://namenode:40010/flink/checkpoints 
  

  代码配置：

  • 直接设置StateBackend为HashMapStateBackend

  StreamExecutionEnvironment 	env =StreamExecutionEnvironment.getExecutionEnvironment();
  env.setStateBackend(new HashMapStateBackend());
  
  

• 内嵌 RocksDB 状态后端（EmbeddedRocksDBStateBackend）

  会将处理中的数据全部放入 RocksDB 数据库中，RocksDB 默认存储在 TaskManager 的本地数据目录里。

  优点：

  • 不会占用taskManager运行内存
  • 可以根据需要对磁盘空间进行扩展，适合海量状态的存储。

  缺点：

  • 状态的访问性能要差一些（数据被存储为序列化的字节数组（Byte Arrays），读写操作需要序列化/反序列化）

  配置：

  文件配置：

  # 默认状态后端 
  state.backend: rocksdb 
  # 存放检查点的文件路径 
  state.checkpoints.dir: hdfs://namenode:40010/flink/checkpoints 
  

  代码配置：

  • 直接设置StateBackend为EmbeddedRocksDBStateBackend

  StreamExecutionEnvironment 	env =StreamExecutionEnvironment.getExecutionEnvironment(); 
  env.setStateBackend(new EmbeddedRocksDBStateBackend());