容错机制（状态一致性）

佛系爱学习

于 2024-01-29 16:20:49 发布

阅读量1k

点赞数 21

分类专栏： flink知识点文章标签：微服务分布式运维大数据 flink 数据库

本文链接：https://blog.csdn.net/2301_77578187/article/details/135913952

版权

flink知识点专栏收录该内容

25 篇文章 0 订阅

订阅专栏

本文详细解释了Flink流式处理中的状态一致性概念，涉及一致性级别（AT-MOST-ONCE,AT-LEAST-ONCE,EXACTLY-ONCE），一致性快照和异步快照机制，以及如何通过检查点、数据源的幂等性和事务性来实现端到端的状态一致性。

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

容错机制

状态一致性

狗哥：

在Flink流式处理架构中，状态一致性是一个核心概念，它确保了流式应用程序在故障恢复后能够继续从一致的状态开始执行。

首先，我们来理解什么是状态一致性。在流式处理中，状态一致性意味着在故障发生后，Flink能够准确地恢复到故障发生前的一致状态，使得应用程序在恢复后能够继续处理数据，并且不会丢失或重复处理数据。为了实现状态一致性，Flink采用了一致性快照（Consistent Snapshot）机制。

一致性快照机制的工作原理是定期对流式应用程序的状态进行快照（Snapshot）操作，将当前状态保存下来。当故障发生时，Flink会回滚到最近的一致性快照，并从该快照开始重新处理数据。由于快照是一致性的，因此可以确保在故障恢复后不会出现数据丢失或重复处理的情况。

在实际应用中，Flink流式处理架构采用异步快照（Async Snapshotting）机制来提高状态一致性的效率和可用性。异步快照允许在不阻塞数据处理的情况下进行状态快照的创建和保存，从而提高了系统的吞吐量和响应能力。

为了实现异步快照机制，Flink引入了两个重要的组件：Checkpoint Barrier 和 Task State Manager。Checkpoint Barrier 用于在数据流中标识一致性检查点的位置，Task State Manager 负责管理任务状态的快照和恢复操作。

当 Checkpoint Barrier 到达某个任务时，Task State Manager 会触发状态快照的创建和保存操作。同时，Flink还采用了一种增量快照（Incremental Snapshot）机制，只对发生变更的部分进行快照，而不是每次都完整地保存整个状态，从而减少了快照的生成时间和存储开销。

除了快照机制外，Flink还提供了其他应对机制来确保状态一致性。例如，Flink提供了检查点（Checkpoint）和保存点（Savepoint）等机制，允许用户手动触发状态快照的创建和保存操作，以便在故障发生时进行恢复。此外，Flink还提供了容错机制，例如故障恢复和重新平衡等，以确保流式应用程序在故障发生后能够快速恢复到一致的状态并继续执行。

狗哥：

1 一致性的概念和级别

在分布式系统和事务中，一致性是一个核心概念，它涉及到结果的正确性和数据的一致性。在Flink流式处理架构中，一致性的概念主要应用于故障恢复，以确保状态恢复后结果的正确性。

简单来说，一致性就是结果的正确性。在分布式系统中，一致性指的是不同节点中相同数据的副本应该始终保持一致，即从不同节点读取时总能得到相同的值。对于事务而言，一致性是指提交更新操作后能够读取到新的数据。对于Flink而言，由于多个节点并行处理不同的任务，为了确保计算结果的正确性，必须保证不漏掉任何一个数据，并且不会重复处理同一个数据。

狗哥：

在Flink中，状态一致性的级别可以分为三种：

最多一次（AT-MOST-ONCE）：当任务发生故障时，最简单的做法是直接重启，不进行状态恢复或数据重放。每个数据正常情况下会被处理一次，遇到故障时就会丢失，因此也被称为“最多处理一次”。这种保证没有操作来保证结果的准确性，因此也被称为“没有保证”。如果主要诉求是速度且能接受近似正确的结果，这种解决方案可能是一个很好的选择。
至少一次（AT-LEAST-ONCE）：在实际应用中，通常希望至少不丢失数据。这种一致性级别意味着所有数据都不会丢失，并且肯定会被处理。然而，不能保证每个数据只被处理一次，有些数据可能会被重复处理。在某些场景下，重复处理数据不会影响结果的正确性，这种操作具有幂等性。例如，统计电商网站的UV时，对每个用户的访问数据进行去重处理，即使同一个数据被处理多次，也不会影响最终结果。然而，如果重复数据对结果有影响，例如统计PV或词频word count等场景，使用AT-LEAST-ONCE语义可能会导致结果不一致。为了达到AT-LEAST-ONCE的状态一致性，需要在发生故障时能够重放数据。一种常见的做法是使用持久化的事件日志系统，将所有事件写入持久化存储中。通过记录偏移量，当任务发生故障重启后，可以重置偏移量来重放检查点之后的数据。Kafka就是这种架构的一个典型实现。
精确一次（EXACTLY-ONCE）：这是最严格的一致性保证，也被称为“精确一次”或“恰好一次”。它意味着所有数据不仅不会丢失，而且只被处理一次，不会重复处理。也就是说，对于每个数据，最终体现在状态和输出结果上只能有一次统计。EXACTLY-ONCE可以真正意义上保证结果的绝对正确性，在发生故障恢复后，就如同从未发生过故障一样。为了实现EXACTLY-ONCE语义，首先必须达到AT-LEAST-ONCE的要求，即数据不丢失。因此需要具有数据重放机制来保证这一点。此外，还需要专门的设计来确保每个数据只被处理一次。Flink使用轻量级快照机制——检查点（checkpoint）来保证EXACTLY-ONCE语义。

在Flink中实现状态一致性的机制包括快照和检查点等机制。快照用于创建状态的副本并保存下来以便在故障发生时进行恢复。检查点则是一种特殊的快照，用于定期检查应用程序的状态并记录下来。当故障发生时，Flink可以从最近的检查点开始恢复状态并重新处理数据，以确保状态的一致性和结果的正确性。

狗哥：