静态缓存这样设置，服务器性能提升50%

在许多网站运维人员眼中,静态缓存是“配完就不管”的配置项，但其实，静态缓存的设置方式直接影响服务器的负载能力与响应速度，如果设置得当，能大幅降低CPU与IO压力；反之，可能导致缓存命中率低、磁盘空间浪费甚至缓存雪崩，下面从服务器视角出发，聊聊几种关键设置方法。

明确哪些内容适合静态缓存

静态缓存只对不经常变化、可重复利用的资源有效，推荐缓存的对象包括：

• 图片、CSS、JS文件：版本固定时可长期缓存
• 字体文件、PDF、视频分段：占用带宽大，缓存收益高
• 不带参数的API响应（如JSON配置、静态网页片段）：减少后端计算

不要缓存：用户私有数据、实时交易接口、频繁更新的数据库结果。

合理设置缓存过期时间（TTL）

TTL是服务器端缓存生存时间,设置原则是：对稳定性要求高、更新频率低的资源，TTL设置长一些；对可能变化的资源，设置短TTL或采用主动失效机制。

推荐策略：

• 版本化的静态资源（如app.abc123.css）：TTL设为30天以上，甚至永久
• 非版本化资源（如站点Logo）：TTL设为1~7天，配合文件修改时间校验
• API片段缓存：TTL依据数据更新周期设定，如5分钟、1小时

注意：长TTL配合HTTP头Cache-Control: public, max-age=31536000，可让CDN和浏览器同时受益。

启用内存缓存，减少磁盘IO

静态缓存常用的存储介质有两类：内存与磁盘，内存速度比磁盘快百倍以上，但容量有限。

实用建议：

• 核心高频资源（如首页、公共JS库）：强制放入内存缓存（如Redis、Nginx proxy_cache_path max_size=10g levels=1:2搭配use_temp_path=off避免中间写入磁盘）
• 大文件（视频、高清图）：使用磁盘缓存，但设置inactive参数清理长时间未访问的文件
• 启动缓存分层：内存作为第一级缓存（L1），磁盘作为第二级缓存（L2），命中L1则直接返回

使用CDN分担服务器静态资源压力

CDN是静态缓存的最佳搭档,它将资源分发到靠近用户的节点，服务器只需承担“源站回源”压力。

服务器端配合CDN的设置：

• 回源协议统一为HTTPS：避免CDN回源时证书错误，减少连接开销
• 设置合理回源超时：proxy_connect_timeout 5s、proxy_read_timeout 10s，防止慢回源拖累服务器
• 开启CDN缓存标签：通过Cache-Tag头控制CDN精准失效，无需整个文件清空
• 利用CDN预热：发布新版本后，对首页、核心资源发起预热请求，防止回源脉冲压垮服务器

配置缓存分片与缓存钥匙（Cache Key）

同一个URL可能因不同用户或参数得到不同内容,若共享同一个缓存键，会产生“缓存污染”，需要合理设计缓存钥匙：

• 仅对静态资源使用$uri作为key，忽略请求头
• 对API缓存,可根据$uri$is_args$args生成key，或自定义区分A/B测试的版本号
• 大型站点可对缓存空间分区：proxy_cache_path /cache levels=1:2 keys_zone=static:100m，不同路径使用不同缓存区

主动清理与惰性失效结合

静态缓存如果不清理,可能永远占用空间，推荐“主动清理+惰性失效”组合模式：

• 主动清理：当文件更新时，服务器主动发送PURGE请求给缓存节点（Nginx需加载ngx_cache_purge模块）
• 惰性失效：设置inactive（如inactive=7d），缓存文件7天内未被访问则自动删除
• 版本号驱动：CSS/JS文件名加入hash值，旧版本资源在新版本发布后自然淘汰，无需清理

监控才是最终保障

再完美的设置也需要监控来验证,建议关注以下指标：

• 缓存命中率：低于70%需检查TTL或缓存策略
• 内存/磁盘占用比例：若内存缓存长期满而磁盘很空，说明分级策略失效
• 回源请求量：CDN环境下回源请求突然增加，往往是缓存失效触发

可以使用Prometheus配合Nginx的ngx_http_stub_status_module模块，或直接查看CDN控制台统计。

静态缓存设置的核心,不是一味求大求长，而是根据资源特性合理分级：高频资源放内存、大体积资源用磁盘、版本化资源设长TTL、未版本化资源靠主动失效，再结合CDN和监控体系，服务器才能真正“减负”——响应更快、负载更低、稳定性更高。

记住一句话：静态缓存是服务器最好的“减震器”，而精细化的配置，就是让它永远工作在最佳频率上。