nginx缓存本身不提供高可用，需通过缓存冗余、代理层容灾、健康感知及分级缓存等机制嵌入整体容灾架构，配合stale策略、降级页面与监控清理，才能支撑高可用与容灾。
单纯配置 Nginx 缓存（如 proxy_cache）本身不直接提供高可用或容灾能力，它解决的是响应加速和后端减压问题。要让缓存真正支撑高可用与容灾，必须将其嵌入到整体容灾架构中——即：缓存需在故障发生时仍能持续服务，且不因单点失效导致全链路中断。核心思路是“缓存冗余 + 代理层容灾 + 健康感知”。
缓存节点自身不能是单点
如果只在一台 Nginx 上启用缓存，该节点宕机，不仅服务中断，已缓存的内容也全部丢失，无法降级服务。正确做法是：
- 在多个 Nginx 反向代理节点上**独立启用相同缓存配置**（共享同一套缓存路径结构、key 规则、过期策略），但不共享物理缓存存储（避免锁竞争与一致性难题）；
- 配合 Keepalived 或 DNS 轮询，使客户端流量分散到多个带缓存的 Nginx 实例；
- 即使某台 Nginx 故障，其余节点仍可各自提供缓存响应，实现“缓存级冗余”。
缓存需配合 upstream 容灾策略生效
缓存是否有效，取决于请求能否被成功转发并收到响应。若后端全挂，Nginx 默认不会缓存 5xx 错误（除非显式开启）。要保障极端情况下的可用性，需主动配置容错缓存：
- 启用
proxy_cache_use_stale，允许在后端异常时返回过期缓存：
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; - 搭配
proxy_cache_lock on防止缓存失效时大量并发回源压垮后端； - 设置
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504，确保请求自动重试其他健康后端，提升缓存命中的概率。
缓存内容应具备“降级友好性”
不是所有内容都适合缓存，也不是所有缓存都该长期保留。为支撑容灾，需按业务等级分级缓存：
-
静态资源（CSS/JS/图片）：设置长 TTL（如 1 年），并配合版本化 URL（
/v2.3.1/app.js），确保可安全长期缓存； -
动态页面（列表页、详情页）：设置较短 TTL（如 5–30 分钟），并启用
stale-while-revalidate机制（通过Cache-Control: stale-while-revalidate=30响应头 + Nginx 的proxy_cache_background_update on）； - 兜底页面（50x 错误页）：单独缓存定制化的维护页，当所有后端不可用时，由 Nginx 直接返回本地缓存的 HTML，实现“有内容的中断”。
监控与自动清理保障缓存可靠性
缓存堆积、磁盘满、索引损坏都会导致 Nginx 拒绝缓存或返回错误。必须建立基础运维闭环：
- 使用
proxy_cache_path的inactive和max_size参数自动清理旧缓存（例如：inactive=30m max_size=10g）； - 通过
log_format记录$upstream_cache_status，区分 HIT / MISS / EXPIRED / STALE / BYPASS，用于识别缓存健康度； - 定期检查
proxy_cache_valid是否覆盖关键状态码（如对 200/301/302 设置不同缓存时间），避免错误响应被意外缓存。
