核心是验证缓存失效时系统稳定性、响应可控性、回源准确性与切换无感性；需覆盖主动/被动/配置/运行时四类失效路径，并通过响应头与后端日志确认回源正确及时。
生产环境中验证 Nginx 缓存失效处理与高可用演练，核心不是“能不能缓存”，而是“缓存失效时系统是否仍稳定、响应是否可控、回源是否准确、切换是否无感”。重点在于模拟真实故障场景并观测关键链路行为。
一、明确缓存失效的典型触发路径
验证前先理清哪些操作或异常会导致缓存不可用：
-
主动失效：手动删除 proxy_cache_path 目录下缓存文件、执行
proxy_cache_purge指令（需启用 ngx_http_cache_purge_module） -
被动失效：
max_age过期、后端返回Cache-Control: no-cache或no-store、状态码非 200/206/301/302（默认不缓存） -
配置失效：修改
proxy_cache_valid规则后未重载、proxy_cache_bypass条件命中导致跳过缓存 -
运行时失效：磁盘满（
proxy_cache_path所在分区使用率 ≥95%）、Nginx worker 进程异常退出、共享内存区（proxy_cache_path ... keys_zone）损坏
二、验证缓存失效后的服务连续性
缓存层失效 ≠ 服务中断。应验证后端能否被正确、及时、受控地回源：
- 用
curl -I检查响应头：X-Cache: MISS或X-Cache: EXPIRED出现时，确认后端日志有对应请求（如 Tomcat access_log），且响应时间在合理范围（比如 - 人为制造后端延迟（如在 upstream 中加
proxy_connect_timeout 1s; proxy_read_timeout 1s;并临时堵住后端），观察 Nginx 是否按proxy_next_upstream error timeout http_500;正确重试或降级 - 关闭所有后端服务器，检查 Nginx 是否返回预设的
error_page 502 /50x.html页面，而非空白或超时，确保兜底能力生效
三、高可用演练：缓存节点单点故障下的行为观测
Nginx 本身不负责缓存数据同步，但其所在节点宕机会影响本地缓存命中。需结合 Keepalived 验证整体入口层韧性：
- 在主 Nginx 节点上执行
systemctl stop keepalived，观察 VIP 是否在 3–5 秒内漂移到备节点；用ip a | grep inet和持续ping VIP确认无丢包 - VIP 切换后，立即发起缓存资源请求（如
/static/logo.png），检查响应头中X-Cache是否为HIT（说明备节点已有热缓存）或MISS（冷启动正常），而非 502/504 - 对比切换前后 QPS、P95 延迟、错误率（通过 Prometheus + Grafana 或 Nginx stub_status），确认无明显抖动或雪崩
四、缓存策略有效性验证（配合 Cache-Control）
缓存是否“高可用”，也体现在客户端和中间层是否真正遵守策略：
- 对静态资源（
.js/.css/.png）发起请求，用curl -I查看响应头：Cache-Control: public, immutable, max-age=31536000应存在，且Age头随时间递增 - 对动态接口（如
/api/v1/user）发起两次请求，确认第二次响应头含Cache-Control: no-cache且Age为 0，同时X-Cache为MISS或BYPASS - 修改后端返回的
Cache-Control值（如从max-age=60改为max-age=10），观察 Nginx 是否在 10 秒后自动回源，验证proxy_cache_valid与响应头的优先级逻辑（后者优先）
不复杂但容易忽略的是：缓存高可用不是靠“永远不失效”，而是靠“失效时可预期、可监控、可承接”。每次演练后，务必检查 Nginx error.log 中是否有 upstream cache miss 异常、cache manager process 报错，以及磁盘 I/O 等基础指标是否健康。
