促销当天下午三点，后台订单页转圈，仓库打不出面单，客服电话被打爆——一家做节日礼品的客户在旺季亲身经历的一晚。系统平时好好的，订单量一冲上来就崩，这种问题硬扛是扛不过去的，后端系统开发的扩容要提前做，崩了再做就是拿真金白银交学费。
先搞清楚瓶颈在哪一层
系统变慢的原因五花八门，最常见的就几种：数据库慢查询堆积，一个没加索引的报表查询拖死整库；服务器配置不够，CPU打满；代码里有串行调用的接口，高峰期排队。扩容前先做压测，模拟两倍、五倍于日常的流量，看哪个环节先倒，对症下药。上来就加服务器是常见误区，数据库没调优，加十台应用服务器也没用。
常见的扩容顺序
- 第一步永远是数据库：加索引、拆慢查询、读写分离，成本最低见效最大；
- 其次加缓存：热点数据进Redis，数据库压力立减大半；
- 再考虑应用层横向扩：多加应用服务器配负载均衡，应用层通常是无状态的，扩起来容易；
- 最后才到架构级改造：消息队列削峰、异步化改造，动这个要评估工期。
那家礼品客户的处理算及时：崩过一次后做了压测，查出三个慢查询，加缓存和索引花了不到一周，第二年旺季单日订单翻了四倍，系统稳稳的，这次花的钱不到旺季损失的十分之一。
还有一个思路：把削峰做进业务里。大促订单先进队列慢慢处理，用户端提示已收到，后台按自己的能力消化，比硬扛瞬时高峰便宜得多。很多崩盘不是能力不够，是所有请求都挤在同一秒，容量规划跟着业务日历走，才能不打无准备之仗。
别等崩了才动手
监控要提前装：数据库慢查询、服务器CPU、接口响应时间，设好阈值告警。业务侧也有责任：大促计划提前一个月告诉技术方，好留出压测和扩容时间。后端系统开发的扩容不是一次性工程，业务每上一个台阶就该复查一次。
两条建议：每年旺季前做一次例行压测，把容量天花板摸清楚记下来；监控告警接上你自己的手机，别只靠服务商自觉。比格网络给客户做旺季护航时，压测和监控是标配动作，几百块的预防成本对比一晚上的订单损失，这笔账不难算。
