在大规模流处理领域状态管理State Management始终是决定作业吞吐量、延迟和弹性伸缩能力的核心命脉。随着 Apache Flink 进入 2.x 时代其状态架构迎来了自项目诞生以来最彻底的一次颠覆 —— 从传统的存算一体本地优先架构全面转向云原生的存算分离Disaggregated State架构。本文将深度剖析 Flink 1.x以 RocksDB 为核心与 Flink 2.x以 ForSt 为核心在状态读写流程梳理并通过全方位的横向对比带你看清这场技术演进背后的设计。一、 Flink 1.x 状态架构 RocksDB 存算一体在 Flink 1.x 中当面对超大状态场景时RocksDBStateBackend是绝对的主力。它基于经典的单机LSM-Tree日志结构合并树架构。1. 核心组件分布内存层包含MemTable内部基于跳表 SkipList 实现用于接收并排序最新写入和Block Cache缓存解压后的磁盘数据块加速读。磁盘层本地磁盘NVMe/SSD上分层存储的SST有序字符串表文件。远端层HDFS/S3 等分布式存储在 1.x 中它仅作为 Checkpoint 的备份通路。2. 深度拆解1.x 读写与快照流程写路径同步阻塞当数据流经算子并触发state.update(value)时数据通过 JNIJava Native Interface调用直接写入本地 RocksDB 的内存MemTable中。当MemTable写满后会变成Immutable MemTable, 随后Flush写入磁盘变成SSTSorted String Table文件当ck时将本地 文件上传到远端存储一般为hdfs。核心内幕Flink 在底层写入时默认调用了setDisableWAL(true)因此完全关闭了 RocksDB 的单机预写日志WAL。Flink 宁愿在挂掉时通过“回滚上游 Kafka 重放”来恢复内存也绝不在运行时双写本地盘。刷盘与合并Flush Compaction当MemTable满了后台线程将其异步 dump 到本地磁盘生成 Level 0 层的 SST。随后触发的多层 SST 归并排序Compaction会疯狂抢占本地 TaskManager 的 CPU 和磁盘 I/O。增量检查点Incremental Checkpoint触发 Checkpoint 时RocksDB 在本地对 SST 文件创建Hard Link硬链接毫秒级阻塞主线程随即释放。随后Flink 的异步线程负责将本地新生成的 SST 文件物理复制并上传到远端 HDFS/S3。读路径多级查找算子调用state.value()线程会依次检索内存MemTable→\rightarrow→Immutable MemTable→\rightarrow→内存Block Cache→\rightarrow→本地磁盘SST文件期间利用布隆过滤器避免盲目 I/O。3. 1.x 痛点单机磁盘瓶颈状态大小受限于本地磁盘容量超大状态极易爆盘。I/O 资源突刺后台 Compaction “肉搏”抢资源导致作业吞吐频繁出现断崖式下跌。弹性伸缩极其缓慢作业扩缩容Rescaling时新节点必须从远端全量下载 SST 文件并在本地重建 RocksDB 实例TB 级状态恢复往往需要数十分钟甚至数小时。二、 Flink 2.x 状态架构彻底释放瓶颈的“存算分离”为了将流处理推向真正的云原生化Flink 2.x 彻底打破了“本地磁盘为主存储”的铁律推出了专为流式存算分离定制的存储引擎 ——ForSt (For Streaming)。1. 核心架构重构在 2.x 中远端分布式存储DFS直接晋升为 Primary Storage主存储。本地磁盘退化为高速只读缓存Secondary Local Cache。同时全链路 API 进行了全异步化Asynchronous State API重写。2. 深度拆解2.x 全异步读写流程异步非阻塞写路径当算子调用全新的异步接口state.asyncUpdate(value)时当前 Task 线程绝不等待而是将请求封装为StateRequest丢入状态请求队列后立即返回继续处理下一条数据。后台的AEC异步执行控制器从队列提取请求将相同 Key 空间的修改自动合并成大批次Batch直接写入 TaskManager 堆外内存的ForSt MemTable中同样不写单机 WAL。流水线乱序读路径当调用state.asyncValue()时Task 线程投递请求并拿到一个Future随即释放。AEC 异步线程接管请求按照内存→\rightarrow→本地 SSD Cache→\rightarrow→远端 DFS 网络 RPC的路径进行检索。网络数据返回后注入Future并触发回调。在等待远端 I/O 期间算子可以疯狂处理后续数据通过乱序执行模型Out-of-Order Execution和高并发请求彻底掩盖了网络延迟。秒级轻量化 Checkpoint因为 ForSt 在运行期间就已经把内存满溢的数据SST持续、直接地通过网络写向了远端 DFS。当 Checkpoint 栅栏Barrier到达时AEC 只需要强行 Flush 队列中残存的请求并等待远端落盘的ACK。整个 Checkpoint 变成了纯粹的元数据标记不再需要打包传输大文件数秒内即可完成。三、 Flink 1.x vs Flink 2.x 状态对比为了让你对这两代架构的演进有更直观的认识我们将核心指标归纳为下表对比维度Flink 1.x (RocksDB 存算一体)Flink 2.x (ForSt 存算分离)带来的业务价值状态主存储 (Primary)本地磁盘 (Local SSD/NVMe)远端分布式存储 (HDFS/S3/OSS)状态容量突破单机限制实现理论上的无限扩展。状态访问 API 模型同步阻塞 (Synchronous Blocking)全异步乱序执行 (Asynchronous)杜绝单条数据 I/O 卡死全局用高并发吞吐掩盖网络延迟。单机 WAL (预写日志)默认关闭 (setDisableWALtrue)默认关闭 (依托 Flink 容错大盘)避免流处理中的双重写入榨干计算节点每一步的性能。Checkpoint 耗时较长 (需要在快照期同步/异步上传 SST 文件)秒级 (运行时持续写快照期仅对齐元数据)极大减小了 Checkpoint 期间对线上业务造成的吞吐颠簸。弹性伸缩与故障恢复缓慢 (需全量下载状态文件并在本地重建实例)极致快 (秒级拉起Lazy Restore 按需异步加载)大状态作业遭遇故障或扩缩容时真正具备了秒级弹性能力。本地 I/O 资源稳定性较差 (本地 Compaction 会引发严重的 I/O 突刺)极好 (Compaction 算子卸载到远端或独立线程)TaskManager 算力极其纯净消除了业务吞吐断崖下跌的顽疾。四、 总结与升级建议Flink 2.x 的存算分离状态架构是流计算走向全面云原生、微服务化弹性的必经之路。它巧妙地利用“动态运行期全异步乱序静态检查点强行冲刷确认”的设计既享受了网络异步带来的超高吞吐又死死守住了 Exactly-Once 的容错底线。 升级避坑提示由于底层状态架构发生了基因级的重构Flink 2.x放弃了与 1.x 版本的状态Savepoint/Checkpoint直接二进制兼容。此外为了全面拥抱现代 Java 的并发和异步特性Flink 2.x彻底移除了对 Java 8 的支持最低运行要求全面提升至 Java 11/17。在享受 2.x 极致弹性的红利前务必提前做好技术栈的升级规划。