启用 proxy_cache_use_stale updating 配合 proxy_cache_background_update on，可使用户请求立即返回旧缓存内容，同时后台异步更新缓存，避免大量并发回源压垮上游服务。
用 proxy_cache_use_stale updating 配合 proxy_cache_background_update on，就能在缓存即将过期或已过期时，让用户请求立刻返回旧内容，同时后台悄悄拉取新响应并写入缓存——彻底避开“更新风暴”。
为什么静态缓存更新会引发风暴
当大量用户在同一时刻访问一个刚过期的热门资源（比如首页、商品列表页），Nginx 默认行为是：所有请求都同步回源。哪怕时间差只有几毫秒，也可能触发几十甚至上百个并发回源请求，瞬间压垮上游服务。
这种现象不依赖总流量大小，而是由三个因素共同导致：
- 缓存有效期固定（如统一设为5分钟）
- 用户访问集中在某个时间点（如整点刷新、活动开始）
- 缺乏协调机制，每个请求都独立判断是否过期、是否需要回源
updating 参数的真实作用
proxy_cache_use_stale updating 本身不触发更新，只是一种“授权”：只要缓存条目正在被后台更新，就允许立即返回当前已有的（哪怕已过期）内容。
真正负责后台更新的是 proxy_cache_background_update on——它会让 Nginx 在检测到缓存快过期时，自动发起一个低优先级子请求去上游获取新响应，并写入缓存，主响应完全不受影响。
Bailian Usage Proxy
下载
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
两者配合后的实际流程是：
- 用户请求到达，发现缓存存在但已过期（或剩余寿命不足）
- Nginx 不阻塞，直接返回旧缓存（响应头中带
X-Cache: STALE） - 同时，Nginx 启动一个后台子请求，异步拉取新内容并更新缓存
必须配套的基础配置
单独加 updating 不起作用。以下四项缺一不可：
-
proxy_cache_path正确定义缓存区（含keys_zone） -
proxy_cache在location中启用对应缓存区 -
proxy_cache_valid明确设置缓存有效期（如200 5m），否则没有“过期”概念 -
proxy_cache_background_update on开启后台更新能力
示例关键片段：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=30m;
location /api/ {
proxy_cache my_cache;
proxy_cache_valid 200 5m;
proxy_cache_use_stale error timeout updating http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_pass http://backend;
}
验证是否生效的实操方法
别只看日志，重点观察三点：
- 停掉后端服务后，仍能快速返回响应（响应时间远低于
proxy_read_timeout） - 响应头中出现
X-Cache: STALE（需配置add_header X-Cache $upstream_cache_status;暴露） - 后台日志或
curl -I多次请求同一接口，发现响应时间稳定且无明显波动，说明没有同步阻塞回源
