proxy_cache_background_update 的作用是在缓存即将过期时,不阻塞用户请求,一边返回旧缓存一边后台更新;需配合 proxy_cache_valid、proxy_cache_use_stale updating 和 proxy_cache_background_update on 同时启用。

proxy_cache_background_update 的作用不是“刷新缓存”,而是让 Nginx 在缓存即将过期时,**不阻塞用户请求**,一边把旧缓存返回给客户端,一边在后台悄悄去后端拉取新响应并更新缓存。它解决的是“缓存失效瞬间大量请求穿透到后端”的问题(即缓存雪崩/缓存击穿),而不是主动轮询或定时刷新。
启用 background update 的前提条件
这个功能不会自动生效,必须配合以下配置共同使用:
FastAPI + Flask 混合部署最佳实践,解决路由定义、API 代理等常见问题,适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_cache_valid 必须设置明确的缓存有效期(例如
proxy_cache_valid 200 5m;) -
proxy_cache_use_stale 必须启用至少一项“可接受过期缓存”的指令,比如
updating(关键!没有它,background update 不会触发) - proxy_cache_background_update on; 显式开启(默认是 off)
典型配置示例
以下是最小可行配置片段(放在 location 块中):
proxy_cache my_cache; proxy_cache_valid 200 5m; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_cache_background_update on; proxy_cache_lock on; # 推荐搭配,避免重复回源
说明:
- 当一个请求命中缓存,且该缓存已存在 4m50s(即距离过期只剩 10s),Nginx 就会认为它“即将过期”;
- 如果此时有新请求进来,且缓存尚未完全过期,Nginx 会立即返回当前旧缓存(因为 updating 在 proxy_cache_use_stale 中);
- 同时,Nginx 在后台发起一个异步子请求到后端,获取新响应,并用它更新缓存——整个过程对用户透明、无延迟。
它不做什么?常见误解澄清
- 不是定时刷新:它只在有请求触发、且缓存临近过期时才后台回源,没有请求就不会动作
- 不保证强一致性:用户可能在更新完成前持续拿到旧内容(这是设计目标:可用性优先)
-
不替代 purge 或主动失效机制:后端数据变更时,仍需通过
proxy_cache_purge或时间戳/版本号等手段主动清理缓存 - 不降低首次回源延迟:第一次访问或缓存彻底过期后首次访问,仍会同步阻塞等待后端响应
验证是否生效的方法
可通过日志和缓存状态辅助判断:
- 开启
log_format记录$upstream_cache_status,看到UPDATING状态表示后台更新已触发 - 用
curl -I观察响应头中的X-Cache(若自定义)或Age头变化趋势 - 在后端加简单日志,观察在高并发下,同一资源的请求是否明显减少(说明多数被缓存 + background update 拦截)










