如何配置 proxy_cache_lock 机制在高并发回源瞬间防止后端源站被请求击穿-Nginx-PHP中文网

启用 proxy_cache_lock 可防止同 key 瞬时缓存未命中导致的回源击穿，需配合 cache_path、精准 cache_key、ignore_headers 和 stale 策略协同生效，压测验证后端请求量应显著降低。

如何配置 proxy_cache_lock 机制在高并发回源瞬间防止后端源站被请求击穿

配置 proxy_cache_lock 防止高并发回源击穿，关键不是“开了就行”，而是让锁真正覆盖住同一类请求，并确保它在缓存未命中（MISS）时能稳定介入。它本身不防穿透、不抗雪崩，只对「同 key 的瞬时 MISS」起作用——但这一场景恰恰是源站崩溃最常见的导火索。

没有缓存区，锁就无处落脚：

在 http 块中定义缓存路径和共享内存区，例如：
proxy_cache_path /var/cache/nginx/proxy_cache levels=1:2 keys_zone=my_cache:512m inactive=3h use_temp_path=off;
其中 keys_zone 名称（如 my_cache）后续会被引用，大小按每 1MB 支持约 8000 个 key 估算；use_temp_path=off 可避免临时文件拷贝，提升写入一致性。
确保磁盘路径存在且 Nginx 进程有读写权限（macOS/Linux 下尤其注意 SELinux 或目录 umask 限制）。

锁只在 cache miss 时生效，且仅作用于完全一致的缓存 key：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

启用缓存与锁：
```
proxy_cache my_cache;<br>proxy_cache_lock on;<br>proxy_cache_lock_timeout 5s;
```
超时建议设为 3–8 秒：太短，等待请求快速放弃锁并发回源；太长，用户明显卡顿，尤其后端响应慢时。
显式控制缓存 key，避免因 query 参数、header 差异导致锁失效：
默认 key 含 $args，/api/user?id=1 和 /api/user?id=2 就是两个独立锁。
若需统一锁定某类接口，可自定义：
proxy_cache_key "$scheme$host:/api/user";
或剥离干扰项：
proxy_cache_key "$scheme$host$request_uri";（忽略所有 query 参数）
忽略无关响应头，防止缓存被跳过：
proxy_ignore_headers Set-Cookie Vary;
否则带 Set-Cookie 的响应默认不缓存，锁也形同虚设。

光靠锁等结果，不如让旧缓存“活”得更久一点：

启用 stale 回退：
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
当首个请求回源失败、超时或正在更新时，后续请求可直接返回旧缓存（stale），既减少等待，又避免全部降级失败。
延长热点资源有效期：
```
proxy_cache_valid 200 302 30s;<br>proxy_cache_valid 404 10s;
```
MISS 越少，锁竞争越弱；对 API 接口设 30 秒已足够缓解瞬时压力。

别信配置，要看行为：

加响应头便于观测：
add_header X-Cache-Status $upstream_cache_status;
用 curl -I 查看：首次应为 MISS，紧随其后的并发请求若返回 HIT 或 UPDATING，说明锁已阻塞并复用结果。
压测验证后端访问量：
用 ab -n 20 -c 10 http://your-site/api/hot 并观察后端 access log —— 开启 lock 后，应只记录 1 条（或极少数）请求，而非 10 条。