限流与上限

各端点的上限一览

公开搜索翻页深度

公开搜索和磁力列表使用 Typesense 页码分页，服务端最多读取 100 页：

• /magnets?page=<n> 会把页码规范化到 1–100；例如 ?page=10000 会重定向到 ?page=100。
• /api/animes/search 的 cursor 只接受 ts_page:<页码>。非法前缀会返回 400 VALIDATION_ERROR；超大页码会被规范化到第 100 页并返回空页或最后一页结果。
• limit 与页码上限是两个独立保护：limit 控制单页大小，cursor / page 控制最多翻到第几页。

过滤模型（/rss/anime.xml）

/rss/anime.xml 由主站 Web runtime 查询 Typesense release index。bgmId、groupSlug、resolution、language、subtitle、format 等过滤会尽量下推到 Typesense；episode / episodeKey 这类展示字段可能在 Web runtime 做小窗口后过滤。不会回源 Convex 扫库。

极冷门组合如果叠加过多过滤，可能返回少于 limit 条；这是索引窗口和性能保护的结果。需要更多历史数据时，优先放宽过滤或按字幕组短链分页式轮询。

提高上限

# 把每 IP 60 秒 120 次提高到 60 秒 600 次
RSS_ANIME_RATE_LIMIT_MAX=600
RSS_GROUP_RATE_LIMIT_MAX=600
RSS_MAGNETS_RATE_LIMIT_MAX=600

# 或者改窗口为 10 秒（变成 120 次 / 10 秒）
RSS_RATE_LIMIT_WINDOW_MS=10000

# 关闭 CDN 边缘缓存（不推荐，仅测试用）
RSS_CACHE_TTL_SECONDS=0

1000 用户场景下的真实负载

核心结论：origin 真实承受的回源率与并发用户数几乎无关，只与 s-maxage 和查询参数多样性有关。

请求流转：

用户 ──► 浏览器 / RSS 客户端缓存 (max-age)
        ──► Cloudflare CDN (s-maxage + SWR)
            ──► origin (TanStack Start Web + Redis) ──► Typesense

• CDN 内未过期 → 0 origin 请求
• CDN 过期但仍在 SWR 窗口 → 用户拿旧版本（0 延迟），origin 收到 1 个异步刷新请求
• 完全过期 → origin 收到 1 个同步请求（~50–200ms 回源）
• 客户端带 If-None-Match → ETag 命中时 origin 仅返回 304（无 body，几乎零开销）

各端点在 1000 用户、客户端默认 15 分钟轮询 假设下的预估负载：

综合：1000 用户全套订阅 + 前端使用，origin 一小时实际承受 < 1000 次请求，其中 90%+ 是 304。SWR 让"用户感知延迟"和"origin 回源压力"完全解耦——回源慢不会拖慢用户。

给客户端的轮询建议

主流 RSS 客户端的实际行为

不同客户端默认的轮询频率、ETag/304 支持差异很大。好消息：本站对所有客户端都返回正确的 ETag + Last-Modified + Cache-Control，符合 HTTP 标准的客户端会自动走 304，你不用做任何配置。

针对场景的预期

• 个人订阅 1–2 个番剧 RSS（NetNewsWire / Inoreader）：每小时 1 个请求，全部 304，origin 几乎感知不到。
• qBittorrent 用 RSS 规则自动下载：每 30 分钟拉一次全量 XML（约 50–200 KB），但因为 CDN 命中，实际打到 origin 也只是 5 分钟一次。
• 公开聚合站（Inoreader / Feedly）：1000 个订阅者后端共享同一份订阅，对 origin 等同 1 个用户。

调优建议

• 用 Inoreader / Feedly / NetNewsWire iCloud 这类支持云端聚合的客户端 → 你和其他用户共享缓存
• qBittorrent / Transmission 直接拉的话，把规则间隔调到 ≥ 15 分钟（默认 30 分钟也很合理）
• 自建脚本必须实现 If-None-Match 复用，否则等于浪费带宽

后端发布 → 用户看到的完整延迟拆解

以"字幕组发布一个新种子"到"订阅者的 RSS 客户端弹出通知"为例，逐段算一遍最坏情况：

T=0       字幕组提交 release 到 AniBT Web API
          (Web 解析请求体 / 种子，Convex mutation 写入 releases / files 表)
T=0       数据库立即可读（Convex 强一致）
          Web 写侧事件会触发外部 Worker 清 Redis RSS cache + purge CDN

T≤120s    事件 purge 缺失时的兜底 CDN / Web Redis 短缓存窗口内：
          客户端请求被 CDN 拦截，仍拿旧版本
          → 这一段是用户感知延迟的主要来源

T=120s    CDN 缓存进入 SWR 期：
          下一个用户请求触发 CDN 异步回源
          原 origin 拿到新数据 → CDN 缓存更新

T=120~300s 客户端的下次轮询周期（取决于客户端）：
          - 若客户端轮询间隔 = 5min → 最快下一次拿到新版本
          - 若间隔 = 15min → 平均再等 7.5 min
          - 若间隔 = 1h → 平均再等 30 min

典型场景的端到端延迟（中位数）

优化哪一段最有效

1. 缩短客户端轮询间隔（最有效）：从 1h 改成 5min，立刻把延迟从 30min 砍到 5min。
2. 缩短 s-maxage（次要）：从 300s 改成 60s，origin 压力涨 5 倍但用户延迟只少 4 分钟，性价比低。
3. 强制 origin 立即推送（不可行）：HTTP RSS 是 pull 模型，没办法。