OBS 生命周期转归档后 CDN 回源失败：三种可落地的修复方案

问题现象

OBS 桶开启 CDN 加速后，配置了 30 天转归档的生命周期规则。第 31 天起，CDN 边缘节点未命中缓存回源，源站返回 404 NoSuchKey，边缘把 404 也缓存了 60 秒，用户连续看到资源加载失败。

根因分析

生命周期把对象从标准存储转成归档存储后，对象元数据仍存在，但 GET 请求需要先恢复（Restore），未恢复直接读取会返回失败。CDN 回源使用的是普通 GET，无法触发恢复流程，因此回源失败。同时 CDN 的缓存键只包含 URL，不含存储类别，导致错误响应被当作正常结果缓存。

方案一：让 CDN 只服务热数据

把需要长期通过 CDN 分发的对象放到独立桶，生命周期规则只对冷备桶生效；热桶设置更长的保留期，或者改用低频访问存储而不是归档。这样回源始终可读。

方案二：回源前先恢复

对确实需要归档的对象，用 OBS 的 RestoreObject 接口提前恢复，恢复完成后再刷新 CDN 缓存。恢复是异步的，标准恢复通常几分钟完成。可以写一个定时任务扫描即将转归档的对象，提前把热点对象恢复到标准存储。

方案三：区分回源状态码

在 CDN 侧配置缓存规则，只缓存 200 和 206，不缓存 403、404、5xx；同时把回源超时时间调大，避免恢复中的对象被提前判定失败。这样即使偶发回源失败，边缘也不会把错误结果缓存给所有用户。

验证方法

用 curl 直接请求源站对象确认返回码；再用 curl -I 请求 CDN 域名，观察 X-Cache 命中状态；最后在归档对象上调用恢复接口，等待恢复完成后再次请求，确认返回 200。三步都通过，说明链路配置正确。

经验总结

生命周期规则和 CDN 缓存策略必须一起设计。凡是会被 CDN 长期回源的桶，不要把默认存储类别设成归档；确实要归档的，要么走独立桶，要么在回源链路上加恢复步骤。缓存键尽量包含影响内容的维度，错误码一定不要缓存。