添加单次键值缓存写入操作导致我的 Worker 失效——而且没有向调用方抛出任何错误。
我运营着一个韩国直面消费者广告运营流水线，其中一个 Worker 负责为每个请求在约 400 个广告账户间分发性能检查任务。计算看起来没问题：400 个账户 × 2 次应用程序接口调用 = 800 个子请求，远低于云flare每次调用的硬性上限 1000 次。随后，我添加了键值写入操作以缓存每个结果。400 × 3 = 1200。Worker 静默停止处理最后约 200 个账户。没有 5xx 错误。没有异常传播。只是数据缺失。我花了两天时间使用 wrangler tail 才发现了这一行日志：
workers/runtime/fetch: subrequest count exceeded limit of 1000
使此限制对于扇出模式尤其棘手之处在于：它是每次调用重置，而不是按批次或队列消息重置。而且计数包含的内容超出你的预期——每次 fetch()、每次键值 get/put、每次 R2 操作、每次 D1 查询、每次持久化对象存根调用都计入在内。唯一有用的例外是：Queue.sendBatch() 不 计入此限制。这是修复方案所依赖的逃生通道。
架构上的解决方案是将扇出触发器与扇出工作分离。入口 Worker 接收请求并立即调用 env.QUEUE.sendBatch()，为每个账户发送一条消息——零次上游获取请求，零次键值写入，远低于任何限制。随后，每个队列消费者调用处理一小批消息（我设置 max_batch_size = 10），孤立地处理每个账户的 3 个子请求。十条消息 × 3 个子请求 = 每次调用 30 个。上限变得无关紧要。
在采用此模式之前，值得了解的权衡是：队列是发后不管机制。如果你的用例要求在一个同步超文本传输协议响应中返回所有 400 个账户的摘要——例如实时仪表板——仅靠这种方法无法实现。那是一个不同的问题，需要一个持久化对象作为聚合点，这会带来其自身的子请求考量。
我在 dailymanuallab.com 上撰写了完整的细分分析——包括用于同步扇出的持久化对象聚合模式、确切的 wrangler.toml 消费者配置以及完整的子请求参考表。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
