把串流狀態的主要儲存搬到遠端檔案系統，再用非同步、亂序的記錄執行模型把遠端延遲藏起來。
Flink 1.x 把工作狀態放在 task manager 本機磁碟上的內嵌 RocksDB，在容器化的雲端部署裡，這等於逼作業為了買磁碟而買 CPU：以每核心 20 GB 狀態為門檻，阿里巴巴物流業務中有 35% 的作業是被磁碟而非 CPU 卡住的。Flink 2.0 把儲存層級整個翻轉過來，讓遠端分散式檔案系統（HDFS、OSS、S3）成為主要儲存、本機記憶體與磁碟退為快取；做法是 ForSt 這個 LSM-tree 狀態儲存，它的檔案透過 Unified File System 層持續串流寫到 DFS，而該層以邏輯對實體的對應與參考計數模擬出 hard link。由於工作目錄與 checkpoint 目錄現在同處一個檔案系統，checkpoint 退化成建立連結並向 Job Manager 註冊，復原與重新調整規模則完全不必搬資料。為了付出狀態讀取延遲暴增的代價（本機 NVMe 68 微秒，對上 OSS 23 毫秒），執行期把每筆記錄拆成非狀態轉換、非同步狀態存取、狀態後回呼三段，並由 Asynchronous Execution Controller 保證同一個 key 同時只有一個運算在飛行中，讓 per-key FIFO 順序、exactly-once checkpoint 與 watermark 完整性在亂序執行下依然成立。在 290 GB 的生產物流作業複本上，每次 checkpoint 都在 3 秒內完成（Flink 1.20 則有 19.7% 超過 30 秒），scale-out 快 49 倍，作業只要 8 個 compute unit 而不是 16 個，成本直接砍半。
Flink 誕生於 Map-Reduce 時代，運算與狀態放在同一批機器上，它的狀態管理也忠實反映這一點：keyed state 事先切成 key-group，每個 stream task 以 single-writer 語意獨佔自己的分割，內嵌後端（本機磁碟上的 RocksDB，或 Java heap 上的 map）在主執行緒上同步服務每一次讀寫。Checkpoint 則是由 Job Manager 往來源注入 marker 所驅動的非同步兩階段提交：marker 對齊之後，後端先同步複製一份本機狀態，再非同步上傳到外部 DFS，Job Manager 只保管檔案參考供復原使用。到了 2020 年代中期，部署樣貌完全變了——Kubernetes 上的容器化作業、以 CPU／記憶體／磁碟綁在一起販售的雲端 compute unit、便宜的物件儲存，以及頻寬大幅拉高的資料中心內部網路。工作負載也同步長大：2024 年雙 11 期間，阿里巴巴的 Flink 基礎設施吸收了每秒超過 44 億筆的進站資料流，而一個保存 60 天訂單與物流更新的物流作業，狀態量落在數百 GB 到 TB 之間。每個容器底下那顆本機磁碟，就這樣悄悄變成決定你要租幾台機器、重啟要等多久的關鍵。
Flink 2.0 把 Flink 1.x 的儲存層級倒過來：遠端分散式檔案系統保存權威的工作狀態，本機記憶體與磁碟只是可有可無的快取，而且狀態更新是持續串流寫到 DFS，不再等到 checkpoint 才上傳。這讓本機磁碟徹底退出資源估算，TB 級狀態的作業只需要用到運算真正需要的核心數。更微妙的是，它讓活躍狀態與 checkpoint 狀態成為同一個檔案系統裡的鄰居，這正是把 checkpoint 與狀態遷移從大量資料搬運變成 metadata 記帳的關鍵。論文的成本表就是直接後果：同一個物流作業在 Flink 1.20 純粹為了不超過磁碟上限就要 16 個 compute unit，在 Flink 2.0 只要 8 個。
因為遠端讀取比本機慢上大約 20 到 300 倍，Flink 2.0 不讓它阻塞主任務執行緒。每筆記錄的生命週期被切成三段——非狀態轉換、狀態存取、狀態後回呼——只有狀態存取交給獨立的執行緒池，另外兩段照舊留在主執行緒。主執行緒會在先前記錄等待 I/O 的同時繼續拉取新記錄，因此 CPU 密集的轉換與緩慢的遠端 I/O 得以重疊，也同時有大量狀態請求在飛行中，這才是真正把遠端頻寬吃滿的原因。不需要存取狀態的記錄會完全略過這套機制，行為與 Flink 1.x 一模一樣，這也是整套模型可以用組態直接繞過的原因。
亂序執行之所以安全，是因為 Asynchronous Execution Controller 在單一 task 內任一時刻只允許同一個 key 有一個運算在飛行中。Key Accounting Unit 記錄所有進行中運算的 key，包含非狀態運算、狀態存取與回呼；新到達的記錄若 key 正忙，就被放進 blocking buffer，等前一筆完成後依 FIFO 順序釋放。搭配 Flink 既有的 FIFO channel（本來就保證同 key 記錄依原始順序抵達同一個 task），這就重現了與 Flink 1.x 完全相同的 per-key 循序語意，同時允許不同 key 之間無上限地併行。complex event processing 等函式庫所依賴的 per-key single-writer 原子性，因此毫髮無傷。
watermark 承諾的是完整性：所有時間戳小於它的記錄都已處理完畢。非同步執行會打破這個承諾，因為 watermark 抵達時，可能還有比它更早的運算尚未完成，因此 Flink 2.0 引入 epoch——兩個相鄰 watermark 之間的區間——作為非同步進度追蹤的單位。epoch 在接收記錄時是 OPEN，被下一個 watermark 封住時轉為 CLOSED，其中所有記錄都完成後才是 FINISHED；Epoch Manager 用一個佇列管理 epoch，只有當某個 epoch 已 FINISHED 且排到隊頭時，它的 watermark 才能往下游發送。因為較晚的 epoch 可能比較早的先完成，隊頭規則正是同時保住單調性與完整性的機制，event-time timer 與 window 因此觸發得和同步執行時一模一樣。
Flink 的 exactly-once 意味著一次 checkpoint 提交的狀態剛好反映 marker 之前的所有記錄、且不含之後的任何記錄；在同步執行下這是白送的。Flink 2.0 用一個 draining 步驟把它拿回來：對齊的 marker 抵達時，運算子阻擋所有後續輸入，並要求 AEC 完成每一項待處理運算，包含還留在 blocking buffer 裡的記錄，以及它們衍生出的狀態存取與回呼。唯有如此才會做本機 checkpoint 並把 marker 往下游送出，而這與解除輸入阻擋是同一個原子步驟。這讓既有的兩階段提交協定與 Job Manager 的協調邏輯完全不用改，也是非同步執行可以靠重新組態開關、而不破壞與 Flink 1.x checkpoint 相容性的原因。
分散式檔案系統在狀態儲存最在意的每件事上都不一致：HDFS 的寫入立即可見，S3 則是最終一致；而且幾乎沒有一個原生支援 POSIX hard link，共享一份檔案通常只能複製資料。ForSt 插入一層 Unified File System，對 HDFS、OSS、S3 提供單一的邏輯檔案視圖，維護邏輯檔案到實體位置的對應與參考計數，並統一物件的可見性語意。有了這層之後，link 或 move 變成一筆 metadata 記錄而不是一次資料複製，而這正是讓 checkpoint 變便宜、讓復原不必搬資料的基本操作。它同時讓 Job Manager 保留既有的 checkpoint 生命週期邏輯、只把刪除動作委派出去，因此這層新機制對執行期其餘部分的侵入性極低。
在 Flink 1.x 中，LSM 的壓縮合併與運算子跑在同一批節點上，又被週期性 checkpoint 放大，正是逼人過度配置資源的 CPU 與 I/O 尖峰來源。既然工作狀態現在放在共享儲存上，別處的 compactor worker 就能直接讀寫這些檔案而不干擾正常處理，因此 ForSt 提供 compaction-as-a-service：由 Flink 任務觸發、無狀態的 compactor 執行。運算容量與壓縮合併容量從此可以獨立擴縮；由於壓縮合併是 I/O 密集的，compactor 可以直接擺進儲存叢集的網路內；而且多個作業的尖峰會在共享資源池裡錯開，不再一次全砸在同一個作業的 task manager 上。論文也明講遠端壓縮合併目前仍是 Flink 分支上的實驗性功能，尚未成為出貨預設。
運算子必須給執行期非同步提示才能啟用這條路徑。在物流的串流 join 中，非狀態轉換（把記錄轉型）與 Flink 1.x 完全相同；shipping 狀態表用 asyncUpdate 更新，order 狀態表用 asyncGetEntries 讀取，後面接一個 THEN 區塊，拿到取回的項目後執行 applyJoin 並輸出結果。互相獨立的狀態存取——例如 join 的兩側——可以同時發出；而 THEN 串接正是用來表達相依性、強制同一筆記錄的兩次狀態操作依序執行。回呼在主執行緒上跑，且狀態後回呼的優先權高於新到記錄的非狀態轉換，確保待處理記錄先完成，新工作才開始。
主任務執行緒從 FIFO 輸入通道拉取記錄，並把狀態請求送進 AEC。若 key 為 26 的記錄 O1 正在飛行中，Key Accounting Unit 就持有 key 26；當同樣是 key 26 的 O2 抵達，記帳單元偵測到衝突並把 O2 放進 blocking buffer，而 key 18 的 O3 則直接通過並取得一條狀態執行緒。O1 的請求完成後，它的回呼連同取回的狀態被排進 callback channel，主執行緒會優先於輸入通道消化這個通道；等 O1 真正結束，AEC 才依 FIFO 順序恢復 key 26 的待處理請求。飛行中記錄數與緩衝區大小可組態，預設為 6000 筆，每個運算子約數 MB 記憶體；緩衝區塞滿時 AEC 會阻擋新記錄，向上游表現為 backpressure。
網路層一如既往地跨輸入對齊 checkpoint marker。任務消費到對齊 marker 時，會阻擋輸入順序中排在其後的每一筆記錄，藉此確立 marker 之後的東西不會被提早處理。接著它在 AEC 上等待，直到 marker 之前的記錄不再有任何待處理運算：飛行中的記錄、卡在 blocking buffer 的記錄，以及它們衍生的每一次狀態存取與回呼。AEC 回報靜止後，才做本機 checkpoint、把 marker 往下游送出，並在同一個原子步驟裡解除輸入阻擋。Draining 會拉長 checkpoint，但有界的飛行中記錄數把它控制在數秒內；而 Flink 1.x 那種不對齊的 Chandy-Lamport checkpoint 仍可使用、不需要 draining，代價是必須把 in-flight 訊息也當成狀態一併 checkpoint。
Epoch Manager 維護一個 epoch 佇列，新的 epoch 與其 watermark 從尾端入隊、從頭端送出。抵達的記錄被指派給當前的 OPEN epoch；合併後的 watermark 抵達時，會在同一個原子操作中把該 epoch 封為 CLOSED 並開啟一個新的，等其中所有記錄完成後才轉為 FINISHED。出隊要求狀態為 FINISHED，而 watermark 只有排到隊頭才能發出——所以論文的例子中，已完成的 epoch [30, 40] 與它的 watermark 仍被擋著，因為前一個 epoch [20, 30] 還有未完成的記錄。至於合併輸入 watermark 本身，仍由 Flink 既有的單調 max-min 歸約在各輸入的 watermark 上算出，所以需要新機制的只有完整性，不是單調性。
由於 ForSt 持續把檔案串流寫到 DFS 上的工作目錄，marker 抵達時 checkpoint 需要的多數檔案其實早已持久化複製在那裡。後端為要納入 checkpoint 的檔案建立 hard-link 邏輯副本，由 UFS 更新邏輯對實體的對應並遞增參考計數；這些邏輯副本會像 Flink 1.x 註冊實體檔案一樣註冊到 Job Manager。當某個 checkpoint 過期，Job Manager 不直接刪檔案，而是對 hard-link 參考發出刪除，UFS 遞減參考計數，只有計數歸零時實體檔案才真的被移除。這是相對 Flink 1.x 協定唯一的改動，也正是它能保住 Job Manager 既有 checkpoint 生命週期管理、同時把底下的資料搬運整個拿掉的原因。
Flink 的重新組態依然是 pause-and-restart：作業暫停、worker 從最新 checkpoint 載入狀態、所有分割載入完成後恢復處理。改變的是載入這一步——新的 ForSt 實例直接掛上 DFS 上已存在的 checkpoint 檔案連結副本，沒有任何位元組從遠端儲存搬到本機磁碟。Flink 1.20 則必須下載並重建大約 290 GB；scale-out 時是兩倍，因為 32 個新 worker 各自去讀原本 16 個 worker 之一所存的資料，這也是三種情境中 scale-out 差距最大的原因。Flink 2.0 的殘餘成本在 metadata：重建 ForSt 實例仍要載入 LSM metadata，這使得 OSS 比 HDFS 慢 10 到 20 秒，作者也因此把啟動時合併 metadata 讀取列為未來工作。
ForSt 在運算節點上做兩層快取：記憶體中一個常見的 block-based LRU 快取，以及本機磁碟上一個以檔案為單位的次級快取，後者會把遠端的 SSTable 檔案整份複製過來。次級快取採用 History-Based Policy——淘汰用 LRU 掃過目前所有已快取檔案，載入則看頻率：前一分鐘存取頻率超過門檻的遠端檔案會被週期性載回來，這正是緩解 cache thrashing 的關鍵；此策略是 Flink 2.0 與阿里巴巴 Flink 服務的預設值，且設計成可抽換。遠端壓縮合併沿用 Flink 1.x 的觸發時機，但把實際工作外送：ForSt 後端把帶著 metadata 的壓縮合併請求送給服務，一個排程節點以 round-robin 指派給某個 compactor，完成後通知後端更新 LSM metadata。compactor 是無狀態的，而且因為壓縮合併屬於 I/O 密集、對運算節點的位置無所謂，可以直接部署在 DFS 叢集的內網裡。
Flink 2.0 於 2025 年釋出，是這個專案十年來的第一個大版本，而這套架構正是它的招牌功能；artifact 是 apache/flink 的 release-2.0 分支，ForSt 開源在 ververica/ForSt，而且這個設計在貢獻回社群之前，已經在阿里雲即時運算服務裡運行兩年以上，也撐過了雙 11 尖峰。它最可移植的部分其實不是儲存佈局，而是非同步執行模型：它示範了如何在記錄亂序執行的前提下，用 key 記帳、draining 與 epoch 佇列同時保住 per-key FIFO 順序、exactly-once checkpoint 與 watermark 完整性——任何想把狀態搬離節點的串流執行期都得重現這套配方。它也替串流補上了 Snowflake、Amazon Aurora、Socrates、PolarFS 早已在分析型與交易型資料庫走完的十年分離化趨勢，並與 RisingWave 獨立得到的結論會合（作者自己說那是最接近的架構）：以遠端儲存作為真實來源，再加上遠端壓縮合併。對照更早的外部狀態串流系統，這是一個直接的回答——MillWheel 把狀態放進 BigTable 與 Spanner，卻是在記錄的關鍵路徑上同步讀取；Meta 以 ZippyDB 為後盾的管線也只在 monoid 式的附加更新下才避得開完整狀態載入；Flink 2.0 則在保留通用 keyed state API 與 LSM 儲存的同時，把遠端延遲藏了起來。最後，UFS 那一招——讓 checkpoint 變成對本來就住在 checkpoint 檔案系統裡的檔案做參考計數——其實可以推廣到 Flink 之外：它與現代 lakehouse 及雲端資料庫儲存層的 zero-copy clone 是同一個洞見，只是換到串流快照上。
“Flink 2.0 relies on a remote distributed file system (DFS) for primary state storage and uses local disks as a secondary cache, with state updates streamed continuously and directly to the DFS.（中譯：Flink 2.0 以遠端分散式檔案系統（DFS）作為主要狀態儲存，本機磁碟則作為次級快取，狀態更新持續且直接串流寫入 DFS。）”
“The AEC enforces a single active in-flight computation per key, within each task, at a time.（中譯：AEC 強制每個 task 內、每個 key 在同一時間只有一個活躍的飛行中運算。）”
“This transforms checkpointing from a data-intensive operation to a lightweight reference creation.（中譯：這把 checkpoint 從一個資料密集的操作，轉變成一次輕量的參考建立。）”