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 存在的理由。