用历史数据为五个链路分别建模
售票链路关注同时在线查询、选票、下单和支付的人数与转化率。支付回调关注第三方回传的并行量和延迟。库存同步关注渠道、窗口和分销商的共享库存读写的竞争条件。核销吞吐关注入口闸机的连续扫码速率和并发数。数据看板关注同时查询的管理人数和聚合延迟。
把去年同期的最高并发和增长比例转化为今年的测试模型，明确请求数量、持续时间、响应分位值和允许的失败率。不能只写支持百万并发，因为售票、核销和查询的资源消耗完全不同。
区分垂直扩容与水平扩容，测过才算
垂直扩容加CPU或内存存在上限；水平扩容通过增加实例、读写分离和消息队列分流。系统应在达到预设水位线时自动或经审批后扩容，并在压力下降后缩容以节省成本。
扩容演练比承诺更重要。在测试环境中用模型复现压力，观察瓶颈在哪里、新实例启动几秒、缓存命中率是否下降、数据是否一致、缩容时正在处理的请求是否丢失。没有压力测试数据的弹性只是形容词。
限流和降级保护核心链路
售票满负荷或支付接口延迟时，系统应限流新用户进入排队、返回明确等待提示而不是白屏，已在支付中的用户尽量完成。非核心功能如积分查询、海报生成在高峰期降级以释放资源。
限流策略写入运维手册，注明触发条件、限流参数、对游客的提示话术、排队超时处理和降级恢复步骤。非技术人员也能从监控大屏判断是否需要人工介入。
闸机是入园瓶颈而不是服务器
支付成功但闸机前堵了几百人，问题不在云端在入口。每个闸机的单位通行速率乘以闸机数决定理论吞吐量；实际还要扣除补扫、重试、证件核对和引导耗时。高峰期增加手持机和人工通道，不是只加服务器。
闸机本地缓存、断网模式和恢复补传在高峰压力下不能退化。压力测试包括闸机并发扫码、大量重复码、网络抖动和缓存溢出，不只是服务器压测。
监控要能看到真实瓶颈
监控分三组：业务指标关注实时售票、核销、退票和库存变化；技术指标关注CPU、内存、带宽、数据库连接、缓存命中、消息堆积和错误率；游客端关注页面加载时间、支付失败和排队时长。
建立告警、通知、响应、恢复、复盘闭环。告警不轰炸无关人员，每条告警标注严重程度、SOP链接和升级联系人。事后复盘必须回答瓶颈在哪、自动扩容有没有生效、降级是否有预期效果。
灾备切换不是换个地方宕机
多活或主备部署要在非高峰期实际切换测试：DNS或负载均衡是否正确指向备用站点，备用环境的数据是否完整、证书是否有效、第三方回调是否路由正确。切换后持续观察售票、核销、退款和对账。
回切也要演练。灾备站点累积了新订单，回到主站点时如何合并和重放，是否有重复和丢失。异地备份的数据恢复时间也要真实模拟。
常见问题 FAQ
高峰期的最大并发数应该怎么定？
取去年同期最高并发的若干倍加上增长预估，再为每个链路分别建模，单一数字不足以指导扩容。
云服务商的自动扩容够用吗？
自动扩容需要提前配置策略和测试；不测就不知道启动时间、数据库连接和缓存预热是否满足窗口。
高峰期关闭部分后台功能有效吗？
合理但需提前约定降级清单和恢复步骤，并确保不会关闭售票、核销和对账的核心链路。
压力测试每年一次就够吗？
每次重大版本更新、接口变更或新增渠道后都应重新跑核心场景的压测。