Flink借助Kafka实现端到端精准一次_flink 如何保障数据一致性(1)

最新推荐文章于 2024-06-04 11:42:27 发布

2401_84160361

最新推荐文章于 2024-06-04 11:42:27 发布

阅读量992

点赞数 9

分类专栏： 2024年程序员学习文章标签： flink kafka 大数据

本文链接：https://blog.csdn.net/2401_84160361/article/details/137761305

版权

2024年程序员学习专栏收录该内容

115 篇文章 1 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

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>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
        <flink.version>1.13.0</flink.version>
        <java.version>1.8</java.version>
        <scala.binary.version>2.12</scala.binary.version>
        <slf4j.version>1.7.30</slf4j.version>

    </properties>
    <dependencies>
        <dependency>
            <groupId>org.apache.flink</groupId>
            <artifactId>flink-connector-kafka_2.12</artifactId>
            <version>${flink.version}</version>
        </dependency>
        <!--1.12.0需要在服务器上引入如下两个jar包-->
        <dependency>
            <groupId>org.apache.flink</groupId>
            <artifactId>flink-connector-base</artifactId>
            <version>${flink.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.kafka</groupId>
            <artifactId>kafka-clients</artifactId>
            <version>2.4.1</version>
        </dependency>
        <!--flink通用连接kafka 可以在写代码时不用指定版本 2.12代表scala版本-->
        <dependency>
            <groupId>org.apache.flink</groupId>
            <artifactId>flink-connector-kafka_2.12</artifactId>
            <version>${flink.version}</version>
        </dependency>

        <!-- 引入Flink相关依赖-->
        <dependency>
            <groupId>org.apache.flink</groupId>
            <artifactId>flink-java</artifactId>
            <version>${flink.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.flink</groupId>
            <artifactId>flink-streaming-java_${scala.binary.version}</artifactId>
            <version>${flink.version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.flink</groupId>
            <artifactId>flink-clients_${scala.binary.version}</artifactId>
            <version>${flink.version}</version>
        </dependency>
        <!-- 引入日志管理相关依赖-->
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>${slf4j.version}</version>
        </dependency>
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <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)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TjbpOjHL-1681811696794)(image-20230414195452057.png)] 我们假设，来了三条数据，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”

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

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

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

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

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

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

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）
[外链图片转存中…(img-uc0R66Sm-1713123420215)]

2401_84160361

关注

9
点赞
踩
22

收藏

觉得还不错? 一键收藏
0
评论
Flink借助Kafka实现端到端精准一次_flink 如何保障数据一致性(1)

那么在检查点保存的时候，系统故障，保存检查点失败，那么恢复检查点的时候，恢复的是上次成功保存检查点的数据偏移量，如果不对新数据进行保护，可能就会把之前有可能。
复制链接

扫一扫