Cloudflare Queues：在邊緣處理背景工作

Cloudflare Queues 解決的是每個無伺服器應用遲早都會撞上的那個問題：一個請求抵達，觸發了一段使用者本來不該等待的工作。寄出確認郵件、把上傳的圖片改尺寸、把記錄同步到第三方服務。這些工作的共同點是：它們必須發生，但並不需要在使用者按下按鈕的那一刻發生。在傳統伺服器上，你把這類工作交給一個背景工作行程就好。可是在 Workers 上，請求處理完就結束，根本沒有可以交出去的常駐行程。

常見的幾種繞道做法，比看起來更糟。把工作放在請求裡同步做完，等於讓使用者去等一家郵件服務商的回應。向另一個 Worker 丟出請求卻不等待它，只要發起方的呼叫先結束，這個工作就丟了。這兩種做法都撐不過服務商的一次故障。

佇列真正給你的是什麼： 是持久性與重試，不是速度。生產者寫入一則訊息後立刻返回，另一個獨立的消費者 Worker 把它取走；消費者失敗時，訊息會回到佇列裡，而不是消失在虛空中。價值全在這裡。如果你的背景工作本身經不起被重跑一次，佇列救不了你。

各個元件如何咬合

一個佇列有兩端，兩端都是 Workers。

生產者是任何綁定了佇列的 Worker。它帶著訊息內容呼叫 send，只要訊息被持久化寫入，這個呼叫就立刻返回。使用者的請求不必等待那段工作就能結束。

消費者是帶有佇列處理常式的 Worker。Cloudflare 會用一批訊息來呼叫它，處理常式對每一則成功處理的訊息逐一確認。確認是逐則進行的，因此同一批裡已經成功的那些，不會因為其中一則出錯而被牽連。凡是沒有被確認的，都會被重新投遞。

真正值得圍繞著它做設計的，就是這個重新投遞的行為。一則訊息可能不只抵達一次，也就是說你的消費者必須是冪等的。在佇列消費者裡不帶冪等鍵就去扣一張卡，等於替自己安排一堆退款工作。郵件寄兩遍只是讓人煩躁，錢扣兩次就是一起客服事故。

死信佇列接住那些反覆失敗的訊息。沒有它，一則徹底損壞的訊息會一直重試到用完嘗試次數，然後無聲無息地消失。有了它，這則訊息會落在一個你能打開來查看的地方。請在需要它之前就設定好，而不是等出事之後再補。

一次操作到底要花多少錢

這個計費模型夠特別，特別到常常把團隊絆倒，因為計費單位並不是訊息則數。

每寫入、讀取或刪除 64 KB 資料計為一次操作 。一則小於 64 KB 的訊息正常投遞一次，花費三次操作：一次寫、一次讀、一次刪。而一則 127 KB 的訊息，每個動作都要兩次操作，同樣是這一次投遞，總共就要六次操作。換句話說，計費跟著資料量走，而不是跟著訊息則數走。

重試會改變這筆帳。每一次重新投遞都是又一次讀，寫進死信佇列則是又一次寫。一個消費者在同一則訊息上失敗五次才成功，就代表多出五次讀取，最後可能還要加上寫進死信佇列的那一次寫入，花掉的遠不只三次操作。這正是應該去修好一個不穩定的消費者，而不是把它的重試次數調高的理由。

在斷定它便宜之前，先用你自己的流量把帳算一遍。每月一百萬則訊息、每則三次操作，就是三百萬次操作，超出付費方案的額度，費用大約八十便士。這確實很便宜。但每天一千萬則訊息，那就是另一場對話了。

決定它是否合適的那些上限

資料取自 Cloudflare 的 Queues 限制文件 ，於 2026 年 8 月核對。

其中兩條比其餘都重要。單則訊息 128 KB 的上限代表你不會把檔案放進佇列。你把指標放進佇列，把檔案放進 R2，這本來就是比較正確的形態。25 GB 的積壓上限是保護你不掉進無聲災難的那道閘：如果消費者在某個星期五壞掉而沒人發現，佇列會被塞滿，然後用儲存錯誤拒絕新訊息，而不是悄悄把它們丟掉。報錯和靜默丟棄的差別很大，因為報錯至少會出現在你的指標和日誌裡，而被靜默丟掉的資料沒有人會替你記錄。

每秒 5,000 則訊息的吞吐量已經很慷慨，但它是按佇列計算的。單獨一條被打爆的熱佇列就是瓶頸，而這個瓶頸可以靠設計避開，把流量分片到多條佇列上即可。

什麼時候 Cloudflare Queues 是錯誤答案

當這段工作確實是同步的時候。 如果使用者就是要在螢幕上看到結果，把它丟進佇列只會多一次往返，再加上一個輪詢問題。就地做完，並且把它做快。

當你需要有序而且恰好一次的處理時。 Queues 提供的是至少一次投遞。任何要求嚴格順序或恰好一次語意的情境，都需要佇列並不提供的協調能力，而在 Cloudflare 上，這通常代表一個 Durable Object。

當它是排程工作而不是被觸發的工作時。 每晚的清理不需要佇列。用一個 cron 觸發器直接呼叫 Worker 更單純，會動的零件也更少。

當這段工作超過 15 分鐘時。 超出執行時間上限的消費者會在工作中途被終止。跨多個步驟的長流程需要的是 Cloudflare Workflows，它就是為了跨步驟的持久執行而設計的，而不是一個想把狀態抓在手上一刻鐘的佇列消費者。

我們那篇用 Cloudflare Workers 建構無伺服器 API 的指南談的正是通常會產生這類工作的請求路徑，而Cloudflare Workers 與 AWS Lambda 的比較 則說明了它的執行模型與大多數團隊帶來的 SQS 加 Lambda 模式有何不同。

從哪裡開始

在你的請求處理常式裡挑出唯一那件使用者不需要等待的工作，只把這一件搬走。第一天就給它配上死信佇列，把消費者做成冪等的，並且真的去看積壓指標，而不是想當然耳地認為它是空的。上線一週之後再回頭看這條曲線：積壓始終貼近零，代表這件工作確實適合放進佇列；積壓一路往上爬，代表問題出在消費者身上，而不在佇列上。

Mecanik 透過我們的軟體開發 團隊設計並審視邊緣架構，其中也包括有人反過來追問這項工作到底需不需要佇列的那一步。大多數系統需要的是一兩條佇列，而不是每個功能配一條。

延伸閱讀： Cloudflare Hyperdrive：從邊緣連線 Postgres 、2026年如何建構Web應用：英國開發者指南 、Cloudflare D1：在邊緣建構無伺服器 SQL 資料庫 、Cloudflare Workers AI：2026 年在邊緣執行 AI 模型 。

常見問題

Cloudflare Queues 的價格是多少？ Workers Free 方案每天包含 10,000 次操作，付費方案每月包含一百萬次操作，超出部分每百萬次操作 0.40 美元，而且不收取對外流量費。每寫入、讀取或刪除 64 KB 計為一次操作，因此一則小於 64 KB 的普通訊息總共花費三次操作：一次寫、一次讀和一次刪。

在 Cloudflare Queues 裡什麼算是一次操作？ 每寫入、讀取或刪除 64 KB 資料算一次。小於 64 KB 的訊息每個動作花費一次操作，而 127 KB 的訊息每個動作要花兩次。每次重試都會多出一次讀，寫進死信佇列又會多出一次寫，所以一個不穩定的消費者，成本遠高於每則訊息三次操作的基準。

Cloudflare Queues 的單則訊息最大是多少？ 每則訊息 128 KB，批次傳送則限制為 100 則訊息或合計 256 KB。正因為有這個上限，你會把內容資料存進 R2 或別的物件儲存，只把一個指標放進佇列，而無論有沒有這個限制，這都是比較好的設計。

Cloudflare Queues 保證恰好一次投遞嗎？ 不保證。投遞是至少一次，所以一則訊息可能抵達多次，你的消費者必須是冪等的。在消費者裡不帶冪等鍵就扣款或發放額度，遲早會重複一次。需要嚴格順序或恰好一次語意時，應該改用 Durable Object。

什麼時候不該使用 Cloudflare Queues？ 當使用者正在等結果時，當你需要嚴格順序或恰好一次處理時，當工作是排程執行而非被觸發、一個 cron 觸發器就夠用時，或者當這段工作會超過消費者 15 分鐘的執行時間上限時。最後這種情況，正是 Cloudflare Workflows 存在的理由。