冷热分离

账单上的一记闷棍

“光影”上线第 4 个月的一天早上，我收到一封阿里云的月度账单邮件。随手点开一看——存储费 380 元。

380 块？我们才 8000 个用户、5 万张图片，怎么就 380 了？

我打开 OSS 控制台一看，存储量已经飙到 2.1 TB。原因很简单：用户每上传一张 5MB 的原图，我们会生成 5 张缩略图（大/中/小/WebP/AVIF），加上原图本身，一张图片就占了将近 8MB 的存储空间。

但更让我不安的不是这些——而是这些存储的利用率。

帕累托法则现身

我写了一个脚本，分析过去 30 天所有图片的访问日志：

20% 的图片贡献了 84.3% 的流量。

更极端的是，前 1% 的图片（520 张）贡献了 42% 的流量——这些都是热门摄影师的作品、首页推荐图和社区活动中的照片。

而底部的 60% 图片（31,200 张），在 30 天内一次都没被访问过。它们就静静地躺在 OSS 上，每个月产生标准存储的费用。

42.7% 的图片是僵尸图片，30 天内无人问津，却在用最贵的标准存储。

这就是冷热分离的价值——把钱花在刀刃上。

设计分层策略

OSS 提供了三种存储类型，价格差距巨大：

存储类型      价格（元/GB/月）    适用场景              读取延迟
───────────────────────────────────────────────────────────────
标准存储      0.12               频繁访问（热数据）     毫秒级
低频存储      0.08               偶尔访问（温数据）     毫秒级
归档存储      0.03               极少访问（冷数据）     1~5 分钟（需解冻）
冷归档存储    0.01               合规归档               1~12 小时（需解冻）

我的分层策略：

自动分层引擎

接下来是核心——自动分析访问频率并迁移存储层级的定时任务。

缩略图的特殊处理

这里有个细节值得注意：缩略图不应该跟原图走同一套分层规则。

存储费直接砍掉 45%！ 从 30.48 元降到 16.63 元。

归档图片的”复活”机制

冷数据归档后，如果用户突然想看一张老照片怎么办？

前端配合：解冻等待体验

定时任务配置

冷热分析是一个定时任务，每天凌晨运行：