景区售票系统为什么要在高峰压测？实测 10 万并发到底压出了什么

先给结论：压测不是秀数字，是提前暴露高峰期真实风险

很多景区只在『买票那一刻』关心系统快不快，却忽略了两件事：一是秒杀式抢票瞬间的数据库压力，二是检票口闸机核销的并发吞吐。这两处的瓶颈完全不同，压测要分开压。

做一场有效压测至少覆盖四类场景：购票下单压测、支付回调压测、闸机核销压测、库存扣减压测。缺了任何一类，高峰期都可能出现『订单能下、票出不来』或者『闸机卡在门口排长队』的局面。

第一步：先想清楚高峰期到底哪些环节会挤

压测前先对着自己景区画一张高峰期流量图：游客会从哪些入口下单——小程序、OTA、窗口、自助机；每个入口在上午 9-11 点这个集中到达窗口，大约会承载多少并发请求；闸机口在开园那一刻会同时涌进多少人。

这张图决定你压测的『施压分布』。如果 80% 的票走 OTA 分销，你却把大部分压力放在自营小程序上，测出来的结论不反映真实瓶颈。建议按真实渠道占比分配压测流量。

同时要标出关键水位线：门票库存还剩多少时触发告警、支付超时多少秒判定失败、闸机核销单机每秒最多过多少人。这些数字先定下来，压测结果才有比较基准。

第二步：一场可复现的压测怎么做，分四步走

压测不是随机猛按请求，而是按『渐变加压』原则推进。先把并发从 100 起步，每 30 秒翻一倍，观察响应时间曲线拐点出现在哪里——拐点就是系统接近极限的位置，比直接打满更安全也更说明问题。

第二个关键是『真实请求比例』。不要只压一个查询接口，要把下单、支付、退票、改签、查库存这些请求按真实用户操作比例混合压，因为混合负载下的表现才接近实际高峰。

第三个关键是『端到端』。压测最后一步要走完整链路：游客下单→支付成功→生成票码→闸机扫码核销→数据库回写。很多系统单接口响应快，一旦走完整链路，某个中间环节（比如票码生成、短信推送）就成了瓶颈。

第四步是记录基线：每轮压测把并发数、TPS、平均响应、错误率、CPU/内存/数据库连接数全部落表，方便压完复盘。没有基线记录的压测，等于白压。

第三步：这些指标才是压测真正要盯的

别只看『并发数很高』。真正要盯的核心指标是：订单成交的 TPS 和它的错误率、支付成功到票码可用的延迟、闸机核销的吞吐与单次核销耗时、库存扣减是否出现超卖。

举一个典型例子：某景区乐观估计自己 10 万并发很稳，但压测发现真正瓶颈在库存扣减——同一张票多人抢购时数据库行锁竞争严重，导致订单成功率骤降。这类问题不压测永远发现不了。

建议定三个红色红线：错误率连续超过 1%、下单到出票延迟超过 5 秒、核销丢单数大于 0。只要触线就判定这一档容量不达标，哪怕并发数字再好看也不能上线。

第四步：压测最容易踩的几个坑

第一个坑是『只压应用不压数据库』，测完发现数据库连接被打爆、主从同步延迟到分钟级。压测一定要连带数据库和缓存一起压，别跳过存储层。

第二个坑是『没做库存与超卖验证』。高峰最怕超卖——闸机扫了没票、游客退款和重购叠一起导致错账。压测要专门制造并发抢同一库存的极端场景。

第三个坑是『压测环境与生产不一致』。测试机比生产的配置高很多，测出来的结论搬到生产就失效；建议尽可能用规格一致的环境。

第四个坑是『高峰期临时改规则』。压测发现扛不住，不该靠现场手改配置应急，而应该提前规划分流、限购、排队放号，把规则写进系统而不是靠人喊。

压测结果怎么用：从数字到上线决策

压测产出的不是一份报告，而是一张容量规划表：每个并发档位对应能承载多少游客、需要多大带宽、多少台应用实例、数据库连接池调到多少。这张表直接决定高峰前的扩容预算和架构调整。

对景区而言，压测的价值是把『不确定的高峰』变成『数字化的预案』：知道 5 万客流稳不稳、10 万客流要不要限流、什么时候该开分流通道。心里有数，节假日加班才不慌。

常见问题 FAQ

参考来源与事实边界

1. 1. 趣买票·景区票务系统压测方案
2. 2. 高并发系统设计公开资料