一个真实的“惊群”现象：你的网站突然变慢，原因可能是缓存过期
故障定位思路
解决大型网站静态文件过期看似简单，真正落地时却很容易踩坑。想象一下：你维护着一个日活百万的新闻网站，用户打开首页时，浏览器会请求一大堆 CSS、JS 和图片。这些静态文件被 CDN 或浏览器缓存了一段时间。某个凌晨，运营同事批量更新了首页样式，重新发布了所有静态资源——于是所有旧缓存瞬间失效。早上 8 点，用户涌进来，浏览器发现缓存过期，于是成千上万个请求同时涌向源站。源站服务器 CPU 飙到 100%，数据库连接池耗尽，页面加载时间从 200ms 变成 10 秒，最终导致大面积 502 错误。这就是典型的“回源雪崩”。
延伸阅读：此处可内链到“解决大型网站静态文件过期配置案例”相关文章。
什么是回源雪崩？为什么跟静态文件过期有关？
容易忽略的细节
先拆解几个概念：
- 回源：当 CDN 节点或浏览器本地没有缓存，或者缓存已过期，它们会向源站（你的服务器）请求原始文件。这个过程叫回源。
- 雪崩：在极短时间内，大量请求同时打到源站，导致源站负载超过上限，进而响应变慢甚至崩溃。崩溃后，后续请求堆积，形成恶性循环。
静态文件（如 .css、.js、.png）通常会被设置一个较长的缓存时间（比如 30 天）。但当你发布新版本时，会更改文件名（比如 app-v2.js）或通过版本号强制刷新缓存。问题就出在这里：如果某个 CDN 节点上的旧缓存恰好集中过期，或者你手动清空了整个 CDN 缓存，那么所有用户下一次访问时，都会触发回源。而且，浏览器端的缓存可能也同时失效，双重叠加，回源流量可能比平时高几百倍。这就像一座独木桥，平时只走 10 个人，突然来了 10000 个人同时挤上去，桥当然会塌。
想继续深入：此处可内链到“解决大型网站静态文件过期优化清单”文章。
容灾方案一：分层缓存——给静态文件建三堵墙与解决大型网站静态文件过期
容易忽略的细节
最朴素的思路：不让源站直接承受所有请求。我们可以建三层缓存：
- 第一层：浏览器缓存（强缓存）——设置合理的 Cache-Control max-age，比如 365 天。配合 ETag / Last-Modified 做协商缓存。用户打开页面时，只要本地缓存没过期，连 CDN 都不必去。
- 第二层：CDN 缓存——把静态文件分发到全球边缘节点。CDN 节点本身也会缓存文件，并设置较长的缓存时间（例如 7 天）。注意，CDN 的缓存策略要跟浏览器缓存错开，比如 CDN 缓存 7 天，浏览器缓存 1 年，这样即使浏览器缓存过期，CDN 节点上大概率还有副本。
- 第三层：源站缓存——在源站前面加一层 Nginx 反向代理或内存缓存（如 Redis/Varnish）。即使 CDN 节点全部穿透回源，这层缓存可以挡住大部分请求，真正打到应用服务器的只有极少数。
这三层缓存就像三道防洪堤坝，层层削峰。
相关阅读：此处可内链到“解决大型网站静态文件过期常见问题”专题。
解决大型网站静态文件过期：容灾方案二：缓存预热——别让海量请求同时扑过来
我的处理经验
当你计划更新静态资源时，不要直接清除缓存。应该提前“预热”。具体做法：
- 用脚本或 CDN 的预热接口，提前将新版本的静态文件推送到所有 CDN 节点。
- 预热完成后，再让用户访问新版本。
- 如果你的 CDN 不支持预热，可以采取“灰度发布”：先让 1% 的流量访问新资源，确认没问题后再逐步放量，同时观察回源量。
预热的核心思想是“把集中请求分散到一段时间内”，避免瞬间冲击。
关联教程：此处可内链到“解决大型网站静态文件过期部署与验证”内容。
容灾方案三：回源限流与熔断——保护源站不被打垮
实际操作要点
即使有缓存和预热，依然可能出现突发回源超过承载能力的情况。这时候需要主动限流：
- 在源站入口设置速率限制（Rate Limiting）：比如 Nginx 的 limit_req 模块，限制每秒最多接受 1000 个回源请求，多余的返回 503 或 429，让 CDN 重试。
- 熔断机制：监控回源失败率，一旦超过阈值（比如 50% 请求 5xx），自动开启熔断，直接返回过期的缓存内容给用户（即使过期，也比打不开强）。CDN 通常有“回源失败时使用过期缓存”的选项，务必开启。
- 后端过载保护：在应用服务器层面，使用连接池限制、任务队列等，避免被超负荷请求冲垮。
补充参考：此处可内链到“解决大型网站静态文件过期故障排查实例”。
容灾方案四：异步回源与合并请求——减少不必要的回源
故障定位思路
有些框架默认会为每个静态文件单独发送回源请求。如果页面有 50 个静态文件，回源一次就是 50 个并发。可以通过以下方式优化：
- CSS Sprite / 雪碧图：把小图标合并成一张大图，减少请求数。
- Webpack 打包：把多个 JS/CSS 合并成一个（注意合理分块，避免过度合并导致大文件缓存更新困难）。
- CDN 的回源合并：部分 CDN 支持“回源请求合并”，同一节点上多个用户请求同一个文件时，只发起一次回源，其他人等待该文件缓存后再获取。
实战：用 Nginx + CDN 搭建防雪崩架构
假设你有一个使用 Nginx 作为反向代理的源站，CDN 用的是 EdgeOne（腾讯云）或 Cloudflare。下面是一个常见的配置思路：
1. 源站 Nginx 配置回源限流
http {
limit_req_zone $binary_remote_addr zone=src_limit:10m rate=1000r/s;
server {
location /static/ {
limit_req zone=src_limit burst=200 nodelay;
proxy_pass http://backend;
# 启用缓存
proxy_cache STATIC;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503;
}
}
}
说明：
- rate=1000r/s 表示每秒最多处理 1000 个请求，超出部分被限流。
- burst=200 允许短时间内额外 200 个突发请求。
- proxy_cache_use_stale 让 Nginx 在回源失败时返回过期缓存，避免雪上加霜。
2. CDN 端配置
- 设置 CDN 缓存时间为 7 天（根据文件更新频率调整）。
- 开启“回源失败时使用过期缓存”选项。
- 配置缓存预热 API，在发布新版本前执行预热脚本。
- 设置 CDN 回源超时（比如 5 秒），避免慢请求占满连接。
3. 验证方法
你可以用压测工具（如 wrk、ab）模拟大量并发回源。正常情况源站 CPU 应该平稳，不会出现断崖式上升。如果发现限流生效，返回 503 时 CDN 节点会使用过期缓存，用户无感知。
常见误区与注意事项
验证与回滚
- 误区一：缓存时间越长越好。 太长会导致更新不及时，太短会频繁回源。建议静态文件缓存 30 天以上，配合版本号强制刷新，而不是频繁清全站缓存。
- 误区二：清缓存时全量清除。 应该只清除变更的文件对应的缓存，或者使用 CDN 的“目录刷新”功能，避免把所有文件缓存都干掉。
- 误区三：只依赖 CDN，不设源站缓存。 CDN 节点也可能同时穿透，比如某个地区 CDN 节点故障后重建，源站直接承受全部请求。
- 注意： 如果你的静态文件托管在对象存储（如 COS、S3）上，回源雪崩同样会发生在对象存储上。对象存储也有 QPS 限制，同理需要打开 CDN 缓存并配置预热。
总结：设计一个能扛住突发回源的系统
配置前的检查
解决静态文件过期导致的回源雪崩，核心思路是“减少突发量、充分利用缓存、提前预热、主动限流”。具体方案结合你的业务场景选择：
- 对于小型网站，做好浏览器缓存 + Nginx 代理缓存基本够用。
- 对于中型网站，加上 CDN 和限流。
- 对于大型网站，必须全面实施分层缓存、预热、熔断、异步合并等组合策略。
缓存过期只是一个触发点，但背后的本质是“流量尖刺”。通过这篇文章，希望你能建立起对回源雪崩的直觉认知，并在实际架构中提前埋下保护机制。毕竟，一个好的容灾方案，应该在故障发生前就已经生效，而不是等雪崩来了再临时补救。后续只要定期检查关键指标，解决大型网站静态文件过期就不会变成维护负担。
延伸阅读