先定义“什么峰值”
节假日峰值可能出现在开售瞬间、游客集中到园、短视频直播引流或天气变化后的集中退票。项目组应使用历史分钟级订单与核销数据，叠加活动计划形成基线、预期峰值和极端峰值三档模型。没有历史数据时，可先用可解释假设测量，再在真实运营后持续校准。
流量模型要覆盖完整业务混合
| 场景 | 重点观察 | 常见风险 |
|---|---|---|
| 查票与库存 | 缓存命中、库存新鲜度、热点票种 | 缓存击穿、显示有票但下单失败 |
| 创建订单 | 限购、优惠、库存锁定、幂等 | 超卖、重复单、锁库存不释放 |
| 支付回调 | 乱序、重复、延迟与补单 | 已付未出票、重复出票 |
| 渠道同步 | OTA 配额、限流、失败重试 | 渠道库存滞后 |
| 入园核销 | 票码查询、离线缓存、开闸结果 | 接口成功但排队仍增长 |
测试环境必须足够接近生产
数据库版本、索引、缓存容量、消息队列、网络拓扑和关键配置应与生产保持可比。测试数据要有真实分布：大量普通票、少量套票、会员票、团队票和异常票码。若所有请求都命中同一个简单票种，结果会过度乐观。外部支付与 OTA 不宜直接施压，可用经过确认的沙箱或模拟器复现延迟、失败和限流。
容量测试必须包含故障注入
- 让一个应用实例退出，验证负载是否自动摘除并恢复。
- 人为增加数据库延迟，观察连接池、超时和队列是否扩散。
- 清空热点缓存，验证预热和防击穿策略。
- 暂停一个外部接口，验证订单主链路是否隔离、是否出现无限重试。
- 模拟景区网络中断，验证闸机离线规则、缓存容量和恢复后的去重同步。
容量验收应绑定业务结果
除吞吐量和响应时间，还要核对测试前后的订单数、支付数、出票数、退款数、库存余额和核销数。每次测试记录版本、配置、数据规模、脚本、持续时间、资源曲线和瓶颈结论，才能判断优化是否真实有效。
数字边界：本文不提供通用 QPS、闸机通行或可用性承诺。容量目标必须根据景区规模、入口布局、产品复杂度和实际部署测量确定。