构造可复现流量
验收不能用随机请求，要按真实分布构造重复率与长尾比例。怎么做：从历史日志抽样并按业务线配比，固定随机种子；边界是流量模型要与生产同构，否则命中率结论无法外推，压测通过也不代表线上有效。
穿透与雪崩
清空缓存后瞬间打入全量请求，观察后端是否被打满、限流是否生效。为什么必测：缓存故障时后端要承接全部流量，这是最容易被忽略的容量缺口。通过标准是错误率与延迟在上限内，且限流能按租户生效。
路由故障注入
让主模型超时、返回错误或限流，检查是否切到备用并按预案提示。怎么做：分别测单次失败与持续失败，并记录每次切换的实际耗时；边界是重试要有上限与退避，否则故障期间请求被放大，备用侧也会被打垮。
隔离与一致性
用不同租户与角色的样本交叉请求，确认不会读到他人缓存；再更新知识与权限，验证旧条目是否按约定失效。为什么合并：两类问题都靠样本验证，且都要在压测后复查。边界是允许短暂不一致时要写清时长与提示方式。
适用与不适用
适合谁
- 正在做缓存或网关上线验收的项目组
- 要向外方或上级证明优化有效的平台团队
- 承担多租户服务、需要验证隔离的服务商
不适合谁
- 只有演示环境、没有历史流量可用于构造模型的团队
- 不接受压测占用资源、只想看功能是否可用的项目
典型场景
某银行客服系统在上线前做验收：先用历史日志构造带重复率的流量，测出命中与后端压力；再清空缓存做穿透测试，发现限流只按全局配置，补了租户级限额；最后用两个角色的同问题样本验证隔离，确认不会串答案，验收记录随变更单一并归档。
可执行步骤
- 从历史日志抽样构造流量模型，固定随机种子、样本清单与配比口径
- 测命中率与后端压力，记录分位延迟、资源水位与错误率的变化曲线
- 清空缓存做穿透与雪崩测试，验证限流是否按租户生效并记录恢复过程
- 注入路由超时与错误，验证切换与退避，并记录用户可见提示与耗时
- 用越权样本与知识更新验证隔离与失效，留存可审计的记录与最终结论
常见坑
- 用随机请求压测，重复率远低于真实业务，命中率虚高，上线后的实际效果与验收结论对不上号。
- 没有做穿透测试，缓存故障当天后端就被打满，业务全面不可用，恢复时间也远超预期与预案。
- 重试没有上限，主模型超时后请求成倍打到备用，故障范围扩大，原本可用的模型也跟着过载下线。
- 只测功能不测隔离，跨租户返回同一答案，属于严重数据问题，事后追责时很难说清责任归属。
自检与验收清单
- 流量模型是否与生产同构，是否固定了随机种子
- 是否做过清空缓存的穿透与雪崩测试并记录结果
- 重试是否有明确上限、退避策略与降级开关项
- 是否用越权与跨角色的样本验证过多租户隔离
- 缓存失效的验证是否留下了可审计的完整记录
常见问题
压测要打多少流量？
按真实业务的峰值与重复率构造，覆盖到峰值的一到两倍即可。关键是与生产同构，而不是把数字做大。流量模型失真时，命中率与延迟结论都无法外推，验收通过也说明不了线上表现。
缓存故障时能降级吗？
可以，但要提前设计并验证：关闭语义缓存、改为直连、限制单租户并发、必要时返回排队提示。降级路径需要定期演练，否则真正故障时会发现开关没人会用，或者降级之后仍然超时。
隔离测试怎么造样本？
准备同一问题、不同租户与角色的账号，交叉请求并比对返回内容；再修改其中一个租户的权限，观察缓存是否失效。样本要覆盖公共知识与私有数据两类，避免只测其中一种就下结论。