大数据学习之Flink、快速搞懂Flink的容错机制！！！

十二点的泡面

已于 2024-01-22 17:29:41 修改

阅读量1.3k

点赞数 27

分类专栏： Flink 大数据文章标签： flink 大数据

于 2024-01-18 21:09:25 首次发布

本文链接：https://blog.csdn.net/2301_78038072/article/details/135683080

版权

大数据同时被 2 个专栏收录

27 篇文章 3 订阅

订阅专栏

Flink

12 篇文章 0 订阅

订阅专栏

本文详细介绍了Flink的容错机制，包括其工作原理、检查点策略、配置参数以及一致性级别，特别强调了Flink如何通过exactly-once语义保证数据处理的准确性。

摘要由CSDN通过智能技术生成

第五章、Flink的容错机制与其他框架的容错机制相比较

1. checkpoint.interval：

2. checkpoint.timeout：

3. checkpoint.max-concurrent-checks：

4. checkpoint.min-pause-between-checkpoints：

5. checkpoint.directory：

6. checkpoint.snapshot-mode：

7. state.backend：

第一章、Flink的容错机制

Ⅰ、Flink的容错机制

1. 概念：

Flink的容错机制是确保数据流应用程序在出现故障时能够恢复一致状态的关键机制。这种机制通过创建分布式数据流和操作符状态的一致快照来实现，这被称为检查点（Checkpoint）。

当系统遇到故障，例如机器故障、网络故障或软件故障时，Flink会回退到最后一个成功的检查点，然后重新启动所有的算子。这样可以确保即使在故障发生后，应用程序的状态也只会反映数据流中的每个记录一次，实现精确一次（exactly-once）的语义。
- 在有状态的流处理中，如果任务继续处理新数据，并不需要“之前的计算结果”，而是需要任务“之前的状态”。因此，Flink选择了将之前某个时间点所有的状态保存下来，这份“存档”就是所谓的“检查点”（checkpoint）。
- 当遇到故障重启的时候，可以从检查点中“读档”，恢复出之前的状态，这样就可以回到当时保存的一刻接着处理数据。检查点是Flink容错机制的核心。
- 这种机制的好处在于，它能够确保在故障发生后，应用程序的状态不会包含任何重复或遗漏的处理结果，从而保证了数据处理的准确性和一致性。这对于需要处理大量数据的应用程序来说非常重要，因为它可以避免因为数据重复处理或遗漏处理而导致的错误结果或数据不一致性。
此外，Flink还提供了异步屏障快照（Asynchronous Barrier Snapshots）技术，这是一种轻量级的快照技术，可以以低成本备份DAG（有向无环图）或DCG（有向有环图）计算作业的状态。这使得计算作业可以频繁进行快照并且不会对性能产生明显影响。

总的来说，Flink的容错机制能够确保在遇到故障时，数据流应用程序的状态最终将恢复到一致状态。这需要将状态存储在可配置的位置（例如主节点或HDFS上），并且在程序失败时，Flink会停止分布式数据流，然后重新启动算子并重置输入流到相应的状态快照位置。

Ⅱ、状态的一致性：

当在分布式系统中引入状态时，自然也引入了一致性问题。

一致性实际上是"正确性级别"的另一种说法，也就是说在成功处理故障并恢复之后得到的结果，与没有发生任何故障时得到的结果相比，前者到底有多正确？

举例来说，假设要对最近一小时登录的用户计数。在系统经历故障之后，计数结果是多少？如果有偏差，是有漏掉的计数还是重复计数

1.一致性级别：

在流处理中，一致性可以分为3个级别:

at-most-once(最多一次):

这其实是没有正确性保障的委婉说法——故障发生之后，计数结果可能丢失。
at-least-once(至少一次):

这表示计数结果可能大于正确值，但绝不会小于正确值。也就是说，计数程序在发生故障后可能多算，但是绝不会少算。
exactly-once(严格一次):

这指的是系统保证在发生故障后得到的计数结果与正确值一致.既不多算也不少算

曾经，at-least-once非常流行。第一代流处理器(如Storm和Samza)刚问世时只保证at-least-once，原因有二:

保证exactly-once的系统实现起来更复杂。这在基础架构层(决定什么代表正确，以及exactly-once的范围是什么)和实现层都很有挑战性
流处理系统的早期用户愿意接受框架的局限性，并在应用层想办法弥补(例如使应用程序具有幂等性，或者用批量计算层再做一遍计算)。

最先保证exactly-once的系统(Storm Trident和Spark Streaming)在性能和表现力这两个方面付出了很大的代价。为了保证exactly-once，这些系统无法单独地对每条记录运用应用逻辑，而是同时处理多条(一批)记录，保证对每一批的处理要么全部成功，要么全部失败。这就导致在得到结果前，必须等待一批记录处理结束。因此，用户经常不得不使用两个流处理框架(一个用来保证exactly-once，另一个用来对每个元素做低延迟处理)，结果使基础设施更加复杂。曾经，用户不得不在保证exactly-once与获得低延迟和效率之间权衡利弊。Flink避免了这种权衡。

Flink的一个重大价值在于，它既保证了exactly-once，又具有低延迟和高吞吐的处理能力。

从根本上说，Flink通过使自身满足所有需求来避免权衡，它是业界的一次意义重大的技术飞跃。

2.端到端的状态一致性

目前我们看到的一致性保证都是由流处理器实现的，也就是说都是在Flink 流处理器内部保证的；而在真实应用中，流处理应用除了流处理器以外还包含了数据源（例如 Kafka）和输出到持久化系统。

端到端的一致性保证，意味着结果的正确性贯穿了整个流处理应用的始终；每一个组件都保证了它自己的一致性，整个端到端的一致性级别取决于所有组件中一致性最弱的组件。

具体划分如下:

source端

需要外部源可重设数据的读取位置.目前我们使用的Kafka Source具有这种特性: 读取数据的时候可以指定offset
flink内部

依赖checkpoint机制
sink端

需要保证从故障恢复时，数据不会重复写入外部系统. 有2种实现形式:
- 幂等（Idempotent）写入
  
  所谓幂等操作，是说一个操作，可以重复执行很多次，但只导致一次结果更改，也就是说，后面再重复执行就不起作用了。
- 事务性（Transactional）写入
  
  需要构建事务来写入外部系统，构建的事务对应着 checkpoint，等到 checkpoint 真正完成的时候，才把所有对应的结果写入 sink 系统中。对于事务性写入，具体又有两种实现方式：预写日志（WAL）和两阶段提交（2PC）