某年大促开始前二十分钟，一家做食品的客户的小程序商城系统直接白屏，顾客在群里刷「进不去」，等系统恢复，最热的那波流量早跑了。事后查，问题不在程序写得烂，在于从来没人算过并发这笔账。
先搞清楚自己的峰值在哪
并发不是看店铺总人数，是看同一秒内有多少人在同时请求。平时一天五百单的店，峰值并发可能就二三十；做一场千人群秒杀，开抢那一秒并发轻松破千。算峰值有个粗办法：取最近一次活动中最高一分钟的订单量，乘以二十到三十倍作为并发请求数，再留一倍余量，这就是系统该扛住的底线。很多商家压根不知道自己的峰值，直到崩了才第一次见到它。峰值还可以用预约和预告来削：提前一天在社群预告开抢时间，把集中涌入摊开到几分钟，比硬扛便宜得多。
瓶颈往往不在你想的地方
大家总以为是服务器CPU不够，实际最常见的瓶颈是数据库和图片。几百人同时刷新商品页，数据库查询排队，页面就卡死；商品图没做压缩和CDN加速，一张五兆的图能把手机端拖到超时。排第二的是支付回调堆积，订单量猛增时支付通知处理不过来，顾客付了钱订单迟迟不出，比白屏还吓人。所以压测不能只测商品页，下单和支付链路要按同样的量级一起压，哪一段排队看监控数据说话。
- 静态资源上CDN，图片按需压缩，前端压力先减一半
- 数据库加缓存，热门商品页做静态化，别每次都查库
- 秒杀类活动用队列削峰，先收单后出结果，别让所有人挤同一秒
配置之外，程序写法也有讲究：循环里查数据库、一个请求发十几次查询，这种代码平时几十人看不出毛病，几百人一挤就现形。正规的服务商上线前会做代码走查，选型时可以把「有没有做过性能审查」当成一道筛选题。
大促前必做的两件事
一是压测：用工具模拟预估峰值两倍的访问量，看哪里先倒，提前一个月修完。二是弹性扩容：服务器配置临时升级、带宽临时加大，活动结束再降回去，成本比常年养高配服务器省得多。压测报告要留档，写清峰值之下下单成功率多少，这才是真正的底气。报告同时抄送客服和仓库，让他们知道大促当天什么情况算异常。
比格网络给客户的小程序商城系统做大促保障，固定动作就是提前两周压测加演练，崩在测试环境里一次，总好过崩在顾客面前。演练还包括客服和仓库的应急预案，真到流量爆的时候，各岗位知道该盯哪里、向谁汇报。
