图片站与下载站对边缘缓存容量需求差别明显，根因不是访问量大小，而是单个缓存对象体积与驻留时间的乘积不同图片站缓存大量小文件，下载站缓存少量大文件，后者单文件就能吃掉一块边缘磁盘。
图片站和下载站哪个更吃带宽？先把带宽和容量拆开看
带宽吃紧和容量吃紧经常被混为一谈,带宽是“每秒要搬多少数据”，容量是“磁盘上能放多少数据”，图片站的请求次数可能远高于下载站，但每次请求只搬几十KB到几MB；下载站一天可能只有几百次点击，一次就搬几个GB，所以图片站经常先碰到带宽瓶颈，下载站经常先碰到磁盘容量瓶颈。
| 对比项 | 图片站 | 下载站 |
|---|---|---|
| 单对象大小 | 几十KB到几MB | 几百MB到几十GB |
| 热对象数量 | 多 | 少 |
| 单节点容量压力 | 相对低 | 相对高 |
| 主要瓶颈 | 带宽和请求数 | 磁盘容量和回源带宽 |
图片站的请求模型：高频小对象
- 单张图片通常几十KB到几MB,WebP、AVIF格式进一步压缩。
- 一个详情页可能同时拉取几十张缩略图,请求数大。
- 热点图片相对分散,缓存命中集合大，但单对象占空间小。
- 边缘节点容量压力主要来自对象数量,而不是单文件体积。
下载站的请求模型：低频大对象
- 安装包、系统镜像、模型权重、视频素材包，动辄几百MB到几十GB。
- 请求频次低,但一旦命中，单个文件就会长期占用磁盘。
- 大文件下载中断后续传,边缘节点还要处理Range请求，缓存分片会增加容量碎片。
- 容量压力主要来自少数几个超大文件,而不是海量小文件。
图片站边缘缓存容量需求为何普遍低于下载站
图片站边缘缓存容量需求通常低于下载站,不是图片不重要，而是图片的“单对象体积×驻留时间”这个乘积小。
容量需求由三个变量决定
- 热对象数量：图片站热图数量多，下载站热文件数量少。
- 平均对象大小：图片站几十KB到几MB，下载站几百MB到几十GB。
- 缓存驻留时间：图片站内容更新快，下载站版本稳定，大文件驻留更久。
把三个变量乘起来,下载站在平均对象大小上大几个数量级，热对象数量上的劣势完全被抵消，行业共识认为，大文件缓存驻留是边缘磁盘被迅速占满的主要原因。
缓存淘汰策略对两类站点的不同影响
图片站使用LRU或LFU淘汰时,删掉一个对象只释放几MB空间，容量曲线平滑，下载站淘汰一个安装包，可能瞬间释放几GB，但换入一个新的大文件，又瞬间占掉几GB，这种台阶式变化让下载站必须预留更多冗余容量，否则容易触发磁盘写满、缓存写失败。
压缩和转码进一步拉低图片站容量压力
图片站可以在边缘节点直接做WebP/AVIF转码，把原图转成更小的格式再缓存，下载站的大文件大多已是压缩包，边缘节点没法再压缩，转码不适用，图片站的缩略图、尺寸变体虽然增加对象数，但单个更小，总容量仍然可控。
下载站边缘缓存配置方案：容量不能按请求数估算
下载站做边缘缓存,先要忘掉“按点击量算容量”的思路，大文件缓存的容量需求，要看源站热文件的体积分布。
实操步骤：从源站扫描热文件体积
- 登录源站或对象存储挂载目录。
- 用命令找出最大的文件：
du -sh /var/www/downloads/ | sort -rh | head -20 - 记录前20个热文件的总体积。
- 边缘节点缓存盘的可用空间,至少要覆盖这些热文件的总体积，并留出冗余。
- 如果使用Nginx的
proxy_cache_path，把max_size设置为热文件总体积的合理倍数，避免磁盘写满后回源。
Nginx下载站边缘缓存关键配置
proxy_cache_path /data/cache levels=1:2 keys_zone=download_cache:100m
max_size=500g inactive=30d use_temp_path=off;
max_size决定缓存盘上限。inactive=30d适合大文件版本稳定场景。- 大文件下载要开启
proxy_cache_key包含$http_range，否则Range请求可能缓存错误分片。
图片站边缘缓存配置侧重命中率而不是容量
图片站可以配置更小的max_size，但要把proxy_cache_valid按文件类型细化，比如图片缓存24小时，缩略图缓存更久，用proxy_cache_min_uses提高命中门槛，避免冷图占盘，图片站的容量监控看对象数量和平均大小，下载站看磁盘使用率和Top大文件。
国内边缘节点部署成本如何影响两类站点的容量选择
国内边缘节点部署成本不是统一价,一线城市机房带宽贵、磁盘相对便宜，中西部节点带宽便宜但磁盘成本占比上升，下载站的大文件缓存对磁盘容量敏感，更倾向于把大缓存盘放在核心城市或自有节点，边缘小节点只放少量热文件，图片站小对象缓存对磁盘不敏感，可以在更多地域节点均匀分布，用更低的磁盘成本换更低的延迟。
边缘节点带宽计费与磁盘容量要协同
- 按95计费的带宽,下载站大文件突发会推高计费带宽，需要在边缘节点缓存更多热文件来抵扣回源带宽。
- 按流量计费时,图片站请求多但单次流量小，下载站单次流量大，容量配置要与带宽包匹配。
- 国内跨地域回源链路质量差异大,下载站如果边缘节点容量不足，回源大文件会占用大量骨干网带宽，成本反而更高。
业内专家指出,边缘缓存容量规划不能只看磁盘单价，要把它和回源带宽、命中率、用户地域分布放在一起算，图片站容量冗余小，下载站容量冗余大，这是两类业务形态决定的，不是配置失误。
实操：两类站点边缘缓存容量估算模板
- 图片站：统计日UV、平均图片请求数、平均对象大小、缓存命中率目标，容量约等于“热图数量×平均大小×副本系数”。
- 下载站：统计日下载次数、热文件数、平均文件大小、缓存驻留时长，容量约等于“热文件总大小×冗余系数”。
- 两类站点都需要监控：磁盘使用率、缓存命中率、回源流量、淘汰速率。
- 下载站额外监控Top10大文件缓存状态和磁盘碎片率。
图片站和下载站对边缘缓存容量需求差别明显,本质是缓存对象的体积分布不同，图片站用容量换命中率，下载站用容量换回源带宽，规划容量时先看文件体积分布，再决定磁盘大小，比盲目按流量估算更稳妥。
Q&A：图片站与下载站边缘缓存容量需求常见问题
图片站边缘缓存容量需求低，还需要部署边缘缓存吗？
需要,容量低不等于边缘缓存没有价值，图片站边缘缓存主要降低用户加载延迟、减少回源带宽，并支持就近做图片转码和缩略图生成，单节点磁盘不必为超大文件预留，但仍需为热图集合留出足够空间。
下载站边缘缓存容量需求大，怎样避免磁盘写满？
下载站要设置较高的max_size，开启磁盘水位告警，并定期检查Top大文件，对超大安装包可以只缓存Range分片而不是整个文件，或者把版本稳定的文件迁移到对象存储，让边缘节点只保留最近几个版本，写满时优先淘汰最久未命中的大文件。
图片站和下载站边缘缓存容量需求不同，选型时先看什么？
先看源站文件体积分布和单文件最大体积,如果大多数对象小于1MB，按图片站思路配置；如果存在几百MB以上的高频下载文件，按下载站思路预留大磁盘，再看地域分布和带宽计费方式，国内多节点部署时，下载站需要在核心节点放更大的缓存盘，图片站可以更均匀地分布小容量节点。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/642820.html
