如何在 Cloud Run 上让文件只保留几分钟而非数年
内容提要
本文介绍一种用于打印中转等短时任务的临时文件模式：文件仅在任务期间存在，完成后即删除。实现方式为：用随机ID命名对象，上传时加密并校验文件类型，密钥由KMS封装；任务记录存入Redis并设置TTL；授权方读取后先删对象再删记录，并以定时清理任务兜底。服务保持无状态，Redis故障时健康检查返回503。成功标准是空存储桶，而非可搜索的档案库。
延伸解读
无状态服务与有状态队列的平衡
文章强调Cloud Run服务本身可以无状态，但队列不能无状态。如果每个实例在内存中保存任务，多实例部署时会出现任务丢失或错乱。因此必须使用Redis等外部存储保存任务状态，并在健康检查中反映Redis的可用性，避免流量被路由到无法正确处理队列的实例。
加密策略与隐私声明的边界
文章区分了零知识加密和短保留期两种模式。对于打印中转等场景，服务器需要在接收时解密以校验文件类型，并在授权下载时解密流式传输，因此并非零知识。文章建议诚实声明服务器可见明文，避免过度承诺。同时，使用AES-GCM和KMS封装密钥可确保存储安全。
删除顺序与清理机制的设计
文章指出删除时应先删对象再删记录，防止指针丢失导致孤儿文件。此外，由于用户可能关闭页面或请求中断，需要定时清理任务作为兜底，删除超时未完成的对象。使用Redis锁避免多个实例同时清理，确保操作幂等。
随机命名与访问控制的区别
使用随机UUID命名对象可以避免形成可搜索的档案库，但文章提醒随机名称不等于访问控制。授权调用者仍需通过认证检查才能流式传输文件。同时，应限制单次访问的文件数量，防止存储和队列无限增长。
Q&A
如何在 Cloud Run 上实现文件只保留几分钟的临时存储？
使用一个 Cloud Run 服务，将文件密文存入对象存储，任务记录存入 Redis 并设置 TTL。授权方读取后先删除对象再删除记录，并用定时清理任务兜底。服务保持无状态，Redis 故障时健康检查返回 503。
为什么临时文件存储中对象名称要用随机 ID 而不是原始文件名？
使用随机 ID 可以避免对象存储变成可搜索的档案库，防止后续被要求添加搜索功能。原始文件名可以放在有 TTL 的任务记录中，而不是对象名称里。
在 Cloud Run 上处理临时文件时，如何保证多个实例间的队列一致性？
进程可以无状态，但队列不能。必须使用外部 Redis 存储任务记录，并确保健康检查在 Redis 不可用时返回 503，避免流量被路由到无法正确读取队列的实例。
临时文件存储中加密和密钥管理是如何设计的？
浏览器先用 AES-GCM 加密上传，服务端解密后校验文件类型，再用新的数据密钥加密存储。数据密钥由 Cloud KMS 封装，封装后的密钥与任务记录一起存储。授权读取时解封密钥、解密并流式传输。
如何确保临时文件被及时删除？
授权方读取完成后，先删除对象存储中的文件，再删除 Redis 中的任务记录。同时运行定时清理任务，删除已完成任务残留的对象或超过时间窗口（如 30 分钟）的孤立对象，并使用 Redis 锁防止重复清理。
这种临时文件模式有哪些局限性或不能声称的特性？
服务端在接收和授权下载时能看到明文，因此不是零知识加密。删除对象后无法从接收方屏幕、打印机或相机中消除。Redis 故障时应停止新任务，而不是回退到本地队列。随机对象名不是访问控制，仍需授权检查。
