fastcgi_cache_lock的本质是控制缓存未命中时的并发穿透行为：仅首个请求回源，其余在nginx层阻塞最多5秒（硬编码不可配），待缓存生成后统一返回；需协同fastcgi_read_timeout、fastcgi_cache_valid和fastcgi_cache_use_stale updating才能生效。
fastcgi_cache_lock 的本质不是“处理压力”，而是控制缓存未命中时的并发穿透行为：当多个请求同时访问一个没缓存或已过期的 URL，它只放行第一个请求去后端，其余请求在 Nginx 层阻塞等待——等缓存写入后统一返回。这能降低瞬时压力，但效果取决于配置协同是否合理。
fastcgi_cache_lock 开启后的实际行为
- 启用
fastcgi_cache_lock on;后，Nginx 对同一缓存 key（如/article/123）的并发 miss 请求做串行化：- 第一个请求穿透到 PHP-FPM 执行并写缓存
- 其余请求不发往后端，也不立即失败，而是在 Nginx 内部排队等待
- 等待上限固定为 5 秒（源码硬编码，不可修改）
- 若 5 秒内首个请求完成并写入缓存，所有等待请求直接读缓存返回
- 若超时，等待请求全部失败（通常返回 503 或由
fastcgi_cache_use_stale降级）
它适合什么场景？
- 后端响应快（平均 ≤3 秒），且该页面被大量用户同时访问（如首页、活动页）
- 缓存 key 高度集中（相同 URL 被反复请求），避免锁粒度过细失效
- 已清理干扰头：用
fastcgi_ignore_headers Cache-Control Set-Cookie等，防止因响应头导致缓存不生效
它不适合什么场景？
- 后端有慢接口（如导出、聚合搜索、报表），执行时间常超 5 秒
- 第一个请求卡住 → 等待队列全超时 → 大量失败 + 客户端重试 → 连接堆积、RST 断连
-
fastcgi_read_timeout设置过短（比如设为 10 秒，但 PHP 实际要 20 秒）- Nginx 先中断首个请求 → 缓存未写入 → 后续请求继续 miss → 锁失效，击穿重现
- 存在动态 Cookie 或登录态，但未正确配置
fastcgi_cache_bypass和fastcgi_no_cache- 导致本该绕过缓存的请求被锁住，影响用户交互
真正缓解并发压力的关键组合
单靠 fastcgi_cache_lock 不够，必须配合以下三项：
-
fastcgi_read_timeout≥ 后端 P95 响应时间（如 PHP 最长需 25 秒，此值至少设 30 秒） -
fastcgi_cache_valid分层设置有效期，避免集中过期（例如首页 15m、分页 5m、搜索 60s） -
fastcgi_cache_use_stale updating error timeout http_500;-
updating是核心：缓存过期时允许先返回旧内容，后台异步刷新，既保可用又防穿透
-
不复杂但容易忽略
