ai-chatbot/AI生图平台桶缓存落地对接清单.md

AI 生图平台桶缓存落地对接清单

交付对象：AI 生图平台负责人 当前主接口域名：https://sc.jiansun.vip 当前资源主域名：https://s3.jiansun.vip 备用资源域名：https://s3.yydd.ai 文档时间：2026-03-18

1. 这次要做的事情

计划把新入口服务器 180.97.215.57 上独立数据盘中的 180G 空间，用作 AI 生图平台相关资源的读取缓存。

这件事的目标是：

• 提升 AI 生图平台读取图片资源时的稳定性
• 降低反复回源到生产机的压力
• 让热点资源第二次及之后访问更快

2. 这次不会变的东西

下面这些默认都不变：

• 桶本体位置不变，真实存储仍在生产机 192.168.58.20:9000
• AI 生图平台的接口入口仍然是 https://sc.jiansun.vip
• 对外资源主域名仍然是 https://s3.jiansun.vip
• https://s3.yydd.ai 先保留为备用域名，不作为默认对接地址
• 这次做的是“读缓存”，不是改上传链路，也不是迁桶

一句话说清楚：

缓存只是在入口服务器上多放一份“最近常用内容的副本”，不是把桶搬走。

3. 当前已经确认的事实

当前资源入口链路是：

s3.jiansun.vip
  -> 180.97.215.57
  -> nginx 磁盘缓存
  -> 127.0.0.1:29000
  -> FRP
  -> 192.168.58.20:9000

当前缓存盘配置已经到位：

• 缓存目录：/data/nginx-cache/s3
• 缓存上限：180g
• 当前入口机资源盘：/data，总容量约 200G

2026-03-18 实测真实桶链路时，使用了一个约 145MB 的真实桶对象做下载测试：

• 直回源 127.0.0.1:29000：约 23.2 MB/s
• 走 https://s3.jiansun.vip 第一次请求：X-Cache-Status: MISS，约 22.7 MB/s
• 同一个 URL 第二次请求：X-Cache-Status: HIT，约 63.2 MB/s

这说明：

• 首次访问主要受回源链路影响
• 命中缓存后，速度会明显提升

基于当前已验证结果，可以先明确 3 个结论：

• 这套 180G 读缓存方案本身是可行的
• 它适合承接 AI 生图平台里“会被重复访问”的热点资源
• 在不改业务入口、不迁桶的前提下，就可以先做灰度验证

4. 我还需要 AI 生图平台这边提供什么

为了把这 180G 真正用于 AI 生图平台的热点流量，而不是“缓存了一堆不重要的文件”，还需要下面这些信息。

4.1 需要确认的资源范围

请提供：

• AI 生图平台当前实际会读取的资源类型
• 这些资源对应的 URL 样例
• 最常访问的路径前缀

最好直接给：

• 近 3 天最常访问的 20 个资源 URL 样例
• 主要路径前缀清单

例如是否主要集中在：

• 生图输入参考图
• 生图结果图
• 放大图、变体图、蒙版图、压缩包等固定路径前缀

4.2 需要确认是否只使用一个主资源域名

这个点非常关键。

请确认：

• AI 生图平台后续是否统一只读 https://s3.jiansun.vip
• https://s3.yydd.ai 是否只作为备用 / 回切，不参与日常默认调用

推荐口径：

• 主用：https://s3.jiansun.vip
• 备用：https://s3.yydd.ai

如果两个域名同时长期对外使用，那么同一份内容就可能同时出现两个公网 URL。

4.3 需要确认文件是否“同 key 覆盖”

这个点决定缓存能不能放心加大。

请确认：

• 同一张图后续会不会“覆盖原来的对象 key”
• 还是每次生成新图都使用新文件名 / 新路径

最推荐的方式是：

• 新内容永远用新 key

比如：

• image-20260318-001.png
• image-20260318-002.png

不推荐的方式是：

• 总是写回同一个 URL

比如始终覆盖：

• latest.png

原因很简单：

• 如果同一个 URL 对应的文件内容被覆盖了，缓存里可能暂时还是旧版本
• 这样就会出现“URL 没变，但内容短时间还是旧图”的情况

4.4 需要确认时效要求

请确认：

• 图片更新后，允许多久内出现旧图
• 删除后，是否允许短时间还能访问
• 是否存在“必须秒级生效”的路径

如果某些资源要求非常高的实时性，就不能和普通静态资源用完全同一套缓存策略。

4.5 需要确认流量规模

请提供一个大致量级即可，不需要特别精确。

需要知道：

• 峰值并发大概多少
• 每分钟 / 每小时大概多少请求
• 热门图片是否会被大量重复读取
• 单张图通常多大
• 是否有明显的突发高峰时段

4.6 需要一批联调样本

请提供：

• 5 到 10 个真实可访问的 AI 生图平台资源 URL
• 最好覆盖“结果图 / 参考图 / 较大文件”几类

这样我可以直接按真实资源做灰度验证，而不是拿不相关对象代替。

4.7 这次不需要 AI 生图平台配合改的内容

为了避免沟通误差，这里也明确一下当前不要求你们先改的东西：

• 不要求先改接口域名，接口仍然走 https://sc.jiansun.vip
• 不要求先迁桶，桶本体仍然在 192.168.58.20:9000
• 不要求先切到 s3.yydd.ai
• 不要求先改上传链路

这次优先要拿到的是“真实读流量信息”，不是让业务先大改。

5. 对正常使用有没有影响

正常情况下，对用户是无感的。

前提是满足下面两个条件：

• 对外主资源域名统一使用 https://s3.jiansun.vip
• 资源尽量使用“新内容新 key”的方式，不要反复覆盖同一个 URL

只要做到这两点，缓存的效果就是：

• 第一次访问走回源
• 后续重复访问直接命中入口缓存
• 用户看到的还是同一个公网 URL

6. 会不会出现“同一张图两个 URL”

情况 1：缓存本身

不会。

缓存不会凭空再生成一个给用户使用的新 URL。

用户访问的仍然是原来的公网地址，比如：

https://s3.jiansun.vip/xxx.png

缓存只是入口服务器内部把这个 URL 对应的内容存到磁盘里。

也就是说：

• 对用户看到的 URL 不变
• 对程序调用的 URL 不变
• 只是入口机内部多了一份缓存文件

情况 2：两个域名同时都在用

会。

如果下面两个地址同时长期对外使用：

• https://s3.jiansun.vip/xxx.png
• https://s3.yydd.ai/xxx.png

那么从“公网 URL”角度看，就是两条 URL 指向了同一份内容。

所以当前建议非常明确：

• s3.jiansun.vip 主用
• s3.yydd.ai 备用

不要两个一起作为默认入口使用。

7. 会不会出现“缓存里一张图，桶里又是另一个 URL”

从用户角度看，不会多出一个可见 URL。

但有一个需要特别注意的现实问题：

如果同一个 URL 被反复覆盖内容

那么就可能出现：

• 桶里已经是新图
• 缓存里短时间还是旧图

这时候不是“两个 URL”，而是：

• 同一个 URL，在不同时间点可能先返回旧内容，再返回新内容

这也是为什么我强烈建议：

• 新图使用新 key
• 不要反复覆盖同一个对象地址

如果业务上确实必须覆盖同一个 URL，那就必须额外做：

• 清缓存机制
• 或单独降低这类路径的缓存时间

8. 推荐的最终口径

建议 AI 生图平台后续按下面这套规则执行：

域名规则

• 主用资源域名：https://s3.jiansun.vip
• 备用资源域名：https://s3.yydd.ai

URL 规则

• 对外只认主域名，不混用两个资源域名
• 新内容尽量使用新 key，不覆盖老 key

缓存规则

• 把 AI 生图平台的热点读流量优先收敛到 s3.jiansun.vip
• 入口机 180G 只做读缓存，不改桶本体位置

9. 现在就可以推进的下一步

如果 AI 生图平台负责人能补齐下面 4 项，我就可以继续往下收口：

1. 确认主用资源域名是否统一为 s3.jiansun.vip
2. 提供 AI 生图平台真实会读取的路径前缀或 URL 样例
3. 明确是否存在“同 key 覆盖”
4. 提供一组真实联调 URL 用于灰度测试

拿到这些信息后，我这边会继续做：

1. 按真实热点路径确认是否需要“分路径缓存策略”
2. 区分哪些资源适合长缓存，哪些资源要短缓存
3. 如果存在“同 key 覆盖”，评估是否需要补清缓存机制
4. 用真实 URL 做灰度验证，再决定是否正式放量

10. 建议负责人直接按下面模板回复

为了节省来回沟通时间，建议 AI 生图平台负责人直接按这个格式回：

1. 主用资源域名：
   例如：统一使用 https://s3.jiansun.vip

2. 是否保留备用域名：
   例如：保留 https://s3.yydd.ai，仅用于备用，不作为默认入口

3. 主要读取的资源类型：
   例如：生图结果图、参考图、放大图、变体图、压缩包

4. 主要路径前缀或 URL 样例：
   例如：/gongxiangpan/ai-output/... 或 /gongxiangpan/ai-input/...

5. 是否存在同 key 覆盖：
   例如：有 / 没有

6. 时效要求：
   例如：更新后允许 5 分钟内旧图；某些路径要求秒级生效

7. 流量规模：
   例如：高峰每分钟约多少次读取，热门图片是否会被重复访问

8. 联调样本：
   例如：提供 5 到 10 个真实可访问 URL

---

如果只要一句最短版本，可以直接转给对方：

这次不是迁桶，只是在 180.97.215.57 上给 s3.jiansun.vip 做 180G 读缓存。要继续推进，需要 AI 生图平台确认主用域名、真实热点路径、是否会覆盖同一 URL、以及给一组联调样本。只要统一用一个主域名，并尽量做到新内容新 key，缓存对用户基本无感，也不会凭空多出第二个 URL。