Flink容错机制、搞懂一致性和各种机制和策略！懂得核心组件的工作原理！！！

当系统遇到故障，例如机器故障、网络故障或软件故障时，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）

需要构建事务来写入外部系统，构建的事务对应着 checkpoint，等到 checkpoint 真正完成的时候，才把所有对应的结果写入 sink 系统中。对于事务性写入，具体又有两种实现方式：预写日志（WAL）和两阶段提交（2PC）

Ⅲ、核心组件

Flink的容错机制的核心组件包括Checkpoint和Savepoint。等等.. .. ..

1. `Checkpoint`组件：

一致性检查点

Checkpoint是用于容错和恢复的机制
Checkpoint 是 Flink实现容错机制最核心的功能组件，也是Flink四大基石之一，它在数据流处理过程中定期捕获作业状态的快照，并将其存储在可靠的存储系统中。
当作业发生故障时，Flink 可以从最近的 Checkpoint 恢复，重新处理数据流，以保证数据的完整性和一致性。Checkpoint 的频率和大小可以通过配置参数进行设置。

2. `Savepoint`组件：

?保存点

Savepoint则是用备份机制，于手动恢复的点。
Savepoint是Flink提供的一种备份机制，用于将作业的状态保存到一个指定的位置。
与 Checkpoint 不同，Savepoint 不是为了容错而设计的，而是为了在升级作业或修改作业时能够恢复到之前的状态。通过创建一个 Savepoint，用户可以确保在升级或修改作业后能够回滚到之前的状态，而不会丢失数据或影响数据处理的正确性。

3. `Barrier`组件

?分界线

在检查点过程中，Flink使用分界线来确保到达某个检查点之前的所有数据变更都被包含在该检查点中。
分界线是一种特殊的?数据形式?，它沿着数据流向下传递，当所有相关的任务都收到了分界线，那么就可以认为该检查点完成了。

4. `State Backend`组件

状态后端

状态后端是负责存储和管理任务状态的组件。
Flink支持多种状态后端实现，包括内存状态后端（MemoryStateBackend）?、?文件系统状态后端（FsStateBackend）?和?RocksDB状态后端（RocksDBStateBackend）等。
状态后端负责将任务的状态保存到检查点，并在故障发生时从检查点恢复数据状态。

5. `Recovery Strategy`组件

恢复策略

恢复策略定义了在发生故障时，如何从检查点恢复数据状态。
Flink提供了多种恢复策略，包括固定延时重启策略、失败率重启策略等，
用户可以根据应用的需求进行定制。

6.`?Failover Strategy`组件

故障恢复策略

故障恢复策略是Flink容错机制的一部分，它规定了在单个任务失败时，应如何恢复。Flink支持多种故障恢复策略，如RestartAll、RestartIndividualStrategy和RestartPipelinedRegionStrategy等，这些策略决定了在任务失败时应重启哪些任务。

7.?`Job Restart Strategy`组件

作业重启策略

作业重启策略是Flink容错机制的另一个重要组成部分，它规定了在作业级别发生故障时应如何恢复。Flink提供了多种作业重启策略，如FixedDelayRestartStrategy、FailureRateRestartStrategy和NoRestartStrategy等，这些策略决定了在作业失败时应如何重启作业。

Ⅳ、核心组件的工作原理

1. `Checkpoint`工作原理：

Checkpoint 是 Flink 实现容错机制最核心的功能。

它能够根据配置周期性地基于Stream中各个Operator 的状态来生成快照，这些状态数据会被定期持久化存储下来。当Flink程序一旦意外崩溃时，可以从这些快照进行恢复，修正因为故障带来的程序数据状态中断。在Checkpoint过程中，会在多个分布式Stream Source中插入一个Barrier标记，这些Barrier会根据Stream中的数据记录一起流向下游的各个Operator。当一个Operator接收到一个Barrier时，它会暂停处理Stream中新接收到的数据记录。当所有Stream中的Barrier都已经到达该Operator，这时所有的Barrier在时间上看来是同一个时刻点（表示已经对齐），在等待所有Barrier到达的过程中，Operator的Buffer中可能已经缓存了一些比Barrier早到达Operator的数据记录（Outgoing Records），这时该Operator会将数据记录（Outgoing Records）发射（Emit）出去，作为下游Operator的输入，最后将Barrier对应快照发射（Emit）出去作为此次Checkpoint的结果数据。

周期性触发：Checkpoint 是定期触发的，通常每隔一定数量的数据记录或一定时间间隔触发一次。这个频率可以根据需要进行配置，但一般来说，太频繁的 Checkpoint 会增加资源消耗，而太稀少的 Checkpoint 则可能无法满足容错的需求。
数据同步：在 Checkpoint 触发时，Flink 会暂停数据流的处理，并将已经处理的数据记录写入到持久化存储中。这个过程需要确保数据记录的一致性，避免出现数据丢失或重复的情况。
状态持久化：除了数据记录之外，Checkpoint 还会将各个 Operator 的状态信息也写入到持久化存储中。这些状态信息包括 Operator 的内部状态、缓冲区中的数据等。通过将状态信息持久化，Flink 可以在故障发生时，利用最新的 Checkpoint 进行恢复，保证数据的完整性和一致性。
数据校验：为了确保 Checkpoint 的正确性和完整性，Flink 还会对写入持久化存储的数据记录和状态信息进行校验。校验通常使用一些哈希算法或其他校验机制进行数据完整性的验证。
恢复机制：当 Flink 作业发生故障时，Flink 会根据配置的恢复策略，从最新的Checkpoint中读取数据记录和状态信息，并将作业恢复到 Checkpoint 时的状态。这个过程可以确保数据的完整性和一致性，避免因故障导致的数据丢失或不一致。

补充：

在 Apache Flink 中，Operator 是数据流处理的基本单元，负责处理一部分数据流。

每个 Operator 根据其功能和需求，会对输入的数据进行相应的转换和处理。

Operator的作用:

数据转换：将一个或多个数据流转换成新的数据流。这个过程中，Operator 会对输入的数据进行各种计算和转换，以满足后续处理的需求。

数据处理：根据具体需求，Operator 可以进行各种数据处理操作，例如过滤、聚合、连接等。这些操作可以帮助用户实现更复杂的数据处理逻辑。

数据分发：Operator 负责将处理后的数据发送到下游的 Operator 或存储系统。在这个过程中，Operator 会根据配置的策略，将数据发送到不同的目标，实现数据的分布式处理和存储。

2. `Savepoint`工作原理：

Savepoint 是用户触发的一种机制，它创建了程序全局状态的一个镜像。与Checkpoint不同，Savepoint不是为了容错而设计的，而是为了在升级作业或修改作业时能够恢复到之前的状态。通过创建一个 Savepoint，用户可以确保在升级或修改作业后能够回滚到之前的状态，而不会丢失数据或影响数据处理的正确性。当触发 Savepoint 时，Flink 会将作业的状态保存到一个指定的位置，这个状态包含了作业的所有状态信息，包括各个 Operator 的状态。用户可以使用 Savepoint 来恢复作业到之前的状态，重新处理数据流。

触发 Savepoint：用户通过触发Savepoint，通知Flink 将当前作业的状态保存到指定的位置。这个操作是手动的，需要用户显式地触发。
保存状态：Flink 会将当前作业的状态信息保存到指定的存储系统中。这些状态信息包括各个 Operator 的状态、缓冲区中的数据等。
生成快照：在Savepoint 触发时，Flink 会生成一个快照，这个快照包含了当前作业的状态信息。这个快照可以被视为一个一致性的状态，表示在 Savepoint 触发时的作业状态。
恢复状态：当需要从 Savepoint 恢复作业时，Flink 会从快照中读取状态信息，并将作业恢复到 Savepoint 触发时的状态。这样就可以保证在升级或修改作业后，能够回滚到之前的状态，而不会丢失数据或影响数据处理的正确性。

Ⅴ、配置参数

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毫秒，表示状态永不过期。

Ⅵ、恢复策略

了解如何从故障中恢复数据流。根据Checkpoint和Savepoint的状态，可以选择从最近的一个Checkpoint或Savepoint恢复数据流。

1. Checkpoint：

Checkpoint是Flink容错机制的核心，它定期将作业的状态信息持久化存储起来。当故障发生时，Flink可以从最新的Checkpoint中恢复作业的状态，继续处理数据流。Checkpoint的恢复机制可以确保数据的完整性和一致性。

2. Savepoint：

Savepoint是Flink提供的一种备份机制，用于将作业的状态保存到一个指定的位置。与Checkpoint不同，Savepoint不是为了容错而设计的，而是为了在升级作业或修改作业时能够恢复到之前的状态。通过从Savepoint中恢复状态，用户可以避免重新启动整个作业，从而提高升级和修改作业的效率。

3. 重启策略：

Flink提供了多种重启策略，用于在故障发生时自动或手动重启作业。这些策略可以根据需要进行配置，例如固定延迟重启、失败率重启等。通过配置适当的重启策略，用户可以在故障发生时快速恢复作业，减少数据丢失和停机时间。

4. 状态后端：

Flink的状态后端用于存储作业的状态信息。选择适当的状态后端可以帮助用户在故障发生时快速恢复状态，同时也可以根据需要选择不同的存储介质和存储方式。

Ⅶ、注意事项

在实际应用中，需要注意一些问题，如避免在Checkpoint期间发生故障、确保Checkpoint和Savepoint的一致性、处理失败的Checkpoint或Savepoint等。

1. Checkpoint的稳定性：

Checkpoint的稳定性对于容错机制至关重要。如果Checkpoint过程中发生故障，可能会导致数据丢失或状态不一致。因此，需要确保Checkpoint过程稳定可靠，并定期进行监控和故障排查。

2. 状态一致性：

Checkpoint和Savepoint应该保持一致性，以确保作业的状态可以被正确恢复。在Flink中，可以通过使用Operator Snapshotting等技术来确保状态的一致性。

3. 失败的Checkpoint或Savepoint处理：

如果Checkpoint或Savepoint失败，需要采取适当的措施进行处理。可以配置重试机制，自动尝试重新触发Checkpoint或Savepoint。如果失败次数超过一定阈值，可以考虑手动介入处理。

4. 资源管理：

Checkpoint和Savepoint操作需要消耗一定的计算和存储资源。因此，需要合理配置和管理这些资源，避免对作业性能产生负面影响。

5. 版本控制：

随着作业的升级和修改，Checkpoint和Savepoint的版本也需要进行相应的更新。需要确保不同版本的状态可以正确恢复，并采取适当的措施处理不同版本之间的状态迁移问题。

6. 监控和日志分析：

需要定期监控Checkpoint和Savepoint的状态和性能指标，并进行日志分析。通过监控和日志分析，可以及时发现潜在的问题，并进行相应的处理。

Ⅷ、与其他框架相比较

了解Flink的容错机制与其他框架（如Apache Kafka、Apache HBase等）的容错机制的异同点，以便更好地选择适合自己应用的容错方案。

相同点：

1. 容错机制的目的：

Flink、Kafka和HBase都提供了容错机制，以确保在故障发生时能够保证数据的完整性和一致性。

2. 持久化存储：

这些框架都使用持久化存储来保存状态信息，以便在故障发生时能够从最新的状态进行恢复。

不同点：

1. 适用场景：

Flink主要用于流处理和批处理，Kafka主要用于消息队列和流处理，而HBase则主要用于列存储和实时数据处理。

2. 容错机制的细节：

虽然Flink、Kafka和HBase都提供了容错机制，但在具体实现细节上有所不同。例如，Flink的Checkpoint和Savepoint机制与Kafka的幂等性写入和HBase的WAL（Write-Ahead Logging）机制在细节上有所不同。

3. 数据一致性：

在处理数据一致性问题时，Flink、Kafka和HBase采用的方法也有所不同。例如，Flink通过精确一次处理语义保证数据的一致性，而Kafka通过消息的顺序和偏移量来保证一致性。

综上所述:

Flink、Kafka和HBase的容错机制在实现目标、持久化存储等方面有一些相似之处，但在适用场景、实现细节和数据一致性等方面存在一些差异。

文章来源:https://blog.csdn.net/2301_78038072/article/details/135683080
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：chenni525@qq.com进行投诉反馈，一经查实，立即删除！