在 linux 环境中，nginx 处理缓存失效时的并发回源风暴主要依靠 proxy_cache_lock 机制配合合理的 proxy_cache_valid 和过期策略来实现。开启锁功能后，当多个请求同时发现缓存未命中时，只有第一个请求会发起回源，其余请求会在本地排队等待该请求完成并获取结果，从而避免大量并发请求直接击穿后端服务。
Nginx 中 proxy_cache_lock 的具体配置方法是什么
要启用 Nginx 的缓存锁功能，需要在 http 或 server 块中设置 proxy_cache_lock on，并建议搭配 proxy_cache_lock_timeout 防止请求无限期等待。这样配置后，Nginx 会将同一资源的并发未命中请求合并为一个回源动作，其他请求阻塞等待直到缓存写入完成。
server {
listen 80;
server_name example.com;
location /api/ {
# 定义缓存路径、级别和名称
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
# 开启缓存
proxy_cache my_cache;
# 关键配置：开启缓存锁
proxy_cache_lock on;
# 设置等待锁的最大超时时间，避免客户端长时间挂起
proxy_cache_lock_timeout 5s;
# 设置缓存有效期
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
# 后端服务地址
proxy_pass http://backend_server;
# 设置缓存键，通常使用 URL
proxy_cache_key $scheme$request_method$host$request_uri;
}
}
上述配置中，proxy_cache_lock on 是核心指令。当缓存键对应的资源不存在或已过期时，Nginx 会检查是否已有正在进行的回源请求。如果有，新到达的请求将被阻塞（处于 WAITING 状态），而不是立即发起新的 TCP 连接到后端。如果等待超过 proxy_cache_lock_timeout 设定的时间，Nginx 将放弃等待，直接向客户端返回错误（通常是 504 Gateway Timeout 或根据 proxy_next_upstream 处理的错误）。这种机制有效地将高并发的“回源风暴”收敛为单点回源，保护了后端应用服务器。
如何结合 proxy_cache_lock 优化后端压力与用户体验
仅开启锁功能可能导致部分用户因等待超时而失败，因此需要结合 proxy_cache_lock_timeout 和 proxy_cache_use_stale 进行综合调优。通过设置合理的超时时间和允许使用陈旧缓存，可以在保证后端安全的同时，提升大多数用户的访问成功率。
# 在 location 块中补充以下配置以优化体验 # 1. 调整锁等待超时时间，根据业务容忍度设定 # 如果后端响应很快，可以设短一些；如果后端较慢，需适当延长 proxy_cache_lock_timeout 3s; # 2. 允许在缓存更新期间使用陈旧缓存（Stale Cache） # 当缓存过期且正在回源更新时，如果回源超时或失败， # 可以返回过期的缓存内容，而不是直接报错 proxy_cache_use_stale updating error timeout invalid_header http_500 http_502 http_503 http_504; # 3. 可选：设置 stale_while_revalidate 和 stale_if_error # 这些是更细粒度的控制，允许在特定条件下使用旧数据 # 注意：proxy_cache_use_stale 是较老的方法，新版 Nginx Plus 或特定模块支持更精细的 stale 控制 # 对于开源版 Nginx，proxy_cache_use_stale updating 是关键 proxy_cache_use_stale updating; # 4. 确保缓存键的一致性，避免锁失效 # 如果不同参数导致不同的缓存键，锁只会针对相同的 key 生效 proxy_cache_key $scheme$request_method$host$request_uri;
在实际部署中，proxy_cache_lock 解决了“谁去回源”的问题，而 proxy_cache_use_stale updating 解决了“回源期间用户看到什么”的问题。当缓存失效触发回源时，Nginx 会启动一个后台线程去更新缓存。在此期间，其他请求如果因为某种原因（如锁超时）无法获得最新数据，可以根据 proxy_cache_use_stale 的配置，选择返回旧的缓存内容。这极大地提升了系统的鲁棒性。此外，proxy_cache_lock_timeout 的值需要根据后端服务的平均响应时间来设定。如果后端响应时间在 1 秒以内，锁等待时间设为 2-3 秒通常足够；如果后端较慢，可能需要调整架构，例如引入 Redis 等外部缓存层来分担 Nginx 的缓存压力，或者使用更复杂的缓存预热策略。
当 proxy_cache_lock 遇到动态内容或个性化请求时如何处理
proxy_cache_lock 的作用范围严格基于 proxy_cache_key。如果请求包含个性化参数（如用户 ID、Session ID），导致每个请求的缓存键都不同，那么锁机制将完全失效，因为每个请求都被视为独立的资源。在这种情况下，必须重新设计缓存策略，要么排除个性化参数，要么采用分层缓存或边缘计算方案。
# 示例：错误的缓存键设置，导致锁失效
# 假设 request_uri 中包含 ?user_id=123
# 每个用户的请求都会产生唯一的 key，无法共享锁
proxy_cache_key $scheme$request_method$host$request_uri;
# 修正：排除查询参数中的个性化部分，只缓存公共内容
# 使用 map 指令清理 URI
map $request_uri $clean_uri {
~^(/api/public/.*)$ $1;
default $request_uri;
}
# 使用清理后的 URI 作为缓存键
proxy_cache_key $scheme$request_method$host$clean_uri;
当业务场景涉及大量个性化内容时，proxy_cache_lock 的保护作用微乎其微。开发者应首先分析哪些接口是真正需要缓存的。对于 API 接口，通常只有 GET 请求且无敏感参数的才适合缓存。如果必须缓存带参数的内容，应确保这些参数不影响缓存内容的通用性，或者将个性化部分剥离出缓存键。另一种高级做法是使用 Nginx 的 sub_filter 或 Lua 模块（OpenResty）在边缘层进行动态拼接，但这超出了原生 Nginx 缓存锁的范畴。总之，proxy_cache_lock 是解决静态或半静态资源并发回源的有效手段，但对于高度动态的内容，需要从架构层面重新评估缓存策略。
