《Flink 架构》系列（已完结），共包含以下 6 篇文章：

• Flink 架构（一）：系统架构
• Flink 架构（二）：数据传输
• Flink 架构（三）：事件时间处理
• Flink 架构（四）：状态管理
• Flink 架构（五）：检查点 Checkpoint（看完即懂）
• Flink 架构（六）：保存点 Savepoint

? 如果您觉得这篇文章有用 ✔️ 的话，请给博主一个一键三连 ??? 吧 （点赞 ?、关注 ?、收藏 ?）！！！您的支持 ??? 将激励 ? 博主输出更多优质内容！！！

在前面的博客中我们指出，大部分的流式应用都是有状态的。很多算子都会不断地读取并更新某些状态，例如：窗口内收集的记录，输入源的读取位置或是一些定制的，诸如机器学习模型之类的特定应用状态。无论是内置状态还是用户自定义状态，Flink 对它们都一视同仁。本篇博客我们会对 Flink 支持的不同类别的状态进行介绍。我们将解释如何利用 状态后端（state backend）对状态进行存储和维护，以及有状态的应用如何通过状态再分配实现扩缩容。

通常意义上，函数里所有需要任务去维护并用来计算结果的数据都属于任务的状态。你可以把状态想象成任务的业务逻辑所需要访问的本地或实例变量。下图展示了某个任务和它状态之间的典型交互过程。

任务首先会接收一些输入数据。在处理这些数据的过程中，任务对其状态进行读取或更新，并根据状态和输入数据计算结果。我们以一个持续计算接收到多少条记录的简单任务为例。当任务收到一个新的记录后，首先会访问状态获取当前统计的记录数目，然后把数目增加并更新状态，最后将更新后的数目发送出去。

应用读写状态的逻辑通常都很简单，而难点在于如何高效、可靠地管理状态。这其中包括如何处理数量巨大、可能超出内存的状态，如何保证发生故障时状态不会丢失。所有和状态一致性、故障处理以及高效存取相关的问题都由 Flink 负责搞定，这样开发人员就可以专注于自己的应用逻辑。

在 Flink 中，状态都是和特定算子相关联。为了让 Flink 的运行层知道算子有哪些状态，算子需要自己对其进行注册。根据 作用域 的不同，状态可以分为两类：算子状态（operator state）和 键值分区状态（keyed state），我们将在接下来介绍它们。

1.算子状态

算子状态的作用域是某个算子任务，这意味着所有在同一个并行任务之内的记录都能访问到相同的状态。算子状态不能通过其他任务访问，无论该任务是否来自相同算子。下图展示了任务访问算子状态的过程。

Flink 为算子状态提供了三类原语：

• 列表状态（list state）：将状态表示为一个条目列表。
• 联合列表状态（union list state）：同样是将状态表示为一个条目列表，但在进行故障恢复或从某个保存点启动应用时，状态的恢复方式和普通列表状态有所不同。
• 广播状态（broadcast state）：专门为那些需要保证算子的每个任务状态都相同的场景而设计。这种相同的特性将有利于检查点保存或算子扩缩容。

2.键值分区状态

键值分区状态会按照算子输入记录所定义的键值来进行维护或访问。Flink 为每个键值都维护了一个状态实例，该实例总是位于那个处理对应键值记录的算子任务上。当任务在处理一个记录时，会自动把状态的访问范围限制为当前记录的键值。

因此所有键值相同的记录都能访问到一样的状态。下图展示了任务和键值分区状态的交互过程。

你可以把键值分区状态想象成一个在算子所有并行任务上进行分区（或分片）的键值映射。Flink 为键值分区状态提供了不同原语，它们的区别在于分布式键值映射中每个键所对应存储值的类型不同。我们接下来简要讨论一下键值分区状态最常用的几个原语。

• 单值状态（value state）：每个键对应存储一个任意类型的值，该值也可以是某个复杂数据结构。
• 列表状态（list state）：每个键对应存储一个值的列表。列表中的条目可以是任意类型。
• 映射状态（map state）：每个键对应存储一个键值映射（map），该映射的键（key）和值（value）可以是任意类型。

通过这些状态原语，我们可以为 Flink 状态指定不同的结构，从而实现更加高效的状态访问。

3.状态后端

有状态算子的任务通常会对每一条到来的记录读写状态，因此高效的状态访问对于记录处理的低延迟而言至关重要。为了保证快速访问状态，每个并行任务都会把状态维护在本地。至于状态具体的存储。访问和维护，则是由一个名为 状态后端 的可插拔组件来决定。状态后端主要负责两件事：本地状态管理 和 将状态以检查点的形式写入远程存储。

对于本地状态管理，状态后端会存储所有键值分区状态，并保证能将状态访问范围正确地限制在当前键值。Flink 提供的一类状态后端会把键值分区状态作为对象，以内存数据结构的形式存在 JVM 堆中；另一类状态后端会把状态对象序列化后存到 RocksDB 中，RocksDB 负责将它们写到本地硬盘上。前者状态访问会更快一些，但会受到内存大小的限制；后者状态访问会慢一些，但允许状态变得很大。

由于 Flink 是一个分布式系统但只在本地维护状态，所以状态检查点就显得极其重要。而考虑到 TaskManager 进程以及它上面所有运行的任务都可能在任意时间出现故障，因此它们的存储只能看做是易失的。状态后端负责将任务状态以检查点形式写入远程持久化存储，该远程存储可能是一个分布式文件系统，也可能是某个数据库系统。不同的状态后端生成状态检查点的方式也存在一定差异。例如：RocksDB 状态后端支持增量检查点。这对于大规模的状态而言，会显著降低生成检查点的开销。

后续我们会详细讨论不同状态后端的区别以及它们各自的优劣。

4.有状态算子的扩缩容

流式应用的一项基本需求是 根据输入数据到达速率的变化调整算子并行度。对于无状态的算子，扩缩容很容易。但对于有状态算子，改变并行度就会复杂很多，因为我们需要把状态重新分组，分配到与之前数量不等的并行任务上。Flink 对不同类型的状态提供了四种扩缩容模式。

4.1 带有键值分区状态的算子

带有键值分区状态的算子 在扩缩容时会根据新的任务数量对键值重新分区。但为了降低状态在不同任务之间迁移的必要成本，Flink 不会对单独的键值实施再分配，而是会把所有键值分为不同的 键值组（key group）。每个键值组都包含了部分键值，Flink 以此为单位把键值分配给不同任务。下图展示了键值分区状态通过键值组进行重新分区的过程。

4.2 带有算子列表状态的算子

带有算子列表状态的算子 在扩缩容时会对列表中的条目进行重新分配。理论上，所有并行算子任务的列表条目会被统一收集起来，随后均匀分配到更少或更多的任务之上。如果列表条目的数量小于算子新设置的并行度，部分任务在启动时的状态就可能为空。下图展示了算子列表状态的重分配过程。

4.3 带有算子联合列表状态的算子

带有算子联合列表状态的算子 会在扩缩容时把状态列表的全部条目广播到全部任务上。随后由任务自己决定哪些条且该保留，哪些该丢奔。下图展示了算子联合列表状态的重分配过程。

4.4 带有算子广播状态的算子

带有算子广播状态的算子 在扩缩容时会把状态拷贝到全部新任务上。这样做的原因是广播状态能确保所有任务的状态相同。在缩容的情况下，由于状态经过复制不会丢失，我们可以简单地停掉多出的任务。下图展示了算子广播状态的重分配过程。