这种CDN/缓存设计模式的名称是什么？最低成本的实现方案是什么？

这是两种经典缓存架构模式的组合应用：

• 核心主模式：按需生成式缓存（On-Demand Generated Cache，也叫惰性构建缓存/Lazy Build Cache），属于缓存模式的变种，专门适配生成成本高、访问触发频率不确定的资源场景，资源仅在首次被请求时触发构建，构建完成后永久缓存直到主动失效。
• 配套的防重复执行模式：请求合并（Request Collapsing）/ 缓存回填锁（Cache Backfill Lock），用于解决缓存未命中时的惊群效应，避免同个资源的多个并行请求触发多次重复的高成本构建任务。

你不需要额外引入重型中间件，基于Google Cloud现有托管服务就能极低门槛实现剩余功能，确实需要记录渲染任务状态，但不需要自行搭建数据库：

存储选型 #

• 渲染完成的MP4文件直接存入Cloud Storage即可，本身是高可用托管对象存储，成本极低。
• 任务状态存储直接用Cloud Firestore（Native模式）的免费配额就可覆盖绝大多数中小流量场景，单条资源状态仅需存3个字段：资源唯一ID（作为文档主键）、渲染状态（pending/success/failed）、版本号（可选，用于匹配源数据/渲染参数的变更）。

核心逻辑实现 #

收到请求后按以下流程执行：

1. 根据当前请求的源数据、压缩参数计算哈希值，拼接为资源唯一ID，参数/源数据变更时ID会自动变化，天然触发生成新版资源。
2. 先查询Cloud Storage中是否存在对应ID的MP4文件，存在直接返回文件，流程结束。
3. 文件不存在的话，向Firestore发起原子写入请求，尝试创建对应ID的状态文档，写入条件为「该ID文档不存在」，状态设为pending：
   • 写入成功：说明当前请求拿到了渲染锁，调用你已经实现的GCF渲染逻辑，渲染完成后将文件存入Cloud Storage，再把Firestore对应文档的状态更新为success，返回结果即可。
   • 写入失败：说明已有其他请求在渲染该资源，直接轮询Firestore中该文档的状态（间隔1~2秒即可，超时时间设为你渲染任务的最长耗时），等状态变为success后返回对应的Cloud Storage文件即可。

主动重渲染逻辑 #

需要手动触发重渲染时，仅需两步操作：

• 删除Cloud Storage中对应ID的旧MP4文件。
• 要么直接删除Firestore中对应ID的状态文档，下一次用户请求会自动触发重渲染；如果需要预渲染不用等用户请求，直接手动调用渲染GCF即可。

内容的提问来源于stack exchange，提问作者damian