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

第二章、Flink核心组件和工作原理

第三章、Flink的恢复策略

第四章、Flink容错机制的注意事项

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

第一章、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，原因有二:

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

最先保证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）

需要构建事务来写入外部系统，构建的事务对应着 checkpoint，等到 checkpoint 真正完成的时候，才把所有对应的结果写入 sink 系统中。对于事务性写入，具体又有两种实现方式：

预写日志（WAL）和两阶段提交（2PC）

Ⅲ、Flink容错机制的配置参数

Flink容错机制的配置参数，如Checkpoint和Savepoint的触发频率、超时时间、检查点间隔等。这些参数会影响到容错机制的性能和恢复时间。

1. checkpoint.interval

：

设置Checkpoint的触发间隔，单位是毫秒。默认情况下，Checkpoint是每1000毫秒（1秒）触发一次。

2. checkpoint.timeout

：

设置Checkpoint的超时时间，单位是毫秒。如果在超时时间内，Checkpoint还没有完成，则会被取消。默认情况下，超时时间是10秒。

3. checkpoint.max-concurrent-checks

：

设置同时进行的最大Checkpoint数量（最大并发检查）。默认情况下，只有1个Checkpoint在执行。

4. checkpoint.min-pause-between-checkpoints

：

设置两个Checkpoint之间的最小暂停时间，单位是毫秒。这个参数可以避免在Checkpoint频繁触发时对性能的影响。默认情况下，最小暂停时间是0毫秒。

5. checkpoint.directory

：

设置Checkpoint的持久化存储目录。需要确保目录的可用性和可写权限。

6. checkpoint.snapshot-mode

：

设置Snapshot的模式，可以选择EXACTLY_ONCE或AT_LEAST_ONCE。EXACTLY_ONCE表示每个数据记录只会被处理一次，AT_LEAST_ONCE表示每个数据记录可能会被处理多次，但最终结果是一致的。

7. state.backend

：

设置状态的后端存储类型，可以选择

MemoryStateBackend

、

FsStateBackend

等。不同的后端存储类型有不同的特点和适用场景。

8. state.ttl

：

设置状态的存活时间，单位是毫秒。如果状态在存活时间内没有被访问，则会被清除。默认情况下，状态的存活时间是0毫秒，表示状态永不过期。