Nginx缓存容灾需分级响应、错峰过期、静默刷新与可信降级：仅对502/503/504启用proxy_cache_use_stale，配proxy_cache_valid覆盖错误响应，用background_update+cache_lock防并发回源，通过key归并与时间扰动打散过期。
后端网络抖动（如延迟飙升、偶发超时、502/504 频发）不是彻底宕机，但足以让大量请求穿透缓存、压垮上游。Nginx 缓存容灾的关键，是不让“抖动”变成“雪崩”——核心在于分级响应、错峰过期、静默刷新与可信降级。
只对真实抖动信号启用 stale 容灾
盲目开启 proxy_cache_use_stale error timeout 会把瞬时抖动误判为故障，导致用户持续看到陈旧内容。应聚焦后端明确反馈的异常：
- 必须启用：
http_502 http_503 http_504—— 这三类是网关层确认的服务不可用信号，抖动中高频出现且语义可靠 - 建议启用：
updating—— 配合后台刷新，让缓存过期时也能平滑过渡 - 慎用或不用：
error（DNS 失败、连接拒绝等底层中断）和timeout（单次读超时），除非你确认它们稳定对应节点级故障
让缓存本身扛得住抖动冲击
stale 是“复用者”，不是“创造者”。若缓存没存住、找不到或刚生成就被清掉，容灾就无从谈起：
- 确保
proxy_cache_valid显式覆盖错误响应：proxy_cache_valid 502 503 504 1m;，否则 5xx 根本不进缓存，stale 就无旧内容可返 - 主响应也要设合理有效期：
proxy_cache_valid 200 302 10m;，避免因inactive时间过短（如 1m）导致缓存未等抖动发生就已淘汰 - 缓存键必须稳定：
proxy_cache_key "$scheme$host$request_uri";，剔除$args、$time_iso8601等动态干扰项，防止同一页面分裂出成百上千个 key，放大击穿风险
用静默刷新 + 锁机制防并发回源
抖动常引发大量请求同时判定“缓存过期”，若全部放行回源，瞬间流量洪峰会直接拖垮后端：
- 开启异步刷新：
proxy_cache_background_update on;，让 Nginx 在返回 stale 内容的同时，后台悄悄拉新数据 - 启用缓存锁：
proxy_cache_lock on; proxy_cache_lock_timeout 3s;，同一 key 下仅首个请求触发刷新，其余在 3 秒内等待；超时则继续返回当前缓存（含过期内容），不重试、不穿透 - 二者必须配合：没有
background_update，updating条件永不满足；没有cache_lock，多个并发可能同时刷爆上游
主动打散过期时间，避免整点雪崩
固定 TTL（如统一 5m）会让大量缓存整点集体失效，在抖动期间形成“失效风暴”：
- 按路径归并 key：
proxy_cache_key "$scheme$host$request_uri";，将带不同参数的同类请求合并为一个缓存单元，显著降低 key 总量和过期密度 - 嵌入小时扰动：
proxy_cache_key "$scheme$host$request_uri $time_iso8601_hour";，让缓存自然按小时轮换，避开秒级/分钟级集中失效 - 业务层配合更优：让后端响应头带
Cache-Control: max-age=300, stale-while-revalidate=60，Nginx 自动识别并执行静默刷新，比硬编码更灵活
不复杂但容易忽略
