如何通过Nginx proxy_cache_background_update模块实现静默过期缓存更新？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1015个文字，预计阅读时间需要5分钟。
“
（请提供需要改写的原文内容，以便我进行相应的简写和修改。）
为什么开了 proxy_cache_background_update 还会压垮上游？
因为 proxy_cache_background_update on 只表示“缓存过期后先返回旧内容，再后台发起一次更新请求”——但它不判断“此刻是否已有同键更新在进行”。1000 个并发请求击中同一个过期缓存键，Nginx 就会默认发起 1000 次后台更新，和没开缓存几乎一样。
常见错误现象：upstream connect timeout、502/504 突增、上游 CPU 或连接数飙升；日志里反复看到同一 $uri 在几秒内触发数十次 MISS 或 UPDATING。
- 它不是锁机制，不解决并发冲突
- 它不控制资源（连接、缓冲区、超时），后台请求和主请求共用同一套
proxy_*_timeout和proxy_buffers - 它不区分请求来源，GET/HEAD/带 Cookie 的请求只要缓存键一致，就都可能触发后台更新
必须配 proxy_cache_lock，否则 background_update 就是“伪静默”
proxy_cache_lock on 才是让多个并发请求对同一缓存键“排队等刷新”的关键。它确保：只有一个请求能穿透缓存去 upstream 拉新数据，其余请求要么等待（在 proxy_cache_lock_timeout 内），要么直接返回陈旧内容（需配合 proxy_cache_use_stale updating）。
实操建议：
-
proxy_cache_lock on必须开启，且放在location块内，不能只写在http或server级 -
proxy_cache_lock_timeout 2s：设短些，避免用户端等待太久；超过即放弃抢锁，走 stale 分支 -
proxy_cache_lock_age 10s：锁释放后，10 秒内禁止新锁竞争，防止刚刷完立刻又被刷 -
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504：这是“静默”的底线——连锁都没抢到的请求，也得有 fallback
后台更新请求要单独限流，不能和主流量抢资源
后台更新虽不阻塞用户，但默认和主请求共享 proxy_connect_timeout、proxy_read_timeout、proxy_buffers，容易拖慢整体调度或耗尽 worker 内存。
实操建议（无需改代码，纯配置）：
-
proxy_connect_timeout 3s、proxy_read_timeout 5s：比主请求更激进，快速失败，避免卡住连接 -
proxy_next_upstream error timeout http_500 http_502 http_503 http_504+proxy_next_upstream_tries 2+proxy_next_upstream_timeout 6s：两次尝试内必须结束，否则丢弃 - 用
map或if ($upstream_http_x-cache-status = "UPDATING")（需上游配合加 header）动态切换 upstream，把后台更新路由到精简版upstream（例如keepalive 4而非32） -
proxy_buffering off不推荐全局关；更稳妥的是调小缓冲：proxy_buffers 8 64k、proxy_busy_buffers_size 128k
验证是否真“静默”，盯紧这三个响应头
仅靠日志难定位问题，应在响应中暴露关键状态：
-
add_header X-Cache-Status $upstream_cache_status：值为HIT/MISS/EXPIRED/STALE/UPDATING，确认是否走到了 background update 流程 -
add_header X-Cache-Lock $upstream_cache_status不行，要用$sent_http_x_cache_lock或自定义变量记录锁行为（需配合 log_format） -
add_header X-Cache-Key $cache_key（需提前定义proxy_cache_key）：排查键是否被意外打散（如 Cookie、User-Agent 未忽略）
最容易被忽略的是：缓存键设计不合理导致本该合并的请求分散成多个键，proxy_cache_lock 完全失效。比如忘了加 proxy_ignore_headers Set-Cookie，或 proxy_cache_key 里混进了 $cookie_sessionid。
本文共计1015个文字，预计阅读时间需要5分钟。
“
（请提供需要改写的原文内容，以便我进行相应的简写和修改。）
为什么开了 proxy_cache_background_update 还会压垮上游？
因为 proxy_cache_background_update on 只表示“缓存过期后先返回旧内容，再后台发起一次更新请求”——但它不判断“此刻是否已有同键更新在进行”。1000 个并发请求击中同一个过期缓存键，Nginx 就会默认发起 1000 次后台更新，和没开缓存几乎一样。
常见错误现象：upstream connect timeout、502/504 突增、上游 CPU 或连接数飙升；日志里反复看到同一 $uri 在几秒内触发数十次 MISS 或 UPDATING。
- 它不是锁机制，不解决并发冲突
- 它不控制资源（连接、缓冲区、超时），后台请求和主请求共用同一套
proxy_*_timeout和proxy_buffers - 它不区分请求来源，GET/HEAD/带 Cookie 的请求只要缓存键一致，就都可能触发后台更新
必须配 proxy_cache_lock，否则 background_update 就是“伪静默”
proxy_cache_lock on 才是让多个并发请求对同一缓存键“排队等刷新”的关键。它确保：只有一个请求能穿透缓存去 upstream 拉新数据，其余请求要么等待（在 proxy_cache_lock_timeout 内），要么直接返回陈旧内容（需配合 proxy_cache_use_stale updating）。
实操建议：
-
proxy_cache_lock on必须开启，且放在location块内，不能只写在http或server级 -
proxy_cache_lock_timeout 2s：设短些，避免用户端等待太久；超过即放弃抢锁，走 stale 分支 -
proxy_cache_lock_age 10s：锁释放后，10 秒内禁止新锁竞争，防止刚刷完立刻又被刷 -
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504：这是“静默”的底线——连锁都没抢到的请求，也得有 fallback
后台更新请求要单独限流，不能和主流量抢资源
后台更新虽不阻塞用户，但默认和主请求共享 proxy_connect_timeout、proxy_read_timeout、proxy_buffers，容易拖慢整体调度或耗尽 worker 内存。
实操建议（无需改代码，纯配置）：
-
proxy_connect_timeout 3s、proxy_read_timeout 5s：比主请求更激进，快速失败，避免卡住连接 -
proxy_next_upstream error timeout http_500 http_502 http_503 http_504+proxy_next_upstream_tries 2+proxy_next_upstream_timeout 6s：两次尝试内必须结束，否则丢弃 - 用
map或if ($upstream_http_x-cache-status = "UPDATING")（需上游配合加 header）动态切换 upstream，把后台更新路由到精简版upstream（例如keepalive 4而非32） -
proxy_buffering off不推荐全局关；更稳妥的是调小缓冲：proxy_buffers 8 64k、proxy_busy_buffers_size 128k
验证是否真“静默”，盯紧这三个响应头
仅靠日志难定位问题，应在响应中暴露关键状态：
-
add_header X-Cache-Status $upstream_cache_status：值为HIT/MISS/EXPIRED/STALE/UPDATING，确认是否走到了 background update 流程 -
add_header X-Cache-Lock $upstream_cache_status不行，要用$sent_http_x_cache_lock或自定义变量记录锁行为（需配合 log_format） -
add_header X-Cache-Key $cache_key（需提前定义proxy_cache_key）：排查键是否被意外打散（如 Cookie、User-Agent 未忽略）
最容易被忽略的是：缓存键设计不合理导致本该合并的请求分散成多个键，proxy_cache_lock 完全失效。比如忘了加 proxy_ignore_headers Set-Cookie，或 proxy_cache_key 里混进了 $cookie_sessionid。