Nginx 里 fastcgi_cache_background_update 实现静默更新

fastcgi_cache_background_update 是 Nginx 的缓存静默更新机制，允许缓存过期后仍用旧内容响应用户，同时后台异步刷新；需配合 fastcgi_cache_use_stale updating、fastcgi_cache_valid updating 及 fastcgi_cache_lock off 才能生效。

fastcgi_cache_background_update 是 Nginx 提供的一项关键缓存优化机制，它让缓存过期后仍能继续服务旧内容，同时在后台悄悄拉取新内容并更新缓存——用户完全无感，页面不卡顿、不报错、不降级。

它解决什么问题？

默认情况下，当 fastcgi 缓存过期，Nginx 会阻塞后续请求，直到上游 PHP（如 php-fpm）返回新响应并完成缓存更新。高并发下容易造成“雪崩式延迟”，尤其在动态内容生成较慢时（比如带数据库查询或外部 API 调用的页面）。
开启 fastcgi_cache_background_update on 后，Nginx 在缓存即将过期或已过期时，会立即用旧缓存响应客户端，同时异步发起一个后台子请求去刷新缓存——两个动作完全解耦。

必须配合的关键指令

该功能不是独立生效的，需与以下配置协同工作：

• fastcgi_cache_use_stale updating：允许在缓存正在被后台更新时，继续使用陈旧缓存响应请求；
• fastcgi_cache_valid 中需明确指定 updating 状态的有效期（例如 fastcgi_cache_valid 200 302 10m;，但还需加 updating 5m; 表示更新中的缓存最多再用 5 分钟）；
• fastcgi_cache_lock 推荐关闭（off），否则后台更新可能被锁阻塞，失去“静默”意义；若必须用锁，应配 fastcgi_cache_lock_timeout 防死等；
• 确保 fastcgi_cache_path 已定义且有足够空间，后台更新依赖临时文件写入。

典型配置片段示意

以下是最小可行配置示例（放在 http 或 server 块中）：

fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=mycache:100m inactive=60m use_temp_path=off;<p>server {location ~ .php$ {fastcgi_pass 127.0.0.1:9000;include fastcgi_params;</p><pre class="brush:php;toolbar:false;">    fastcgi_cache mycache;    fastcgi_cache_valid 200 302 10m;    fastcgi_cache_valid 404 1m;    fastcgi_cache_valid updating 5m;  # ← 关键：允许更新中缓存再活 5 分钟    fastcgi_cache_use_stale error timeout updating http_500 http_503;    fastcgi_cache_background_update on;  # ← 开启静默更新    fastcgi_cache_lock off;              # ← 避免后台更新被锁住    fastcgi_cache_bypass $no_cache;    fastcgi_no_cache $no_cache;}

}

验证是否生效

可通过 Nginx 日志和缓存状态辅助判断：

• 启用 log_format 记录 $upstream_cache_status，看到 UPDATING 状态即表示后台更新已触发；
• 观察响应头：X-FastCGI-Cache: HIT 且状态码为 200，但后台正刷新——说明静默更新正在运行；
• 手动清空缓存后首次访问是 MIS，第二次起若快速返回 HIT 且后续仍能持续服务，基本表明 background update 工作正常。

不复杂但容易忽略。关键是理解“updating”是一种缓存状态，而非开关；它需要 valid、use_stale、background_update 三者联动，缺一不可。