景区票务系统的全链路压测与容量评估：旺季前夜，到底压多狠才敢放闸？｜中科智旅景游宝
五一前一周，我们那套中科智旅景游宝的智慧景区景区票务系统连着三晚都在跑压测。第一晚结果出来，主库 CPU 直接打到 92%，运维群里炸了锅。那会儿我才明白一件事：压测不是"压一下看会不会挂"，而是要在开闸之前，把"到底能扛多少、扛不住先保谁"这俩问题彻底想清楚。
这篇文章不聊某个压测工具怎么装，只讲景区票务这类"读多写也多、峰值极其集中"的系统，全链路压测和容量评估到底该怎么设计。全是踩坑换来的，希望对做景区票务的后端同学有点用。
为什么要"全链路"压测？接口压测骗了你
很多人以为压测就是给几个核心接口灌流量。真到旺季你会发现，单接口压测的数据毫无参考价值。为什么？因为一次下单，会同时打主库、写 Redis、发 MQ、调支付、扣库存、推 WebSocket——你以为在测下单接口，其实在测一整套链路的极限。
我们第一年就吃过亏：给购票接口单独压，P99 漂亮得很，结果五一当天库存扣减和支付回调一叠加，Redis 连接池先被打爆，游客下单全部排队。**全链路压测的意义，是把你整个系统的"瓶颈链条"拉出来跑一遍，看最薄的那环在哪。**单测接口只是局部麻醉，全链路才摸到真病灶。
容量怎么估？先建一个"旺季模型"
压测之前，必须先回答"这次要压到多少 QPS"。拍脑袋不行，得建模。我们的做法是拿历史数据算：
- 取去年同节假日的高峰曲线，找到峰值时段（一般是开园前 1 小时和 9 点-11 点）的 QPS、TPS、并发在线数。
- 按今年预计游客增量（我们看闸机预约数和票务预售量）乘一个系数，得出目标峰值。
- 再叠加突发系数（比如开票瞬间的秒杀、退改集中），一般是目标峰值的 1.5 倍作为"压测红线"。
这里有个细节：容量评估要按"瓶颈维度"分别算。数据库看 QPS + 连接数，Redis 看内存 + 每秒读写，MQ 看积压量，网关看并发连接。别只盯着一个数字，要画出整个系统的"水位表"。
数据怎么造？别拿线上库压测
全链路压测最头疼的是"数据从哪来"。直接压线上库？不行，会污染真实数据。我们用的是影子库 + 影子表 + 压测标记的方案：
- 影子库：专门建一套结构一样的测试库，压测流量带上
is_pressure=1的标记，走独立的影子库，跟线上彻底隔离。 - 影子数据：订单、库存、游客账号都提前灌好，量级对齐线上（几百万单、几十万游客）。数据太少，压测结果虚高。
- 影子消费：支付回调、短信、推送这些外部依赖，全部打到 Mock 或影子通道，不然一场压测能把真实短信平台打欠费。
这个方案的好处是可以开着全链路压测进真实环境，网络、网关、负载均衡、云原生组件全都真实参与，最后得出的容量数字才可信。
瓶颈排摸：先打"读"，再打"写"，最后打"混合"
我们压测的节奏很讲究，不是一把梭：
- 先压读链路（查余票、查订单、查景区信息）：确认读 QPS 的天花板，定位缓存命中率和 DB 只读从库的极限。
- 再压写链路（下单、支付回调、退改）：这部分最容易出问题，因为涉及分布式事务、库存扣减、消息顺序。我们会重点盯库存扣减是否超卖、支付回调幂等。
- 最后压混合场景（真实比例的读 + 写 + 排队叫号推送）：这一步最能暴露问题，比如"写高峰把读拖垮""WebSocket 连接数把网关打满"。
每压一轮，都要把瓶颈点、参数、结论记下来。压测不是一次性的，是迭代的——压 → 定位 → 优化 → 再压。
压测结果怎么用？画容量曲线，定限流阈值
压测的产出不是"通过了"三个字，而是一套可复用的容量曲线。我们会记录不同压力下各个组件的表现，画出"QPS - 延迟"曲线，找到拐点（延迟开始陡增的 QPS 值）。
这个拐点，就是限流和熔断阈值的依据。旺季我们把网关限流设成拐点的 80%，给系统留 20% 的缓冲；再往上设一级熔断阈值，防止雪崩。压测的真正价值，是让你在灾难发生前，就把"保命阈值"定好，而不是出事时手忙脚乱地调。
我们还会把压测报告整理进知识库，用 RAG 做检索——下次要查"去年五一压测时 Redis 连接池怎么调的"，直接问系统就能召回当时的完整记录和结论，不用再翻聊天记录。
压测的坑，我踩过的都在这
- 坑一：把压测工具跑在和生产同一台机器。压测机先把自己打满，结果全盘误判。压测要独立资源，最好按生产环境 1:1 复刻一套压测环境。
- 坑二：只压白天高峰，不压凌晨对账。有一次凌晨归档任务 + 日切对账 + 压测三合一，把凌晨的低谷打成了次高峰，游客半夜退票超时。压测要覆盖所有定时任务的时段。
- 坑三：忘了压"排队叫号"这种长连接。WebSocket 连接数和普通 HTTP 请求是两回事，连接长时间不释放，网关内存先爆。长连接场景要单独压，看的是并发连接数和内存，不是 QPS。
- 坑四：压测后不清理影子数据。影子库的数据膨胀，把测试环境搞得很慢，第二天压测结果失真。每次压测完要清理，保持环境干净可复现。
压测报告谁来看？让 AI Agent 做第一道筛选
全链路压测动辄几万行日志，人工看不过来。我们后来写了个 AI Agent 做压测巡检：每次压完自动把各组件指标、异常点、瓶颈排行总结成一份简报，推给值班群。遇到"主库 CPU > 85%"这种高风险项，直接标红提醒。这活儿用大模型做指标归因很顺手——它能从几千行压测日志里，几秒判断出"这次瓶颈是数据库连接池还是网关并发"，省掉我们大量翻日志的时间。甚至可以让 Agent 顺着 MCP 接口直接调监控平台，把"发现问题"到"定位根因"一步到位，不用人肉切来切去。顺手我们还用低代码平台搭了压测看板，运营同学自己就能看水位，不用每次追着后端要数据。
这套链路沉淀下来，旺季前我们基本能做到"压测 → 定位 → 调优 → 复压 → 定阈值"在一天内闭环。中科智旅景游宝靠它扛住了好几个节假日的峰值，没再出过"开园就卡"的事故。
FAQ：常见问题快答
Q1：全链路压测会不会影响线上真实用户？ 只要影子库隔离做干净、压测流量带标记、消费走 Mock，就不会污染线上。我们一直开着压测进真实环境，从没误伤过真实订单。
Q2：压测环境要和线上完全一样吗？ 越接近越好。尤其网关、负载均衡、云原生组件这些，必须一致，否则容量数字不准。数据库配置也尽量对齐。
Q3：限流阈值定多少合适？ 以压测曲线拐点的 80% 做限流阈值，再往上留一级熔断。别定得太满，旺季系统要留缓冲，不然一有突发就直接雪崩。
Q4：压测数据量要多大才准？ 至少对齐线上一个数量级。几万条数据和几百万条数据，数据库执行计划完全不同，压出来的容量是假的。
Q5：压测一次要多久？ 分场景：读链路 1-2 小时、写链路 1-2 小时、混合场景 2-3 小时，中间穿插优化。完整一轮全链路压测，一天内做完比较理想。留出足够时间，别挤在旺季前夜才压——那是拿生产当赌注。
旺季放闸是门手艺。中科智旅景游宝用这套全链路压测 + 容量评估，把"能不能扛住"从玄学变成了工程。希望这篇能帮你，在下一个节假日前夜，睡得踏实一点。
