场景特点

电商大促的负载特征非常极端：平时与峰值的流量差距可以达到数十倍，且峰值出现的时间点高度确定。这意味着两件事：一是按峰值配置资源会长期浪费，二是必须有能力在短时间内把容量提上去。

订单链路又是其中最敏感的环节：写入密集、涉及库存与优惠计算、对超时极为敏感。一旦订单库出现写入阻塞，影响会立刻传导到用户侧。

容量预估与预热

扩容不能等到峰值来了才做，前置工作包括：

  1. 历史数据外推：基于往期大促的 QPS、订单量、连接数峰值，结合本次预期增长做容量估算；
  2. 全链路压测：用真实业务模型压测到目标容量的 1.2 倍以上，找出瓶颈环节；
  3. 提前扩容：在峰值到来前完成节点增加与数据均衡，而不是临近时紧急操作；
  4. 预热：提前加载热点数据与连接池，避免峰值瞬间的冷启动抖动。

在线扩容流程

得益于计算与存储分离的架构，扩容可以拆成两个相对独立的部分：

  • 计算层扩容：新增无状态计算实例并接入负载均衡，不涉及数据搬迁，见效快。需要注意连接池复用问题——已有长连接不会自动迁移到新实例，必要时配合应用侧分批重建连接；
  • 存储层扩容：新增存储节点后由调度组件自动迁移数据分片，过程在线进行，但会产生额外的 IO 与网络开销，应配合限速参数与低峰窗口。
实践中容易踩的坑：只扩了数据库而没扩连接层或中间件，瓶颈会转移到别的组件上，容量提升不明显。

热点治理比扩容更重要

大促场景下最典型的性能问题不是总量压力，而是热点：少数爆款商品的库存行、单个热门活动的计数、集中写入的自增主键，都可能让压力集中到某一个数据分片上，此时扩容整体集群并不能解决问题。

常用治理手段：

  1. 打散热点键：对计数类场景按维度拆分，把单点写入分散到多个键上；
  2. 避免连续自增主键：自增键会让写入持续落在同一分片，改用打散策略或复合键；
  3. 库存扣减优化：把高频扣减放到缓存或队列中做预扣，数据库只承载最终落账；
  4. 读写分离：把商品详情、活动页等读请求指向只读副本，让主链路专注写入。

降级与预案

再充分的准备也要有兜底。大促期间的预案通常包括：

  • 限流：按接口维度设置上限，优先保障下单支付链路，牺牲次要功能；
  • 降级：关闭非核心的实时统计、推荐等重查询，把资源让给交易；
  • 排队：对突发流量采用队列缓冲，用可接受的等待换取系统不崩；
  • 熔断：依赖组件异常时快速失败，避免请求堆积拖垮整条链路；
  • 回滚开关：所有变更都准备回滚手段，并确保开关可在秒级生效。

监控与值守

大促期间的观测重点与平时不同：

  • 关注延迟分位（P99、P999）而非平均值，平均值会掩盖长尾问题；
  • 实时跟踪连接数、活跃事务数、锁等待，这些指标往往先于业务指标恶化；
  • 监控慢查询数量变化趋势，突增通常意味着计划退化或资源竞争；
  • 建立分段看板，让值守人员能在几秒内判断问题出在哪一层。

经验小结

大促保障的本质是把不确定性提前消化：用压测把未知变成已知，用扩容把容量缺口提前补齐，用热点治理把集中压力摊开，用降级预案为最坏情况留出退路。这四件事做到位，大促的稳定性就不再依赖运气。

案例要点速览
行业场景电商大促订单链路，流量峰值可达平时数十倍且时间点可预期
核心诉求短时间内提升容量、避免写入阻塞、保障下单支付链路
关键手段全链路压测、提前扩容与预热、计算与存储分层扩容
主要风险热点键导致压力集中于单一分片，单纯扩容无法解决
兜底策略限流、降级、排队、熔断与可秒级生效的回滚开关