测试缓存过期瞬间后端并发压力，核心是精准触发大量请求同时穿透缓存并集中回源，需通过proxy_cache_valid设定短有效期、禁用updating、同步多波wrk压测、确保相同cache_key及开启proxy_cache_lock，并直采后端qps、连接池、线程与错误率等指标验证承压能力及锁/降级策略有效性。
测试缓存过期瞬间的后端并发压力，核心是精准触发“大量请求同时穿透缓存、集中回源”的场景，验证后端能否承受瞬时峰值流量。不能靠自然过期等待，必须主动控制时间点与请求节奏。
构造可控的缓存过期时间点
在 Nginx 配置中显式设定短且确定的缓存有效期，便于同步压测：
- 用 proxy_cache_valid 固定响应码的缓存时长，例如
proxy_cache_valid 200 302 5s;，让所有成功响应只缓存 5 秒 - 禁用 proxy_cache_use_stale 中的
updating（除非你明确要测试后台更新行为），避免 Nginx 自动启用旧缓存掩盖穿透 - 确保后端响应不带
Cache-Control: no-cache或max-age=0，否则 Nginx 会跳过缓存
同步发起穿透请求，制造“雪崩窗口”
在缓存即将过期前 1 秒发起多批次请求，使它们几乎在同一毫秒内到达 Nginx 并全部判定为需回源：
- 用 wrk 启动两波请求：第一波在缓存剩余 1.2 秒时发出（如
wrk -t4 -c200 -d1s http://host/api），第二波紧随其后（间隔 0.3 秒） - 所有请求必须使用完全相同的 proxy_cache_key（例如统一忽略参数：
proxy_cache_key "$scheme$host$uri";），确保它们竞争同一个缓存项 - 确认 Nginx 已开启 proxy_cache_lock on，否则你会看到大量重复回源；若关闭 lock，则直接观察无保护下的真实并发冲击
重点观测后端的真实承压表现
不要只看 Nginx 日志或平均延迟，要直连后端侧采集关键信号：
- 后端 QPS 突增幅度：对比缓存有效期内的后端 QPS（应接近 0），和过期瞬间的 QPS（理想值应 ≈ 压测并发数 × 请求频率，如 c200 → 后端每秒收到约 180–200 次请求）
- 数据库连接池状态：检查连接是否打满、出现 wait_timeout 或 rejected connection；若有连接池监控（如 HikariCP 的 active、idle、pending），此时 pending 队列应明显拉长
- 应用线程堆积：观察 JVM 线程数、CPU user 时间占比、GC 频率是否陡升；Python/Go 服务则看 goroutine 数或 event loop 阻塞情况
- 错误率拐点：5xx 错误是否在过期后第 1–2 秒内突然跳升（如从 0% → 8%），说明熔断或超时机制未生效
验证缓存锁与降级策略是否生效
这是区分“有防护穿透”和“裸奔穿透”的关键：
- 开启 proxy_cache_lock 后，应观察到：Nginx access log 中
$upstream_cache_status字段在过期窗口内多数为MISS，但只有第一个请求记录upstream_addr，其余请求的upstream_response_time显著更短（复用锁释放后的结果） - 若配置了 proxy_cache_use_stale error timeout updating，可在压测中手动 kill 一个后端实例，再触发过期请求——此时应返回 STALE 缓存，而非全量 502/504
- 配合 Lua 或 OpenResty，在回源前注入限流逻辑（如基于 redis 计数器），验证是否能在穿透瞬间拦截超额请求
