商城系统大促备战清单：从压测、限流到应急演练，双11前必须做的12件事

商城系统大促备战清单：从压测、限流到应急演练，双11前必须做的12件事

　　每年双11之后，总有几个商城的"事故报告"在圈里流传：大促开始10分钟系统崩了、优惠券叠加算错导致几百万的资损、订单付款成功了库存没扣、短信验证码被刷爆导致真客户登不进去……

　　事后复盘，几乎没有人会说"是系统技术太差"。真实原因高度一致：不是系统不行，是没有准备。

　　大促和平时的差别，不是"人多一点"，而是峰值可能是日常的5到10倍，且全部集中在开抢后的前30分钟。平时的系统表现，完全不能用来预测大促当天的表现。

　　这篇文章给一份可执行的备战清单：先算量，再做12件事，最后看最容易翻车的5个细节。 直接可以当项目检查表用。

一、第一步：先算清这次要扛多少量

　　没有容量评估的备战，都是拍脑袋。花半天时间算三个数：

　　① 峰值QPS（每秒请求数）。 算法：日常峰值QPS × 大促系数。大促系数经验值3～10倍，取决于你的推广力度——如果大促当天要投大量广告、发大量短信、做直播引流，就按上限准备。

　　② 峰值订单量。 大促当天的目标GMV ÷ 客单价 = 总订单量。要知道其中60%以上会集中在开抢后1小时内，这个瞬时下单速率才是有意义的数字。

　　③ 并发在线人数。 峰值在线用户数决定了应用服务器、连接数和带宽的配置。

　　特别提醒一个容易漏的： 支付回调、短信、物流对接这些外部依赖，很多企业的系统本身扛得住，反而是这些外部接口先挂——所以容量评估必须把"依赖方"一起算进去。

二、技术备战7件事

　　1. 全链路压测。 不要只压单台应用服务器。要按"用户访问完整链路"来压：CDN → 网关 → 应用 → 缓存 → 数据库 → 外部接口。重点看瓶颈在哪一环，而不是看单机能跑多少QPS。压测最好用生产环境同规格的机器，并尽量用真实数据量级（尤其是数据库里已有的历史订单量级，会显著影响查询速度）。

　　2. 提前扩容，别无脑相信自动扩容。 云资源要提前扩容并保温至少48小时——大促当天现扩，可能遇到资源售罄或新机器冷启动慢。带宽、数据库连接数、Redis内存、消息队列容量都要跟着一起扩，扩CPU不扩数据库连接数，等于白扩。

　　3. 限流与排队。 秒杀场景必须设限流，宁可让用户看到"排队中"，也不要让所有请求都打进来把系统拖死。限流要分级：入口网关限流、应用层限流、热点商品单独限流。关键原则：牺牲少部分用户体验，保住整体可用。

　　4. 降级预案。 提前列出"大促时可以先关掉的功能"，例如：商品推荐、评论列表、历史足迹、积分明细这些非核心链路，在压力大时降级或静态化。核心链路只有一条：浏览商品 → 加购物车 → 下单 → 支付 → 看到订单。这条必须保证。

　　5. 缓存与静态化。 商品详情页、活动页、首页能做静态化的全部静态化，走CDN；不能静态化的热点数据放缓存。一条铁律：能不让数据库做的事，就别让数据库做。

　　6. 慢SQL治理。 大促前把所有慢查询捞出来优化一遍，该加的索引加上。平时跑800毫秒的SQL，数据量涨了之后再并发一上来，就可能变成几秒，直接把数据库连接池占满。

　　7. 监控告警与值班表。 大促前确认监控能覆盖：服务器CPU/内存/磁盘、各接口响应时间、成功率、订单量、支付成功率、队列积压量。告警要提前配置好接收人和值班表，大促当天要有人在岗，而不是"出事再找人"。

三、运营备战3件事

　　技术之外的这3件事，出问题的概率其实更高：

　　8. 商品与价格全量核对。 大促前一定要有一次完整的、人工复核的价格核对：活动价、会员价、优惠券抵扣后价格、限时价，是否与预期一致。价格错标是大促最常见、也最贵的错误——用户下单了你不能不发货。

　　9. 库存与防超卖。 确认库存扣减逻辑在并发下是否可靠（是否用了分布式锁或库存预占），秒杀商品的库存要单独设置并压测。同时准备好超卖后的兜底方案（补货优先、主动联系用户、补偿方案），别等真超卖了才临时开会。

　　10. 客服与售后预案。 提前准备好高频问题的标准话术（发货时间、优惠叠加、退换规则）、临时增加客服排班、设置咨询自动回复。大促当天的客服压力同样是平日的10倍。

四、最容易翻车的5个细节

　　这5件事，几乎每年都有人栽：

　　① 大促前夜发版。 距离大促不到72小时，千万别上线新功能。任何代码改动都是风险，冻结发布是大促前最基本的纪律。

　　② 优惠券规则叠加算错。 "满减+折扣+会员价+新人券"能不能同时用、谁先算谁后算，一定要在测试环境把所有组合都跑一遍。规则越复杂，越要做穷举测试。

　　③ 支付通道限额没提额。 支付渠道（微信、支付宝、银行）通常有单日限额和并发限制，大促前必须提前报备、申请提额，并准备备用通道。

　　④ 短信验证码被刷爆。 大促期间恶意刷短信很常见，会直接烧钱并导致真实用户收不到验证码。要提前做限流（同手机号、同IP）、图形验证码、以及余额预警。

　　⑤ 物流与电子面单没做压测。 订单量一上来，电子面单打印接口如果限流，仓库就发不出货——系统没崩，业务先崩了。

五、时间倒排表：照着排期执行

　　T-30天（现在这个阶段）： 　　
      - 完成容量评估，确定峰值目标 　　
      - 全链路压测第一轮，找出瓶颈 　　
      - 确定大促资源预算（服务器、带宽、短信）

　　T-15天： 　　
      - 压测第二轮（优化后复测），确认达标 　　
      - 完成慢SQL治理与缓存改造 　　
      - 与支付、短信、物流等外部方确认限额与接口能力 　　
      - 编制降级预案清单

　　T-7天： 　　
      - 服务器扩容并保温 　　
      - 告警规则、值班表确认，做一次故障演练 　　
      - 商品价格与库存设置全量检查 　　
      - 客服话术、排班到位

　　T-3天： 　　
      - 代码冻结，停止一切非必要发布
      - 最后一次全流程冒烟测试
      - 大促当天的人员到岗确认

　　T-1天： 　　
      - 检查资源、监控、告警全部就位
      - 确认应急预案的决策人和联系方式
      - 早点睡——第二天会是硬仗

　　大促当天： 　　
       - 关键指标实时盯盘（订单量、支付成功率、接口响应） 　　
       - 按预案触发降级，别临场讨论 - 记录所有异常，为复盘留证据

写在最后

　　大促拼的不是技术有多先进，而是准备得有多充分。

　　一套架构合理的商城系统（比如基于Java的主流架构，天然擅长处理高并发场景）能帮你拿到基础分；但能不能扛住双11，取决于有没有认真做完上面这12件事。

　　提前6周开始准备，比大促当天加班48小时有用得多。

　　如果现在还没开始，从今天算起正好还有6周——来得及，但要从今天开始。

　　（本文为行业科普内容。易族智汇javashop 多用户商城系统基于Java微服务架构，支持分布式部署与弹性扩容，已支撑多家客户的大促峰值流量，欢迎访问官网：www.javamall.com.cn，或通过400-089-8805与我们沟通。）

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。