lunanting/ai-chatbot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ai-chatbot/docs/AI生图平台桶缓存落地补充回复-基于近期日志.md
Your Name fe8a8564e7
Some checks failed
Lint / build (20) (push) Has been cancelled
Details
Playwright Tests / test (push) Has been cancelled
Details
Update agent visibility fixes and local docs
2026-03-21 02:01:56 +08:00

11 KiB
Raw Permalink Blame History

AI生图平台桶缓存落地补充回复（基于近期日志与项目现状）

1. 说明

这份补充回复用于回应对方最新提出的 5 个信息项，信息来源分为两类：

  • 项目当前代码与存储实现
  • 最近 3 天业务侧可观测日志样本

需要特别说明：

  • 下面的“热点路径 / URL 样例 / 请求量级”主要来自应用服务器的 Nginx 日志中，对 /api/image-proxy?url=... 这一类读图请求的观测样本
  • 它可以反映当前业务真实在读哪些桶资源，但不等于资源域名 s3.jiansun.vip 的全量公网访问统计

如果后续要做最终缓存策略定稿，仍建议把资源域名入口侧的 Nginx / 对象存储访问日志也一起纳入。

2. 对最新 5 个问题的直接答复

2.1 主资源域名

我们项目侧的明确口径

建议后续默认统一使用：

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

也就是：

  • https://s3.yydd.ai 不再作为日常默认资源域名写入业务数据库
  • 仅保留为备用访问入口或异常切换入口

但当前线上现状需要说明

从近期应用侧 Nginx 日志样本看，当前仍存在双域名并用现象：

  • s3.jiansun.vip：129 次业务读图样本
  • s3.yydd.ai：182 次业务读图样本

这说明当前历史数据或部分读取链路里，s3.yydd.ai 还没有完全退出。

对缓存落地的建议

建议按下面方式收敛：

  1. 从现在开始，业务默认只写入 https://s3.jiansun.vip
  2. https://s3.yydd.ai 仅保留备用，不再作为默认返回 URL
  3. 后续再分阶段清理历史数据库 / 消息 / 画布中遗留的 s3.yydd.ai 资源引用

2.2 真实热点路径

当前最明确的热点路径前缀

从项目代码与近期日志样本结合看，当前最明确的热点路径集中在：

/gongxiangpan/uploads/

更具体地说，当前应用侧反复读取的资源普遍是：

https://s3.jiansun.vip/gongxiangpan/uploads/{filename}

或历史残留：

https://s3.yydd.ai/gongxiangpan/uploads/{filename}

为什么判断它是热点

因为项目当前所有这类资源会被反复用于：

  • 聊天消息回放
  • 相册页查看
  • 无限画布节点回显
  • AI详情生成后的详情图回读
  • 图片编辑工作流中的二次引用

近期日志里观测到的热点对象样本

按“去掉尺寸参数后的基础对象 URL”聚合，近期样本里重复读取较多的对象包括：

  1. https://s3.jiansun.vip/gongxiangpan/uploads/1773846370425-vkah9g.png，样本中出现 18 次
  2. https://s3.jiansun.vip/gongxiangpan/uploads/1773846444732-r8bzni.jpg，样本中出现 17 次
  3. https://s3.jiansun.vip/gongxiangpan/uploads/1773847125480-d8y8sq.png，样本中出现 11 次
  4. https://s3.jiansun.vip/gongxiangpan/uploads/1773846185500-0rpjwm.png，样本中出现 10 次

历史备用域名上的热点对象也能看到：

  1. https://s3.yydd.ai/gongxiangpan/uploads/1771897462521-toeu12.jpg，样本中出现 9 次
  2. https://s3.yydd.ai/gongxiangpan/uploads/1771897607531-fm9w05.png，样本中出现 9 次

当前业务实际读取形态

当前大量读取不是直接浏览器裸读对象 URL，而是经由：

/api/image-proxy?url=https://s3.jiansun.vip/gongxiangpan/uploads/...

并附带不同渲染尺寸参数，例如：

  • w=64
  • w=720
  • w=756
  • w=758
  • w=960
  • w=1000
  • 个别还有 w=2200

这意味着当前业务访问热点实际上有两层：

  1. 原始对象路径热点：/gongxiangpan/uploads/...
  2. 尺寸变体热点：同一对象会被不同宽度反复请求

2.3 联调样本 URL

下面给出一批近期日志中真实出现过的、可用于联调的对象 URL 样本。

A. s3.jiansun.vip 主域名样本

  1. https://s3.jiansun.vip/gongxiangpan/uploads/1773846370425-vkah9g.png
  2. https://s3.jiansun.vip/gongxiangpan/uploads/1773846444732-r8bzni.jpg
  3. https://s3.jiansun.vip/gongxiangpan/uploads/1773847125480-d8y8sq.png
  4. https://s3.jiansun.vip/gongxiangpan/uploads/1773846185500-0rpjwm.png
  5. https://s3.jiansun.vip/gongxiangpan/uploads/1773846584708-oxjgyr.png
  6. https://s3.jiansun.vip/gongxiangpan/uploads/1773846626436-8lspf3.jpeg
  7. https://s3.jiansun.vip/gongxiangpan/uploads/1773848127368-dw0s0a.png
  8. https://s3.jiansun.vip/gongxiangpan/uploads/1773848264041-2l07om.png
  9. https://s3.jiansun.vip/gongxiangpan/uploads/1773848987321-s19v08.png
  10. https://s3.jiansun.vip/gongxiangpan/uploads/1773849085019-w9cded.jpg

B. s3.yydd.ai 历史残留样本

如果你们需要验证备用域名或历史链路，也可以使用这些样本：

  1. https://s3.yydd.ai/gongxiangpan/uploads/1771897462521-toeu12.jpg
  2. https://s3.yydd.ai/gongxiangpan/uploads/1771897607531-fm9w05.png
  3. https://s3.yydd.ai/gongxiangpan/uploads/1771897836086-4uri8r.jpg
  4. https://s3.yydd.ai/gongxiangpan/uploads/1771897858792-olbfdc.jpg
  5. https://s3.yydd.ai/gongxiangpan/uploads/1771897892910-kjszzi.jpg

C. 样本覆盖说明

这批样本已经覆盖：

  • png
  • jpg
  • jpeg
  • 主域名资源
  • 历史备用域名资源
  • 会被多次重复读取的热点对象

如果你们还需要“明确的大文件样本”，建议再由资源域名入口日志侧补充带原始 Content-Length 的对象清单，因为应用侧日志只能看到尺寸请求，不直接记录对象文件大小。

2.4 是否存在同 key 覆盖

当前项目应用侧结论

当前应用默认链路中，不存在“同 key 覆盖写新内容”的设计。

项目统一上传时，文件 key 规则是：

uploads/{timestamp}-{random}.{ext}

也就是说：

  • 新内容默认新 key
  • 新 URL 默认新对象
  • 这对缓存非常友好

当前项目里没有发现的情况

在当前默认代码路径里，没有发现下面这种模式：

始终覆盖同一个 latest.png / result.png / current.jpg

需要额外说明的边界

如果后续存储层或外部脚本手工做了：

  • 同对象路径覆盖
  • 同 key 重写

那么缓存仍会出现“同 URL 短时间返回旧内容”的风险。

但就项目当前应用代码而言，这不是主流写法。

2.5 时效和流量口径

A. 图片更新后允许旧图保留多久

项目侧真实情况

对当前默认上传链路来说：

  • 因为新内容默认新 key
  • 所以绝大多数图片并不存在“同一个 URL 更新后必须立刻看到新内容”的问题

也就是说：

  • 项目应用侧默认可以接受对象级相对长一点的缓存
  • 因为新图会用新 URL 呈现

项目侧建议口径

对 /gongxiangpan/uploads/ 下这类对象资源，项目侧建议优先按“静态对象”理解，而不是按“频繁同 URL 热更新对象”理解。

B. 是否存在必须秒级生效的路径

当前项目侧结论

就当前应用默认链路来看：

  • 没有发现必须依赖“同一对象 URL 秒级更新生效”的核心路径

需要秒级变化的更多是：

  • 业务页面本身
  • 会话状态
  • 画布数据

而不是上传后的对象 URL 本身。

需要保守处理的例外

如果后续出现人工覆盖对象、后台替换同 URL 内容，那就属于另外一类策略，需要额外补清缓存机制。

C. 峰值请求量级大概多少

当前能给出的项目侧样本

基于最近 3 个日志文件中，对 /api/image-proxy 读取桶对象 URL 的样本统计：

  • 观测到 s3.jiansun.vip 资源样本请求：129
  • 观测到 s3.yydd.ai 资源样本请求：182
  • 两个域名合计样本：311

按分钟聚合，近期样本中可见的高点大约是：

  • 11 req/min
  • 9 req/min
  • 8 req/min

这个量级该怎么理解

这只能算“应用层近期可见样本”，不能等同于资源域名全量公网访问峰值。

但它已经足以说明：

  • 热门资源存在重复读取
  • 资源访问不是纯一次性下载
  • 入口缓存会有实际收益

D. 热门资源是否会被重复读取

明确结论

会，而且已经在日志样本里看到同一对象被重复读取。

例如近期样本中：

  • 单个对象可被重复读取 10-18 次
  • 同一对象还会以不同宽度参数重复请求

这说明缓存非常有价值，尤其适用于：

  • AI详情长图
  • 画布多次回显
  • 聊天结果回看
  • 相册缩略图与大图切换

3. 对缓存策略落地的项目侧建议

基于上面的真实情况，项目侧建议如下：

适合长缓存的路径

优先建议：

  • https://s3.jiansun.vip/gongxiangpan/uploads/*

理由：

  • 默认新内容新 key
  • 热门对象会被重复读取
  • 当前没有应用层同 URL 秒级覆盖诉求

需要保守处理的情况

如果你们后续发现这类链路存在：

  • 人工覆盖对象
  • 通过管理脚本复写原对象
  • 同 URL 替换内容

则这些路径应转为：

  • 短缓存
  • 或配合 purge 机制

当前最重要的动作优先级

  1. 明确主域名收敛到 s3.jiansun.vip
  2. 把 s3.yydd.ai 定位为备用，不再做默认日常入口
  3. 先对 /gongxiangpan/uploads/ 做缓存策略落地
  4. 再根据真实热点对象与尺寸参数情况优化缓存分配

4. 可直接发给对方的简版回复

下面这段可以直接作为对外补充答复：

补充我们项目侧的明确口径如下：

  1. 主资源域名建议统一收敛为 https://s3.jiansun.vip，https://s3.yydd.ai 仅保留为备用 / 回切入口，不再参与默认日常调用。
  2. 结合当前项目代码和最近业务日志样本，热点资源主要集中在 /gongxiangpan/uploads/ 前缀下，且当前业务读取大量表现为 /api/image-proxy?url=https://s3.jiansun.vip/gongxiangpan/uploads/... 这种对对象资源的重复访问。
  3. 当前应用默认采用 uploads/{timestamp}-{random}.{ext} 的新内容新 key 方式，不存在应用层默认的“同 key 覆盖写新内容”设计。
  4. 从应用侧最近 3 天样本看，同一对象存在明显重复读取，单对象可重复访问 10-18 次，样本高点在双位数每分钟，因此读缓存对我们这类场景是有效的。
  5. 对当前项目而言，绝大多数对象资源不依赖“同 URL 秒级内容更新”，因此 /gongxiangpan/uploads/ 这类对象路径更适合按静态对象长缓存来设计。

我们这边已整理了一批可联调的真实 URL 样本，可直接用于你们后续灰度验证。

5. 附：本次补充结论与上一份答复的关系

上一份文档：

适合回答：

  • 项目整体是否适合缓存
  • 为什么基本不用改业务代码
  • 为什么要单域名

本份文档适合回答：

  • 对方点名索要的 5 项补充信息
  • 近期日志里实际观察到的热点 URL 与流量样本
  • 当前双域名残留现状