Nginx 中 fastcgi_cache_lock 处理后端并发响应压力

fastcgi_cache_lock的本质是控制缓存未命中时的并发穿透行为：仅首个请求回源，其余在Nginx层阻塞最多5秒（硬编码不可配），待缓存生成后统一返回；需协同fastcgi_read_timeout、fastcgi_cache_valid和fastcgi_cache_use_stale updating才能生效。

fastcgi_cache_lock 的本质不是“处理压力”，而是控制缓存未命中时的并发穿透行为：当多个请求同时访问一个没缓存或已过期的 URL，它只放行第一个请求去后端，其余请求在 Nginx 层阻塞等待——等缓存写入后统一返回。这能降低瞬时压力，但效果取决于配置协同是否合理。

fastcgi_cache_lock 开启后的实际行为

1. 启用 fastcgi_cache_lock on; 后，Nginx 对同一缓存 key（如 /article/123）的并发 miss 请求做串行化：
   1. 第一个请求穿透到 PHP-FPM 执行并写缓存
   2. 其余请求不发往后端，也不立即失败，而是在 Nginx 内部排队等待
   3. 等待上限固定为 5 秒（源码硬编码，不可修改）
   4. 若 5 秒内首个请求完成并写入缓存，所有等待请求直接读缓存返回
   5. 若超时，等待请求全部失败（通常返回 503 或由 fastcgi_cache_use_stale 降级）

它适合什么场景？

1. 后端响应快（平均 ≤3 秒），且该页面被大量用户同时访问（如首页、活动页）
2. 缓存 key 高度集中（相同 URL 被反复请求），避免锁粒度过细失效
3. 已清理干扰头：用 fastcgi_ignore_headers Cache-Control Set-Cookie 等，防止因响应头导致缓存不生效

它不适合什么场景？

1. 后端有慢接口（如导出、聚合搜索、报表），执行时间常超 5 秒
   1. 第一个请求卡住 → 等待队列全超时 → 大量失败 + 客户端重试 → 连接堆积、RST 断连
2. fastcgi_read_timeout 设置过短（比如设为 10 秒，但 PHP 实际要 20 秒）
   1. Nginx 先中断首个请求 → 缓存未写入 → 后续请求继续 miss → 锁失效，击穿重现
3. 存在动态 Cookie 或登录态，但未正确配置 fastcgi_cache_bypass 和 fastcgi_no_cache
   1. 导致本该绕过缓存的请求被锁住，影响用户交互

真正缓解并发压力的关键组合

单靠 fastcgi_cache_lock 不够，必须配合以下三项：

1. fastcgi_read_timeout ≥ 后端 P95 响应时间（如 PHP 最长需 25 秒，此值至少设 30 秒）
2. fastcgi_cache_valid 分层设置有效期，避免集中过期（例如首页 15m、分页 5m、搜索 60s）
3. fastcgi_cache_use_stale updating error timeout http_500;
   1. updating 是核心：缓存过期时允许先返回旧内容，后台异步刷新，既保可用又防穿透

不复杂但容易忽略