测试缓存失效瞬间吞吐量需主动触发精准purge并毫秒级捕获流量变化：用ngx_http_cache_purge_module批量清除指定key，立即发起并发请求，通过$upstream_cache_status日志字段统计miss/bypass请求数换算穿透rps，同步观测响应时间突增幅度与后端5xx错误率。
要测试缓存失效瞬间的系统吞吐量，核心不是“等它自然失效”，而是主动触发可控的缓存失效事件，并在毫秒级时间窗口内捕获真实请求流量和后端压力变化。直接依赖 TTL 到期不可控、难复现、难对齐时间点，真正有效的做法是结合 Nginx 缓存机制特点，做有迹可循、可重复、可观测的压测。
明确缓存失效的两种典型场景
测试前必须区分清楚你关心的是哪一类失效：
- 被动失效：缓存过期（max_age / inactive）或后端响应携带 Cache-Control: no-cache 等头导致下次请求不命中；这类场景适合长期稳定性观察，但不适合“瞬间吞吐量”压测，因为时间点不可控、失效不集中。
- 主动失效：通过 purge 操作、reload 配置、或手动删除 keys_zone 元数据触发的批量/定向缓存清空；这才是测试“失效风暴”的黄金入口——你能精确控制失效发生时刻、范围和规模。
构造可测量的失效事件
推荐使用 按 key 精准 purge + 并发请求注入 的组合方式，避开 rm -rf 和 reload 带来的副作用（如共享内存残留、进程句柄未释放、全局抖动）：
- 确保 Nginx 已启用
ngx_http_cache_purge_module（需编译时加入），并在 location 中配置 purge 权限，例如：location ~ /purge(/.*) { allow 127.0.0.1; proxy_cache_purge cache_one $1$request_uri; } - 用 curl 触发 purge：curl -X PURGE "http://localhost/purge/api/posts/123"，确认返回 204；该操作会同步清理磁盘文件 + keys_zone 索引，无残留。
- 提前准备一批待失效的 URL 列表（如 100 个热点文章接口），用脚本批量 purge 后立即发起并发请求（例如 500 QPS 持续 5 秒），用时间戳对齐 purge 结束与压测开始。
采集失效瞬间的真实吞吐量
仅看 access.log 的 $request_time 或总请求数不够——你需要分离“缓存命中的请求”和“穿透回源的请求”，才能算出失效瞬间的有效后端吞吐量：
- 在 Nginx 日志中增加
$upstream_cache_status字段，例如：log_format cache_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_cache_status'; - 压测期间实时 tail 日志并过滤：awk '/MISS|BYPASS|EXPIRED/ {miss++} END {print "Back-end RPS:", miss/NR*10}'，其中 NR 是总请求数，假设压测持续 10 秒，即可换算出每秒穿透请求数（即后端真实吞吐量）。
- 配合后端监控（如 Prometheus 抓取 /metrics 中 http_requests_total{handler="api"} 和 http_request_duration_seconds_count{code=~"2.."}），交叉验证 Nginx 日志结果是否一致。
关键指标要同时看三项
单看 RPS 容易误判。缓存失效瞬间必须同步观测：
- 穿透 RPS：单位时间内 upstream_cache_status 为 MISS/BYPASS 的请求数，反映后端真实负载增量；
- 平均响应时间突增幅度：对比失效前 30 秒与失效后 10 秒的 $request_time P95，若从 15ms 涨到 320ms，说明后端已承压；
- 后端错误率：$upstream_status 为 5xx 的比例，若超过 2%，表明失效引发雪崩风险。
