聚水潭ERP专项优化：大促压测支撑峰值每秒2.6万单

2026年10月22日，聚水潭ERP完成双十一前的大促专项优化与全链路压测。压测模拟每秒2.6万单的订单洪峰，订单入账延迟中位数1.9秒，库存扣减成功率99.99%，弹性扩容在8分钟内完成，限流与降级策略按预案自动生效，全链路无中断。压测使用脱敏后的影子订单，不进入商家真实账目；压测期间产生的数据在结束后统一清理，商家侧无感知，也不会影响当日的真实订单同步。压测覆盖订单创建、库存扣减、支付回调、面单生成与售后受理五条链路，每条链路单独设定通过标准，任一未达标即回到开发修复，修复后重新压测。压测采用逐步加压的方式，从日常峰值的六成开始，每十分钟提升一档，直到超过预期峰值两成；每档记录响应时间与错误率，出现拐点即停止加压并定位瓶颈。

大促的稳定性不是靠临时加班。聚水潭稳定性负责人柏舟说：“我们把去年双十一的峰值放大1.6倍来做压测，把可能出问题的地方提前打穿。”本次压测覆盖下单、扣减、打单、发货、售后五条主链路，共12个演练场景。去年双十一的峰值被放大1.6倍，团队按先打穿再修复的思路设计场景，其中一个场景专门模拟第三方面单服务整体不可用，验证降级能否兜住，结果降级后打单仍能在本地队列排队重试。值班体系也做了调整：大促期间按链路设专人值守，监控看板按链路分屏，告警直接派到对应负责人，避免所有告警汇到一个群里互相淹没的情况。库存扣减是最容易出问题的一环：同一SKU被多个订单同时扣减，稍有不慎就出现负库存；团队把扣减改为预占加确认两段式，并在压测中专门构造了热点SKU的并发场景。

全链路压测：每秒2.6万单

压测采用影子流量与真实链路结合，订单、库存、支付回调三类请求按7:2:1比例投放，持续42分钟。峰值每秒2.6万单，订单入账延迟中位数1.9秒、P99为5.7秒，库存扣减成功率99.99%，未出现负库存。

数据库读写分离后主库负载稳定在62%，缓存命中率91.4%；消息队列堆积峰值18万条，在9分钟内消化完毕，未触发消费超时。

影子流量按真实请求的比例投放，订单创建、库存扣减、支付回调三类请求分别标记来源，便于在监控上区分压测与真实流量，避免告警误判与工单误派，压测结束后标记自动失效。

“压测不是为了证明系统能扛，而是为了提前把扛不住的地方找出来，在大促之前修掉。”

—— 祁远，聚水潭SRE负责人

弹性扩容与限流降级

核心服务按CPU与队列长度双指标自动扩容，从检测到扩容完成平均8分钟，最大可扩容至日常容量的6倍；扩容期间请求自动分流，用户无感知。压测中触发扩容3次，均在10分钟内完成。

限流按接口分级设置阈值，超阈值返回排队提示而非错误；降级预案覆盖报表查询、导出、图片处理三类非核心功能，降级后核心链路延迟下降23%。

扩容策略按CPU、队列长度与响应时间三个指标触发，任一越线即扩容；缩容设置冷却期，避免流量抖动导致频繁扩缩。大促期间扩容上限由值班负责人锁定，防止成本失控，扩容记录可在容量看板追溯。

值班与演练

双十一期间安排三级值班，一线监控、二线研发、三线架构师，告警响应时限分别为5分钟、15分钟、30分钟；共准备37个应急预案，覆盖缓存穿透、队列堆积、第三方接口超时等场景。

演练共发现隐患21项，其中5项为高危，已在压测后修复；修复项包括订单查询慢SQL、库存锁等待超时、面单服务连接池不足。全部修复项完成回归验证。

37个应急预案都做了桌面推演与实战演练两轮，每个预案明确触发条件、操作步骤与回滚方式；演练发现的高危项在压测后一周内修复并回归，未修复项列入大促禁做清单，值班表按预案逐条交底。 大促保障方案已随聚水潭ERP V6.6生效，商家侧无需操作；大促期间系统将保持限流预案与扩容策略开启。后续将把压测能力开放为商家可用的活动预演工具。需要稳定承载大促流量，可下载聚水潭ERP并关注大促保障公告。活动预演工具计划开放给商家，商家可用自己的历史订单结构做小规模压测，提前发现打印模板、快递账号与仓库配置方面的问题，减少活动当天的手忙脚乱。大促复盘会在活动结束后一周内完成，逐条核对预案触发次数与实际效果，把误触发与漏触发的预案重新修订，结论同步到下一个活动季的准备清单。大促期间的容量水位每小时公示一次，值班人员据此判断是否需要提前扩容；水位接近八成时自动触发扩容，无需人工确认，扩容记录与当时的指标一并留档，供活动后复盘。