# CF Queues 免费额度连续触顶 — 2026-04-24 现状更新与部署记录

| 字段 | 值 |
|---|---|
| 状态 | 🔴 每日 10k 免费额度连续 14 天被打穿；Plan 8 + Plan 13 已部署，效果待验证 |
| 触发事件 | 2026-04-23 23:58 UTC CF 邮件："You have reached the daily Cloudflare Queues free tier limit of 10000 operations. Attempts to send a message to a queue will fail until the limit resets at 2026-04-25 at 00:00:00 UTC." |
| 受影响环境 | ArcBlock 主账号 `983482dc52a0aee5dbd7f986840a6190` / `staging-aigne-hub-payment-kit` |
| 本文定位 | **更正并替代** `cf-queues-ops-alert-analysis.md` 与 `payment-kit-platform-analysis-2026-04-20.md` 中与现状冲突的预期值和承诺阈值。原文档保留以备历史溯源，勘误对照详见 §5。|

---

## 1. 一句话结论

**账号是免费套餐（不是 $5/月付费），Queue 免费配额是"每天 10,000 ops"（不是"每月 1,000,000 ops"）；自 2026-04-11 起连续 14 天超限，2026-04-24 06:00 UTC 首次实测触发 send() 拒绝，约 18 小时队列完全停写。** Plan 8（`runAllScheduledJobs` D1 合并）+ Plan 13（`depositVault` 合并 + `creditQueue` 恢复批处理）于 2026-04-24 12:33 UTC 部署，效果需 04-25 UTC 完整一日数据才能评估。

---

## 2. 事实更正（与旧文档冲突的关键点）

### 2.1 账号是 **免费套餐**，不是付费 $5

| 证据 | 内容 |
|---|---|
| CF 邮件原文（2026-04-23 23:58 UTC）| `"daily Cloudflare Queues free tier limit of 10000 operations"` + `"upgrade your (ArcBlock) account to the Paid plan"` |
| API `/accounts/:id/subscriptions` | 返回空数组（无任何付费订阅） |
| Workers account settings | `default_usage_model: "standard"`（仅表示计费模型类别，不表示是否付费） |

**影响的旧文档陈述**：
- `cf-queues-ops-alert-analysis.md` §1.1 / §8.2 / §17.2 / §18.3 多处假设"1M/月免费额度"
- `payment-kit-platform-analysis-2026-04-20.md` §3.1 成本表整表基于"$5/月付费"基线

### 2.2 Queue 免费配额是 **10k ops/day**，不是 1M ops/month

- 每日 UTC 00:00 重置，达到 10k 后 `queue.send()` 返回错误直到次日
- 1 条消息 = 1 Write + 1 Read + 1 Delete = **3 ops**，所以 ~3,333 条消息/天就打满
- 付费 Workers Paid（$5/月）才有月度 1M ops 含额度 + $0.40/M 超额

### 2.3 `cf-queues-ops-alert-analysis.md §18` 运维承诺已失效

| 原文 | 现状 |
|---|---|
| O-1 `CF Queue 日 ops（稳态）≤ 5,000 / day` | 实际 10,000–13,000 / day |
| O-2 `月度 ops 占 1M 免费额度 ≤ 20%` | 前提错（免费是日度 10k） |
| O-3 `修复后 30 天内告警触发频次 = 0` | 04-23 再次收到每日限额告警，04-24 触发 send() 拒绝 |

原文承诺的"Plan 1 + PR #1341 部署后 ops 降到 2-4k/day"**未达成**，原因：
1. 业务量（AI 调用产生的 MeterEvent）是 ops 总量的主导因素（~85%）
2. PR #1341 只消除了 shim 层 5× 放大（~15% 贡献）
3. 消除 5× 放大后，底量 ~10-13k/day 仍高于 10k 免费线

### 2.4 `exceededResources` 比率恶化，未按预期降到零

| 日期 | 每小时 exceeded | 过载率 |
|---|---|---|
| 2026-04-18 (Plan 1 刚上线) | 12 | 13% |
| 2026-04-20 14:00 起（突变） | 60 | 上升 |
| **2026-04-23 稳态** | **60** | **42.2%**（success 1,991 / exceeded 1,451） |
| 2026-04-24 部署前 | 60 | ~37% |

`payment-kit-platform-analysis-2026-04-20.md` §1.1 预期 "Phase 1 后 <5%" 未达成。现实是 `runAllScheduledJobs` 每分钟对 16 队列做 32 次串行 D1 RTT，总计约 2s wall-time，稳定踩 CF scheduled handler 时长上限。Plan 8（见 §3）是针对此问题的修复。

---

## 3. 部署记录（2026-04-24）

### 3.1 Plan 8 + Plan 13 组合部署

| 项目 | 值 |
|---|---|
| 部署时间 | **2026-04-24 12:33:43 UTC** |
| Worker Version ID | `4effff8a-1cd0-4006-a2ec-ca88d5be8f46` |
| Deployment ID | `94059fb5-9b18-49f1-912c-bc7311f4183a` |
| 分支 | `fix/plan13-reduce-queue-ops` |
| 包含 commits | `94a7fc33`（Plan 8）+ `d57651e1`（Plan 13）+ `9f1f0ef5`（D1 ctx.waitUntil fix） |
| URL | https://staging-aigne-hub-payment-kit.arcblock.workers.dev |

### 3.2 Plan 8 — `runAllScheduledJobs` D1 查询合并

**文件**：`blocklets/core/cloudflare/shims/queue.ts`

原实现：对 16 个已注册队列串行调用 `getScheduledJobs()` + `getJobs()` = **32 次 D1 round-trip**，每次 50–80ms，总计 1.5–2.1s wall-time。

新实现：单次 `Job.findAll` 跨所有队列（`Op.in` 过滤 queueName，`Op.or` 覆盖"延迟到期 + 立即卡滞"两类），本地按 queueName 分组路由到现有 `dispatchJob`。

**预期影响**：scheduled handler wall-time 2s → <150ms，`exceededResources` 应从 60/h → ~0。

**测试**：`blocklets/core/cloudflare/tests/shims/queue-scheduled.spec.ts` 新增 9 个单测（无队列早退、单次 findAll、按队列分组、异常隔离、WHERE 子句结构校验等）。

### 3.3 Plan 13 — 队列 ops 源头减量

**文件**：`blocklets/core/api/src/queues/payment.ts` + `blocklets/core/api/src/queues/credit-consume.ts`

**改动 A: `startDepositVaultQueue` 合并 N 币种为单条消息**
- 原：N 个启用 vault 的币种 × 288 次 cron/day = **288N writes/day**
- 新：1 条 `{ currencyIds: [...] }` 消息，consumer 内部循环处理，per-currency try/catch 隔离
- 保留 `currencyId?` 与 `currencyIds?` 双兼容字段
- 使用稳定 jobId `deposit-vault-batch`（D1 unique constraint 提供背压）

**改动 B: `startCreditConsumeQueue` 恢复路径按 customer 分组**
- 原：pending MeterEvent 每条 → 1 次 `addCreditConsumptionJob` → 1 条 queue 消息
- 新：按 `(customerId, eventName, subscriptionId)` 分组，多事件组走 `handleBatchCreditConsumption` 批路径
- 单例组保留原逐条路径（失败隔离不变）
- 使用稳定 jobId `batch-credit-recovery-${key}`（与实时 `addToBatch` 共享 batchKey 语义）

**预期影响**（保守/乐观）：
- depositVault writes 节省：假设 N=3 → 1,728 ops/day；N=5 → 3,456 ops/day
- credit 恢复爆发压缩：单次恢复事件节省 270–1,350 ops（取决于 pending 数量）
- 合计：日度 ops 从 10.5k 降到 **6.5–8.8k（保守）/ 4.5k（乐观）**

---

## 4. 部署后 2.5 小时观察

### 4.1 Queue 无法测量（仍在熔断中）
- 今日 06:00 UTC 打满 10,448 ops 后，send() 被 CF 拒绝至今
- 04-25 00:00 UTC 解封后才能看到 Plan 13 效果
- 预计首个完整评估窗口：**2026-04-25 UTC 全日**

### 4.2 `exceededResources` 尚无明显改善
| UTC 时段 | exceeded/h | 相对部署 |
|---|---|---|
| 11:00 | 59 | 部署前 |
| 12:00 | 61 | 部署窗口 |
| 13:00 | 54 | T+0.5h |
| 14:00 | 59 | T+1.5h |
| 15:00（部分） | 10 → 投射 60 | T+2.5h |

Plan 8 预期把 scheduled handler 超时清零，目前看未兑现。可能原因：
- Scheduled 路径还有其他 I/O 瓶颈（如 `flushPendingJobs` 或 `ctx.waitUntil` 内的下游调用）
- 需 wrangler tail 实测日志进一步定位（本地 tail auth 暂时无法用，留待后续）

### 4.3 HTTP 流量自 12:00 UTC 起静默
success 调用：09:00 **2,219** → 10:00 882 → 11:00 214 → 12:00–15:00 **0**

无法判断是正常业务低潮还是 queue 熔断的二级影响（上游 aigne-hub 因 payment-kit 队列失败而停止调用）。

---

## 5. 旧文档勘误对照表

### 5.1 `cf-queues-ops-alert-analysis.md` 勘误

| 位置 | 原文 | 更正 |
|---|---|---|
| §1.1 | "触达免费额度（1,000,000 ops / month）的 95%" | 免费是 10k/day 日度硬顶；95% 告警触发的是"日度阈值"而非"月度" |
| §1.4 预期表 | "PR #1341 完整部署后 2-4k/day" | 实测 11-13k/day；降幅仅 ~15% 而非 80% |
| §1.4 预期表 | "`exceededResources` 趋近 0" | 04-20 14:00 后升至 60/h 稳态；需 Plan 8 另行修复 |
| §4 | "占 1M/month 免费额度 10-15%" | 前提错；实际每日超限 |
| §8.2 | "17 天累计 90k ops → 对 1M/month 免费额度占用 9%" | 前提错；免费是日度 10k |
| §13.2 | "目标 ≤ 3,000/day" | 从未达成；目标下调为 "≤ 10,000/day" 才符合现实约束 |
| §17.2 | "升级付费计划... 根因修完后 ops 在免费额度 10× 以内，不必升级" | 现实每日超 10k，需考虑升级或继续减量 |
| §18.3 O-1 | "CF Queue 日 ops ≤ 5,000/day" | **承诺失效**；当前基线 10-13k |
| §18.3 O-2 | "月度 ops 占 1M 免费额度 ≤ 20%" | **承诺失效**；前提错 |
| §18.3 O-3 | "修复后 30 天内告警 = 0" | **承诺失效**；04-23 再次告警 |
| §21 | Plan 5/6/7/8/9 状态为 pending | Plan 5 已完成；Plan 8 已实施并部署；Plan 13（本文档新增）已部署 |

### 5.2 `payment-kit-platform-analysis-2026-04-20.md` 勘误

| 位置 | 原文 | 更正 |
|---|---|---|
| 总述 | "2-3 周 1 人可完成，账单仍 $5-10/月" | 基线错 —— 账号**未付费**；"$5/月"是升级后的底价，不是当前实际 |
| §1.1 | "`exceededResources` 比率 13%" | 当前 36–42%；Phase 1 完成率 1/8 未整改 |
| §1.4 预期 | "服务端时间 15-18 秒 / `exceededResources` < 5%" | 未兑现（Phase 1 未做完）|
| §3.1 成本表 | 各列基于 $5 付费套餐假设 | 当前未付费；付费后真实月账单详见 §6 |
| §4 Phase 1 清单 | 8 项改动 | 实际完成度：1 (item 7) / 8；item 4 索引 2/3；item 5 代码就绪但配置默认关闭 |
| §4 item 6 | "空数组短路" 标记为"未做" | 复查代码后发现：所有现有 `Op.in + update/destroy` 路径已有 length 守卫；Sequelize 6.37.7 下空数组自带保护。不过防御式编程规则仍建议加 lint |

### 5.3 在两份旧文档顶部各加一行交叉引用（不改原文）

两份文档顶部会加一行 `> [!NOTE] 2026-04-24 更新：本文档部分预期/承诺值已被现实证伪，请先阅读 2026-04-24-queue-ops-followup.md`。

---

## 6. 付费模式下各规模预期月账单（基于真实用量推算）

Workers Paid $5/月含 10M 请求 + 30M CPU-ms + 1M Queue ops + 5B D1 rows read + 50M D1 rows written。超额单价：Queue $0.40/M，Workers $0.30/M，D1 reads $0.001/M（即 $1/B），D1 writes $1/M。

| 用户规模 | Queue ops/月 | D1 rows read/月 | 月账单 |
|---|---|---|---|
| 当前（~100 用户）| 335k | 1.45B | **$5** |
| 1,000 用户 | 3.3M | 14.5B（超 9.5B × $1/B + Queue 超 2.3M × $0.40）| **~$15** |
| 10,000 用户 | 33M | 145B | **~$155**（D1 读为主）|
| 100,000 用户 | 335M | 1.45T | **~$1,500** |

**要点**：D1 rows read 是最大成本随用户规模放大器。Dashboard 预聚合（旧文档 Phase 1 item 8，未做）是长期关键优化。Queue 层优化（Plan 8 + Plan 13）对未来付费账单节省有限，但对当前免费套餐保命必要。

---

## 7. 后续观察计划

| 时间点 | 动作 | 判据 |
|---|---|---|
| **2026-04-25 00:00 UTC** | Queue 配额解封，业务消息恢复写入 | 期望：Plan 13 效果显现，日度 ops <10k |
| 2026-04-25 12:00 UTC（T+24h）| 查 04-25 UTC 全日 ops | 期望：~6.5-8.8k/day |
| 2026-04-26 UTC（T+48h）| 稳态判断 | 期望：稳定在 <10k/day，不再收到 CF 告警 |
| 持续 | 监测 `exceededResources` | 若 48h 后仍 60/h，Plan 8 未解决根因，需独立 PR 深入定位 |

若 T+48h 后仍每天超 10k，需在下列三路径中选一：
- **A**：升级 CF Workers Paid $5/月 —— 立即解决
- **B**：继续压 queue writes（Phase 1 item 8 Dashboard 预聚合 + 订阅 cron 精准化），还能再降 3–5k/day
- **C**：完全去 CF Queue 化，改为纯 D1 + cron 自驱动 —— 1-2 周工程量，性价比差

---

## 8. 相关文档

- `cf-queues-ops-alert-analysis.md` — 2026-04-17 首次告警根因分析（原始 RCA，保留供历史溯源；§18 承诺阈值已部分失效，以本文 §5.1 勘误为准）
- `payment-kit-platform-analysis-2026-04-20.md` — 2026-04-20 平台级评估（Phase 1 建议仍有效，但成本表基于付费套餐假设，以本文 §5.2 勘误为准）

---

## 9. 变更记录

| 日期 | 内容 | 状态 |
|---|---|---|
| 2026-04-24 | 本文档产出；汇总 Plan 8 + Plan 13 部署记录、事实勘误、旧文档对照 | ✅ |
| 2026-04-25 00:00+ UTC | 预计 Queue 配额解封，开始效果验证 | ⏳ |
| 2026-04-26 12:00 UTC | T+48h 稳态评估 | ⏳ |
