apache-flink - Apache Flink：为什么选择 MemoryStateBackend 而不是 FsStateBackend？

Question

Flink 有 aMemoryStateBackend和 a FsStateBackend（和 a RocksDBStateBackend）。两者似乎都扩展了HeapKeyedStateBackend，即存储当前工作状态的机制是完全一样的。

这个SO answer说主要区别在于在MemoryStateBackendJobManagers 内存中保留检查点的副本。（我无法从源代码中收集到任何证据。）这MemoryStateBackend也限制了每个子任务的最大状态大小。

现在我想知道：你为什么要使用MemoryStateBackend?

标签： apache-flinkflink-streaming

Answer 1

正如您所说，两者MemoryStateBackend和FSStateBackend都基于HeapKeyedStateBackend. 这意味着，两个状态后端都将操作符的状态作为 TaskManager 的 JVM 堆上的常规对象来维护，即状态始终在内存中访问。

后端的不同之处在于它们如何保持检查点的状态。检查点是存储在某处的应用程序的所有操作员状态的副本。如果发生故障，应用程序会重新启动，并且操作员的状态会从检查点初始化。

将FSStateBackend检查点存储在文件系统中，通常是 HDFS、S3 或安装在所有工作节点上的 NFS。将MemoryStateBackend状态存储在 JobManager 的 JVM 中。这有以下优点和缺点：

优点：

• 无需设置（分布式）文件系统。
• 无需配置存储位置。

缺点：

• 如果 JobManager 进程死亡，状态将丢失。
• 状态大小受 JobManager 内存大小的限制。

由于如果 JM 发生故障，检查点会丢失，因此MemoryStateBackend不适用于大多数生产用例。它对于开发和测试有状态的应用程序很有用，因为它不需要配置或设置。