压测缓存策略需构造非法参数流量验证穿透拦截、集中失效+高并发验证雪崩防护，并通过upstream_cache_status等指标实时监控效果。
直接压测缓存策略本身没意义，关键是在高并发场景下验证它是否真能拦住穿透和雪崩。核心思路是：构造两类攻击流量，观察 Nginx 是否按预期拦截或缓冲，而不是让请求打穿到后端。
模拟缓存穿透：用非法参数批量刷接口
穿透的本质是查“根本不存在的数据”，比如商品 ID 为负数、超长乱码、或已下架商品的 ID。测试时不能只靠真实业务数据，要主动构造：
- 用脚本生成大量非法 ID（如 -1、9999999999、abc123），对同一接口发起并发请求（例如 5000 QPS）
- 检查 Nginx 日志：命中 404 且无 upstream 记录，说明 Lua 校验生效并提前返回；若出现大量 502/504 或 upstream_time 明显增长，说明请求已穿透到后端
- 确认 Redis 中对应 key 没有被写入空值或元数据（避免误判为“空值缓存”生效）
触发缓存雪崩：集中失效 + 高并发回源
雪崩不是等自然发生，而是人为制造“大量 key 同时过期+瞬间高并发”的组合条件：
- 配置一批缓存（如 /api/product?id=1001～10000），统一设为 proxy_cache_valid 200 60s，确保它们在同一分钟内全部失效
- 在过期前 1 秒发起突发流量（如 3000 请求/秒），观察 Nginx 的 proxy_cache_lock 是否起作用：只有第一个请求回源，其余应等待并复用刚写入的缓存
- 对比开启/关闭 proxy_cache_lock on 时的后端 QPS —— 关闭时后端可能突增数千请求，开启后应稳定在个位数
验证 key 打散效果：看过期是否错峰
如果用了分片或时间扰动策略，得验证它是否真把压力分散开了：
- 启用 proxy_cache_key "$scheme$host$request_uri $shard_bucket" 后，用不同 ID 请求（如 id=1001、1005、1009），检查 access.log 中的 $upstream_cache_status 字段：相同 $shard_bucket 值的请求应共享缓存，不同 bucket 的过期时间应相差明显
- 用 $time_iso8601_hour 扰动时，每小时切换一次 key，可人工在整点前后各抓一次缓存目录（如 /var/cache/nginx/），确认文件数量是否平滑过渡而非突增突减
监控必须盯紧的几个指标
光看日志不够，得结合实时指标判断防护是否有效：
- upstream_cache_status：关注 MISS 和 BYPASS 比例，持续高于 5% 就说明缓存策略未覆盖到位
- 后端响应时间与错误率：穿透或雪崩防护生效时，后端 RT 应基本平稳，5xx 错误不应随压测流量线性上升
- Nginx worker 连接数与 CPU：若 cache lock 大量阻塞，worker 可能堆积连接，CPU 却不高 —— 这是锁机制正在起作用的信号，不是故障
