feat(storage): migrate config, dedup and delivery state to D1

- Move oversized queue payloads from KV to R2 (PAYLOAD binding, webhooks/YYYY/MM/DD/*.json, KV queue:payload:* fallback) - Persist routes/groups to D1 (d1_routes/d1_groups) with memory -> KV -> D1 three-tier cache, seeded from legacy KV config keys - Move webhook dedup (dedup_keys), delivery state (delivery_state) and message tracking (message_tracking) to D1 via canUseD1 probe with automatic KV fallback - Batch send_logs inserts (recordSendBatch) and add group_id/ts index - Add storage-prune scheduled task for expired dedup/state/tracking rows - Add TTL to invite:group:{id} index and audit all ephemeral KV keys - Add D1 indexes for the new tables - Sync AGENTS.md, README.md/zh and docs/ (en/zh) with the new storage layout
2026-09-22 16:11:29 +00:00 · 2026-08-17 15:01:20 +08:00 · 2026-08-17 15:01:20 +08:00 · 25ebae4ae5
commit 25ebae4ae5
parent 2e1b0f022e
46 changed files with 1450 additions and 117 deletions
--- a/docs/zh/api/admin.md
+++ b/docs/zh/api/admin.md
@ -34,7 +34,7 @@

 ## 校验

- `PUT /admin/api/routes` — 请求体为 `{ "routes": Route[] }`；校验每条路由（id 格式、组内唯一 id、name、enabled、groupId、过滤器——**仅 `fallback` 路由允许空过滤器**——可选的 `discordRoleIds`（身份组 id 字符串列表）、平台感知的 targets：Discord 需 `target.channelId`，Telegram 需 `target.chatId`）并持久化到 KV `config:routes`。返回 `200 { ok, count }` 或 `400 { error }` / `401 { error }` / `403 { error }`。未变更的路由跳过完整校验。
+- `PUT /admin/api/routes` — 请求体为 `{ "routes": Route[] }`；校验每条路由（id 格式、组内唯一 id、name、enabled、groupId、过滤器——**仅 `fallback` 路由允许空过滤器**——可选的 `discordRoleIds`（身份组 id 字符串列表）、平台感知的 targets：Discord 需 `target.channelId`，Telegram 需 `target.chatId`）并持久化到 D1 `d1_routes`。返回 `200 { ok, count }` 或 `400 { error }` / `401 { error }` / `403 { error }`。未变更的路由跳过完整校验。
 - `PUT /admin/api/groups` — 校验分组 id、成员角色（至少一个 `owner`）、`providers`（`github` / `gitea`）与 `installationId`。
 - 上限：每个实例最多 200 条路由与 100 个分组。

--- a/docs/zh/guide/configuration.md
+++ b/docs/zh/guide/configuration.md
@ -59,7 +59,7 @@ WebHooker 在 `/admin` 提供内置配置控制台，可在浏览器中管理路

 控制台以 SPA 形式在 `/admin` 提供；其标签页可通过 URL 路径直达（`/admin/groups`、`/admin/logs`、`/admin/audit`）。`/admin` 之外未匹配到端点的 URL 直接返回 `404`，而不会展示控制台。

-所有管理端点（`/admin/api/*`）见 [Admin API](../api/admin)。保存的路由会立即写入 KV `config:routes` 并使配置缓存失效，下一次 webhook 处理即会生效。
+所有管理端点（`/admin/api/*`）见 [Admin API](../api/admin)。保存的路由和分组会立即持久化到 D1（`d1_routes` / `d1_groups`），并使 KV 缓存失效、刷新配置缓存，下一次 webhook 处理即会生效。

 ## 过滤器类型

--- a/docs/zh/guide/deployment.md
+++ b/docs/zh/guide/deployment.md
@ -81,11 +81,24 @@ bunx wrangler d1 execute webhooker --remote --file ./migrations/0002_log_detail.
 bunx wrangler d1 execute webhooker --remote --file ./migrations/0003_telegram_links.sql
 bunx wrangler d1 execute webhooker --remote --file ./migrations/0004_add_group_id.sql
 bunx wrangler d1 execute webhooker --remote --file ./migrations/0005_audit_logs.sql
+bunx wrangler d1 execute webhooker --remote --file ./migrations/0006_config_d1.sql
+bunx wrangler d1 execute webhooker --remote --file ./migrations/0007_send_logs_index.sql
+bunx wrangler d1 execute webhooker --remote --file ./migrations/0008_storage_d1.sql
 ```

 :::

-### 4. 创建队列（可选）
+### 4. 创建 R2 Bucket（可选）
+
+`PAYLOAD` 绑定将超大 webhook 负载暂存在 R2（`webhooker-payloads`）而非 KV。未设置时，超大负载回退到 KV 键 `queue:payload:*`。布局见[存储](/zh/guide/storage)。
+
+```bash
+bunx wrangler r2 bucket create webhooker-payloads
+```
+
+bucket 已在 `wrangler.jsonc` 中声明（`r2_buckets`），无需修改绑定。
+
+### 5. 创建队列（可选）

 `QUEUE` 绑定会通过 Cloudflare Queues 投递 webhook（异步分发，带重试退避与死信队列）。跳过此步则保持同步内联分发。

@ -96,7 +109,7 @@ bunx wrangler queues create webhooker-delivery-dlq

 队列已在 `wrangler.jsonc` 中声明（`queues.producers` / `queues.consumers`），无需修改绑定。`webhooker-delivery` 消费者对可重试失败做指数退避重试（5s/30s/2m/10m），达到 `max_retries` 后消息进入 `webhooker-delivery-dlq` 并标记为 dead。

-### 5. 部署
+### 6. 部署

 ```bash
 bunx wrangler deploy
@ -104,13 +117,13 @@ bunx wrangler deploy

 Worker 现在可通过 `https://webhooker.<your-subdomain>.workers.dev` 访问。

-### 6. 配置 GitHub Webhook
+### 7. 配置 GitHub Webhook

 1. 进入 GitHub App 设置页面
 2. 设置 **Webhook URL** 为 `https://webhooker.<your-subdomain>.workers.dev/webhook`
 3. 设置 **Webhook secret** 与 `GITHUB_WEBHOOK_SECRET` 一致

-### 7.（可选）配置 Gitea Webhook
+### 8.（可选）配置 Gitea Webhook

 1. 在 Gitea 仓库中进入 **设置 → Web 钩子 → 添加 Web 钩子 → Gitea**
 2. 设置 **目标 URL** 为 `https://webhooker.<your-subdomain>.workers.dev/webhook`
--- a/docs/zh/guide/faq.md
+++ b/docs/zh/guide/faq.md
@ -34,4 +34,4 @@

 ## 数据存储在哪里？

-配置存于 Cloudflare KV（`config:routes`、`config:groups`）；发送/审计日志与平台↔GitHub 绑定存于 D1。见[存储布局](./storage#kv-存储布局)。
+配置存于 D1（`d1_routes`/`d1_groups`，KV 仅作缓存）；webhook 去重、投递状态与消息更新追踪同样存于 D1（KV 回退）；发送/审计日志与平台↔GitHub 绑定存于 D1；超大负载可选存于 R2。见[存储布局](./storage#存储决策)。
--- a/docs/zh/guide/groups.md
+++ b/docs/zh/guide/groups.md
@ -1,6 +1,6 @@
 # 分组与访问控制

-路由归属于分组。分组用于划分管理权限，并可限制进入其中的事件。它们以 JSON 数组形式存储在 Cloudflare KV 的 `config:groups` 键下，可通过 [Web 控制台](./configuration#web-控制台)或 [Admin API](../api/admin) 管理。每个实例最多可保存 **100 个分组**。
+路由归属于分组。分组用于划分管理权限，并可限制进入其中的事件。它们存储在 D1（`d1_groups`，首次加载时从旧版 KV `config:groups` 键同步），可通过 [Web 控制台](./configuration#web-控制台)或 [Admin API](../api/admin) 管理。每个实例最多可保存 **100 个分组**。

 ## 分组模式

--- a/docs/zh/guide/introduction.md
+++ b/docs/zh/guide/introduction.md
@ -22,14 +22,14 @@ GitHub / Gitea Webhook → Cloudflare Worker (Nuxt 4 / Nitro)
 | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **Cloudflare Worker**     | HTTP 入口、签名验证、投递去重、事件解析、路由匹配、平台分发                                                                                                     |
 | **Interactions Endpoint** | 验证 Ed25519 签名并处理 `/gh` 交互（斜杠命令、右键菜单、按钮、modal）                                                                                           |
-| **KV**                    | Token 存储 (`token:{userId}`)、OAuth 状态 (`state:{hex}`)、路由配置 (`config:routes`)、分组配置 (`config:groups`)、管理员会话、投递去重、消息更新追踪 (`msg:*`) |
-| **D1**                    | 发送日志 (`send_logs`)、Discord↔GitHub 绑定 (`discord_links`)、Telegram↔GitHub 绑定 (`telegram_links`)                                                          |
+| **KV**                    | Token 存储 (`token:{userId}`)、OAuth 状态 (`state:{hex}`)、管理员会话、分组级 secret、配置缓存、投递去重/投递状态/消息更新追踪的回退（`delivery:*`、`delivery-state:*`、`msg:*`，仅在 D1 不可用时使用）、消息更新锁 (`msg:lock:*`) |
+| **D1**                    | 路由/分组 (`d1_routes`/`d1_groups`)、发送日志 (`send_logs`)、审计日志 (`audit_logs`)、去重 (`dedup_keys`)、投递状态 (`delivery_state`)、消息追踪 (`message_tracking`)、Discord↔GitHub 绑定 (`discord_links`)、Telegram↔GitHub 绑定 (`telegram_links`)，超大负载可选的 R2 存储 |

 ### 数据流

 1. 某个 forge（GitHub 或 Gitea）发送 webhook 到 `POST /webhook`
 2. Worker 根据请求头识别提供方（`X-GitHub-Event` / `X-Gitea-Event`）并验证对应提供的 HMAC-SHA256 签名
-3. Worker 按投递 ID 去重（KV，短 TTL），丢弃重复投递
+3. Worker 按投递 ID 去重（D1，短 TTL，KV 回退），丢弃重复投递
 4. Worker 解析事件类型并将载荷归一化为 GitHub 形状的事件
 5. 根据过滤器（event、repo、actor、action、branch、keyword）与分组所有者限制评估路由
 6. 匹配的路由触发格式化器函数生成平台中立消息
@ -42,7 +42,7 @@ GitHub / Gitea Webhook → Cloudflare Worker (Nuxt 4 / Nitro)
 - **Discord 投递**: Discord REST API（交互通过 Ed25519 验签的 HTTPS Interactions Endpoint）
 - **Telegram 投递**: Telegram Bot API（webhook 带可选 secret-token 校验）
 - **Web UI**: Nuxt 4（Vue 3 + Tailwind CSS v3）——首页/法律页面服务端渲染，`/admin` 控制台客户端渲染
- **存储**: Cloudflare KV + D1
+- **存储**: Cloudflare D1（配置与日志权威）+ KV（缓存/临时状态）+ 可选 R2（超大负载）
 - **鉴权**: Web Crypto API (HMAC-SHA256、Ed25519)、octokit (GitHub API)
 - **语言**: TypeScript

--- a/docs/zh/guide/routes.md
+++ b/docs/zh/guide/routes.md
@ -1,6 +1,6 @@
 # 路由与目标

-路由决定哪些事件被转发到哪个频道（Discord 或 Telegram）。它们以 JSON 数组形式存储在 Cloudflare KV 的 `config:routes` 键下，可通过 [Web 控制台](./configuration#web-控制台)、[Admin API](../api/admin) 或 `config.example.yaml` 管理。
+路由决定哪些事件被转发到哪个频道（Discord 或 Telegram）。它们存储在 D1（`d1_routes`，首次加载时从旧版 KV `config:routes` 键同步），可通过 [Web 控制台](./configuration#web-控制台)、[Admin API](../api/admin) 或 `config.example.yaml` 管理。

 **没有默认路由**——每条路由都必须定义自己的目标。未配置任何路由时不会转发任何事件。每个实例最多可保存 **200 条路由**。

--- a/docs/zh/guide/storage.md
+++ b/docs/zh/guide/storage.md
@ -2,22 +2,24 @@

 ## KV 存储布局

+KV 只保留缓存数据和短期/临时状态。高频写入（webhook 去重、投递状态、消息追踪）存放在 D1，仅在 D1 不可用或未迁移时才回退到 KV（见[存储决策](#存储决策)）。
+
 | 键模式                                     | 值                                                                            | TTL                |
 | ------------------------------------------ | ----------------------------------------------------------------------------- | ------------------ |
-| `config:routes`                            | 路由 JSON 数组                                                                | 永久               |
-| `config:groups`                            | 分组 JSON 数组                                                                | 永久               |
+| `config:routes`                            | 路由配置缓存（D1 `d1_routes` 为权威数据源）                                   | 1 小时             |
+| `config:groups`                            | 分组配置缓存（D1 `d1_groups` 为权威数据源）                                   | 1 小时             |
 | `session:{id}`                             | 管理员会话 `{ userId, login }`                                                | 7 天               |
 | `token:{userId}`                           | `{ userId, accessToken, expiresAt, refreshToken? }`                           | 0.9 × Token 有效期 |
 | `token-reverse:{sha256}`                   | 用于按 Token 反查的用户 id                                                    | 0.9 × Token 有效期 |
 | `state:{hex}`                              | `{ redirectTo, expiresAt, discordUserId?, telegramUserId?, telegramChatId? }` | 600 秒             |
 | `invite:{token}`                           | `{ groupId, role, expiresAt, createdBy, note? }`                              | 7 天               |
-| `invite:group:{id}`                        | 每组的 Token 索引（保证邀请列表一致性）                                       | 永久               |
-| `delivery:{provider}:{groupId}:{id}`       | Webhook 投递去重（按 provider 与租户隔离）                                    | 300 秒             |
-| `delivery-state:{provider}:{groupId}:{id}` | 队列投递状态（`pending`/`processing`/`delivered`/`retrying`/`failed`/`dead`） | 1 天               |
-| `queue:payload:{provider}:{groupId}:{id}`  | 暂存供队列消费者读取的超大 webhook 负载                                       | 1 天               |
+| `invite:group:{id}`                        | 每组的 Token 索引（保证邀请列表一致性）                                       | 7 天               |
+| `delivery:{provider}:{groupId}:{id}`       | Webhook 投递去重回退（D1 `dedup_keys` 为主）                                  | 7 天               |
+| `delivery-state:{provider}:{groupId}:{id}` | 队列投递状态回退（D1 `delivery_state` 为主）                                  | 1 小时             |
+| `queue:payload:{provider}:{groupId}:{id}`  | 暂存供队列消费者读取的超大 webhook 负载（R2 为主）                            | 1 小时             |
 | `nonce:{nonce}`                            | 自定义 webhook 重放防护 nonce（一次性）                                       | 600 秒             |
 | `tenant:{groupId}`                         | 分组 webhook secret（64 位 hex，控制台生成）                                  | 永久               |
-| `msg:{routeId}:{key}:{target}`             | 原地更新用消息 id 追踪（如 `workflow_run` / `check_run`）                     | 7 天               |
+| `msg:{routeId}:{key}:{target}`             | 消息 id 追踪回退（D1 `message_tracking` 为主）                                | 1 天               |
 | `cmd:guild:{id}`                           | 已注册命令的服务器 id（去重）                                                 | 永久               |
 | `cmd:registered:global`                    | 全局命令注册标记（去重）                                                      | 1 天               |
 | `config:discord-app-id`                    | 缓存的 Discord 应用 id                                                        | 永久               |
@ -25,13 +27,35 @@

 ## D1 存储布局

-D1 数据库（`DB` 绑定，数据库 `webhooker`）包含四张表：
+D1 数据库（`DB` 绑定，数据库 `webhooker`）保存配置、投递日志和高频临时状态的权威数据源：

-| 表               | 用途                                                                   |
-| ---------------- | ---------------------------------------------------------------------- |
-| `send_logs`      | 每次分发尝试一行（路由 id、事件、目标、ok/error、耗时、错误码、详情）  |
-| `audit_logs`     | 每次管理员操作一行（登录/登出、分组/路由/成员/邀请变更）               |
-| `discord_links`  | 映射 `discord_user_id` → `github_user_id`，供 `/gh` Discord 命令使用   |
-| `telegram_links` | 映射 `telegram_user_id` → `github_user_id`，供 `/gh` Telegram 命令使用 |
+| 表                 | 用途                                                                   |
+| ------------------ | ---------------------------------------------------------------------- |
+| `d1_groups`        | 分组（权威配置，从旧版 KV `config:groups` 播种）                        |
+| `d1_routes`        | 每组分组的路由（权威配置，从旧版 KV `config:routes` 播种）               |
+| `send_logs`        | 每次分发尝试一行（路由 id、事件、目标、ok/error、耗时、错误码、详情）  |
+| `audit_logs`       | 每次管理员操作一行（登录/登出、分组/路由/成员/邀请变更）               |
+| `dedup_keys`       | Webhook 投递去重（原子 `INSERT ... ON CONFLICT` UPSERT，键 + 过期时间）  |
+| `delivery_state`   | 队列投递状态（`pending`/`processing`/`delivered`/`retrying`/`failed`/`dead`） |
+| `message_tracking` | 原地更新用消息 id 追踪（`event_id` + `target_id` → `message_id`）       |
+| `discord_links`    | 映射 `discord_user_id` → `github_user_id`，供 `/gh` Discord 命令使用   |
+| `telegram_links`   | 映射 `telegram_user_id` → `github_user_id`，供 `/gh` Telegram 命令使用 |

-`audit_logs` 由定时任务在 `AUDIT_RETENTION_DAYS`（默认 90）后自动清理。行字段说明见[日志](./logs)。
+`audit_logs` 由定时任务在 `AUDIT_RETENTION_DAYS`（默认 90）后自动清理。`storage-prune` 任务会清理过期的 `dedup_keys`、超过 7 天的 `delivery_state` 行以及超过 30 天的 `message_tracking` 行。日志行字段说明见[日志](./logs)。
+
+## R2 存储布局
+
+R2（`PAYLOAD` 绑定，bucket `webhooker-payloads`）存储对队列消息或 KV 来说过大的 webhook 负载：
+
+| 对象模式                        | 用途                                            | 保留期       |
+| ------------------------------- | ----------------------------------------------- | ------------ |
+| `webhooks/YYYY/MM/DD/<uuid>.json` | 暂存供队列消费者读取的超大负载                    | 分发后删除   |
+
+当缺少 `PAYLOAD` 绑定时，超大负载回退到 KV 键 `queue:payload:{provider}:{groupId}:{id}`（1 小时 TTL）。
+
+## 存储决策
+
+- **D1 是配置与投递元数据的权威数据源**；KV 只保存缓存和短期状态。
+- `canUseD1` 探测（`server/lib/storage/d1.ts`，检查 `prepare` + `batch`）为每个 D1 存储做门槛判定：当 D1 不可用或尚未迁移时，三种高频存储（去重、投递状态、消息追踪）都会透明回退到 KV，迁移期间行为不变。
+- 这让 Workers 免费版的每事件 KV 写入趋近于零（每日 1000 次写）：去重、投递状态和消息追踪改为写 D1 行（D1 免费版每日可写 10 万行）。
+- R2 免费额度（10 GB-月存储、每月 100 万次 A 类操作）可以轻松承载负载暂存，不占用 KV 写配额。
--- a/docs/zh/guide/tasks.md
+++ b/docs/zh/guide/tasks.md
@ -1,11 +1,12 @@
 # 定时任务

-WebHooker 通过定时触发器（`*/5 * * * *`，每 5 分钟）运行三个维护任务。它们只在部署后的 Worker 上运行（Cloudflare cron）；本地 `wrangler dev` 可用 `wrangler dev --test-scheduled` 触发。
+WebHooker 通过定时触发器（`*/5 * * * *`，每 5 分钟）运行四个维护任务。它们只在部署后的 Worker 上运行（Cloudflare cron）；本地 `wrangler dev` 可用 `wrangler dev --test-scheduled` 触发。

 | 任务            | 用途                                                                                                                |
 | --------------- | ------------------------------------------------------------------------------------------------------------------- |
 | `discord-sync`  | 注册 Discord 斜杠/右键菜单命令：按服务器即时注册，并全局注册（24h 去重，约 1 小时传播）                             |
 | `telegram-sync` | 调用 `setWebhook` 指向 `{BASE_URL}/telegram/webhook`（设置了 `TELEGRAM_WEBHOOK_SECRET` 时作为 `secret_token` 传入） |
 | `audit-prune`   | 删除早于 `AUDIT_RETENTION_DAYS`（默认 90）天的 `audit_logs` 记录                                                    |
+| `storage-prune` | 删除已过期的 `dedup_keys` 记录、超过 7 天的 `delivery_state` 记录和超过 30 天的 `message_tracking` 记录              |

 除任务用到的密钥（`DISCORD_TOKEN`、`DISCORD_APPLICATION_ID`、`TELEGRAM_TOKEN`、`BASE_URL`、`AUDIT_RETENTION_DAYS`）外无需其他配置。