Cloudflare D1 全球讀取副本：那些官方沒說清楚的延遲數字

你有沒有遇過這種情況：文件上寫著「全球分散式」，你興沖沖地部署上去，結果用戶跟你說「為什麼我剛存的資料消失了」？

我最近在研究 Cloudflare D1 的 Global Read Replication，試圖搞清楚它的延遲到底是多少，以及它的「一致性保證」是否值得信任。官方文件說得很美，但真正能讓你做出部署決策的數字，藏在 changelog、社群討論和 benchmark 工具裡——不是首頁。

先把數字擺出來

研究完之後，我整理出這張表：

這裡面有幾個細節值得說清楚。

就近副本讀取的 5–20ms 是在命中本地副本的情況下——也就是你的 Worker 和副本在同一個 Cloudflare 數據中心區域。這個速度其實不錯，接近本地 SQLite 的感覺。

跨洲主庫讀取的 50–200ms 則是反例：如果你的讀取因為某些原因被路由到了主庫（Primary），而主庫在地球另一端，延遲就會飆上去。這不是副本的問題，而是副本「沒辦法回答你的問題」的情況。

Confirm lag 這個概念很關鍵，我後面會細說。

D1 的全球讀取副本不是用「最終一致性」（Eventual Consistency）設計的。這是我覺得最有意思的地方。

大部分分散式資料庫為了效能，會選擇最終一致性：寫入主庫之後，副本「終究」會同步上來，但不保證什麼時候。這讓「讀自己剛寫的資料」（read your own writes）變成一個不確定的事情。你剛存了一筆訂單，立刻查詢，有可能查不到——因為副本還沒同步。

D1 選了不同的路：Sequential Consistency，用的機制叫做 Bookmark，本質上是一個 Lamport timestamp。

運作方式大概是這樣：當你做了一次寫入，D1 會給你一個 Bookmark 值。下次讀取的時候，你可以帶著這個 Bookmark 告訴 D1：「我要讀的資料，至少要包含這個時間點之後的狀態。」D1 會確保副本的狀態達到這個時間點，再回傳給你。

這就是 Confirm Lag 的由來——副本要「確認」自己已經同步到那個 Bookmark 所代表的狀態，才能服務這次讀取。ENAM 到 WNAM（東岸到西岸）的確認延遲大約是 30–45ms，跨大西洋則是 55–75ms。

這個設計讓 “read your own writes” 有了保障，代價是部分讀取請求需要等副本確認同步。對大多數應用場景來說，這個取捨是值得的——用戶體驗上，「我剛存的東西消失了」遠比「這次查詢多等了 40ms」更難接受。

了解了這些數字之後，幾個問題就有答案了：

什麼情況適合 D1 Global Read Replication？

如果你的應用讀多寫少，而且讀取大部分是不需要最新狀態的歷史資料（例如文章列表、商品目錄），就近副本的 5–20ms 讀取速度相當誘人。結合 Cloudflare Workers 的邊緣運算，可以做到很低的端到端延遲。

什麼情況要小心？

高頻寫入 + 立即讀取的場景。每次寫入之後的讀取都需要帶 Bookmark 等待確認，如果你的業務邏輯是「存完馬上查」，confirm lag 會累積。跨洲的情況下，每次這樣的操作多等 30–75ms，對某些實時性要求高的應用可能是個問題。

APAC 的情況？

這裡有個資訊缺口：Cloudflare 官方目前沒有公佈 APAC 區域的延遲數字。如果你的用戶主要在台灣、日本、東南亞，需要自己去測。Cloudflare 有一個互動式 benchmark 工具 replicas.pages.dev，可以從你的位置實際測試讀取延遲，這比看文件上的數字更可靠。

Sequential Consistency 和 Eventual Consistency 的差別，不只是技術細節，而是影響你整個應用的狀態管理方式。

最終一致性的世界裡，你需要在應用層面處理「資料可能不是最新的」這件事——顯示「最後更新時間」、加上版本號、或者接受偶爾的資料不一致。

Sequential Consistency 的世界裡，你可以假設讀到的資料是連貫的，但需要理解 Bookmark 機制，並且在設計 API 時考慮到 confirm lag 的存在。

兩種方式都有它的位置，但混淆它們的後果通常很慘。D1 選擇 Sequential Consistency 其實是一個相對保守、對開發者友好的選擇——代價由基礎設施承擔，而不是讓應用開發者自己處理一致性邊界情況。

說了這麼多，我還有一個疑問沒有答案：在 Bookmark 確認等待期間，D1 是阻塞整個讀取請求，還是有某種回退機制？官方文件沒有說得很清楚。如果是純阻塞等待，極端情況下（網路波動、副本落後）的 P99 延遲可能比表中的數字高很多。

這也許是值得用 replicas.pages.dev 壓測一下的問題。如果有人做過，很想知道結果。

一見生財，2026-03-08