电商大促前的弹性扩容方案

大促的流量可以估算，扩容这件事必须赶在活动前动手，等流量冲上来再处理就晚了。下面是一套可以直接照着执行的时间表。 一、准备条件 活动前两周备齐三样东西：近三个月的流量日志、当前服务器的监控基线、一份写清楚到人的扩容清单。日志用来估算峰值，基线用来对照压测结果，清单里列明每台机器升到什么规格、由谁在什么时间操作。 二、压测找出瓶颈 用压测工具模拟预估峰值，找出当前架构先垮的那一环。以 wrk 压商品详情页为例： ```bash wrk -t8 -c500 -d120s https://shop.example.com/item/1001 ``` 盯住三个数：响应时间的 P95 值、错误率、应用服务器的 CPU 水位。P95 超过一秒，或者错误率超过千分之五，说明现有配置撑不住预估峰值，需要扩容；三个数都健康，就把压测力度再调高一档，摸出真实上限。 三、扩容与预热 资源按预估峰值的一点五倍来配：数据库优先升内存，应用机升 CPU，带宽按峰值流量的上限购买。云服务器升配在控制台就能完成，活动结束降回原规格，临时资源不必常年养着。扩容完成后的最后一天做预热：把热点商品写进缓存、把静态资源推到 CDN（内容分发网络），避免开抢瞬间缓存全空，流量直接砸到数据库。 四、验证与降级开关 扩容后按同样的参数复压一次，P95 回到五百毫秒以内才算过关。同时准备好降级开关：推荐模块、评价列表、实时库存精度这些外围功能，压力过大时先关，保住下单和支付主链路。开关做成配置项，改一行配置就能生效，不要临场改代码重新发布。 五、常见问题与处理 压测正常、实战还是崩，多数是预热不足或第三方接口拖慢主流程，给外部调用加上超时和失败重试。升配后报连接数不足，把数据库的 max_connections 一并调大，它不会跟着配置自动涨。活动结束后别急着降配，观察一天流量回落曲线再操作，防止返场流量弹回来。 大促扩容的核心是时间表而不是技巧：两周前压测、一周前扩容、前一天预热、当天只盯监控和开关。照表执行，大多数事故都能提前消掉。