Nginx 代理缓存中并发请求合并 proxy_cache_lock 怎么配置防止雪崩效应-Nginx-PHP中文网

proxy_cache_lock 通过只放行首个缓存未命中请求回源、其余请求等待或返回旧缓存，缓解缓存击穿压力；需配合过期时间分散、多级缓存、限流等策略共同防雪崩。

nginx 代理缓存中并发请求合并 proxy_cache_lock 怎么配置防止雪崩效应

nginx 的 proxy_cache_lock 是防止缓存失效时大量并发请求穿透到后端的关键机制，它本身不直接解决缓存雪崩，但能有效缓解“缓存击穿”引发的瞬时压力——这是雪崩链条中的重要一环。真正防雪崩需配合过期时间分散、多级缓存、限流等策略，而 proxy_cache_lock 负责在缓存未命中时，只放行一个请求去回源重建缓存，其余请求等待该结果返回后直接使用，避免多个相同请求同时打到后端。

proxy_cache_lock 的核心作用与触发条件

当多个请求同时访问一个尚未缓存（或已过期）的资源时，若启用 proxy_cache_lock，nginx 会锁定该缓存 key，仅让第一个请求进入 upstream 回源，其他请求阻塞等待（默认最多等待 proxy_cache_lock_timeout），待缓存写入成功后统一返回。这显著降低后端负载峰值。

仅对“缓存未命中且需回源”的请求生效；已有有效缓存时完全不触发
锁定粒度是 cache key，不是 URI 或参数组合，需确保 key 设计合理（如忽略无关 query 参数）
不保证绝对原子性：若上游响应慢或超时，锁可能提前释放，导致后续请求再次回源

基础配置写法与关键指令

必须在 location 或 server 块中启用，并搭配 proxy_cache 使用：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

proxy_cache my_cache;
proxy_cache_valid 200 302 10m;
proxy_cache_lock on;                    # 启用锁机制
proxy_cache_lock_timeout 5s;            # 锁等待上限，超时后放弃等待直接回源
proxy_cache_lock_age 5s;                # （可选）锁存在时间，避免旧锁长期占用
proxy_cache_use_stale updating;         # 允许在更新缓存时返回旧内容，进一步降压

proxy_cache_lock_timeout 建议设为略大于正常回源耗时（如 3–8 秒），太短易失效，太长影响用户体验
proxy_cache_use_stale updating 很关键：当缓存正在被第一个请求更新时，其余请求可直接返回旧缓存，而非等待，极大减少阻塞
若后端支持 stale-while-revalidate（如通过 Cache-Control 头），可结合 proxy_cache_use_stale 更精细控制

配合防雪崩的必要补充措施

proxy_cache_lock 单独无法抵御大规模缓存集中过期或 Redis 整体宕机这类典型雪崩场景，必须叠加以下手段：

分散过期时间：在生成缓存 key 时加入随机偏移，例如 cache_key "$scheme$request_method$host$request_uri|$arg_v"; 中对 TTL 加 ±60 秒抖动
主动预热 + 缓存永不过期 + 后台异步刷新：高频接口缓存设为 long max-age，靠后台任务定期更新，避免自然过期
多级缓存：Nginx 本地缓存（proxy_cache）+ Redis 分布式缓存 + 应用内本地缓存（Caffeine/Guava），逐层降级
兜底限流：在 upstream 不可用时，用 limit_req 或 OpenResty 的 lua-resty-limit-traffic 控制最大回源请求数

验证是否生效的简单方法

可通过日志观察 proxy_cache_lock 行为：

开启 log_format 包含 $upstream_cache_status，命中缓存显示 HIT，回源显示 MISSEXPIRED 或 MISS
当出现 LOCK 状态，说明有请求被锁住等待；REVALIDATED 表示使用了 stale 内容
对比开启前后后端 access log 的 QPS 波动，尤其在缓存批量失效窗口期