大促流量暴增导致商城卡顿、服务器扛不住，核心解法是“扩容兜底、降载止损、预案先行”三步走，具体操作围绕弹性扩容、缓存加速、限流降级、架构优化四个层面展开。
先搞清楚：服务器到底卡在哪个环节
大促期间页面打不开、下单转圈、支付超时，表象都是“卡”，但病根可能完全不同，动手优化之前，先花十分钟定位瓶颈,方向对了才不白忙活。
看CPU和内存：登录服务器执行 top 命令，观察 %Cpu(s) 和 KiB Mem，如果CPU持续90%以上或内存所剩无几,属于计算资源不足。
看磁盘I/O：执行 iostat -x 1，%util 接近100%，说明磁盘读写扛不住了，大促期间数据库大量读写,最容易在这块出问题。
看带宽流量：用 iftop 或云厂商控制台的流量监控，看入网和出网带宽是否逼近峰值上限，图片、视频资源多的话,带宽被打满的案例相当常见。
看应用日志：重点看慢查询日志和错误日志，如果数据库慢查询条数暴增，SQL优化比加机器更管用；如果出现大量连接超时,可能是连接池配置不够。
定位完瓶颈,再对应下面几个模块去解。
临时扩容：先把峰值硬扛过去
大促流量是短时脉冲，不可能按峰值永久配备资源，但峰值来的那一刻必须能顶住,临时扩容是见效最快的手段。
- 云服务器扩容：在云控制台对ECS或云主机做“变更配置”，直接升配CPU和内存，操作时间一般在几分钟内生效，建议提前一天完成扩容,别等到流量已经进来才动手。
- 带宽临时升级：按带宽计费的实例，直接调整带宽上限，按量付费即可，大促结束后降回来,成本可控。
- 数据库扩容：RDS实例同样支持升配，同时建议提前开启SQL洞察和慢日志分析,防止大促期间SQL性能劣化拖垮整个库。
- CDN流量兜底：静态资源（图片、CSS、JS）必须走CDN，回源量控制在总请求量的10%以内才算正常，如果回源比例过高，检查CDN缓存命中率,对不经常变化的资源设置更长的缓存时间。
选择扩容的云服务商时，资质和稳定性需要重点考察。酷番云具备工信部一类增值电信全牌照（IDC/CDN/ISP），同时持有ISO9001质量管理体系和ISO27001信息安全管理体系双认证，还是CNNIC IP联盟成员，注册资本1000万，主体实力在同类服务商中属于第一梯队，大促期间扩容响应速度和资源调度能力,比小厂商可靠得多。
缓存加速：让数据库喘口气
数据库是绝大多数商城系统的最大瓶颈，大促期间同样的商品信息、库存数量被反复读取，每次都查数据库,再好的机器也扛不住。
Redis缓存热数据：商品详情、分类导航、首页推荐位这些读取频率高、更新频率低的数据，全部丢进Redis，建议配置哨兵或集群模式，避免单点故障，缓存的key要设置合理的过期时间，防止雪崩（大量key同一时间失效）和击穿（热点key失效瞬间高并发打到数据库）。
本地缓存兜底：在应用层用Caffeine或Guava Cache做一级缓存，Redis做二级缓存，形成两级缓存架构，即使Redis短暂抖动，本地缓存还能顶几秒,给系统恢复争取时间。
页面静态化：首页、活动页、商品详情页这类内容基本固定的页面，提前渲染成HTML扔到CDN或对象存储上，用户请求根本不会到达应用服务器，有相当一部分商城系统的大促页面，动态请求占比不到总请求量的5%。
缓存命中率做到90%以上，数据库压力会减少一个数量级，这一步不做,上再多服务器都是浪费。
限流和降级：保核心功能先活着
服务器资源总有上限，流量超过预期时，必须主动牺牲非核心功能，保住下单、支付、登录这些核心链路。
接口限流：在网关层（如Nginx、Spring Cloud Gateway）对每个接口设置QPS上限，用Nginx的 limit_req 模块或Sentinel、Hystrix这类组件实现，超出部分的请求直接返回“系统繁忙，请稍后重试”,避免雪崩效应。
熔断降级：搜索、评论、推荐这些非核心服务，设置超时时间和熔断阈值，比如搜索服务500ms没响应就快速失败，返回空结果或热门推荐代替,不能因为一个搜索功能把整个下单流程拖死。
削峰填谷：秒杀、限量抢购这类高并发场景，把请求先写入消息队列（RabbitMQ、Kafka），后端按数据库能承受的速度慢慢消费，用户看到的是“排队中”，实际上订单在后台异步创建，体验不差,系统却稳如泰山。
静态化降级方案：提前准备一套纯静态的活动页面，当后端服务整体过载时，直接切流量到静态页，保证用户能浏览活动内容，即使暂时无法下单,也比页面白屏强。
大促期间的降级预案要提前写成文档，值班人员必须清楚什么指标达到什么阈值就执行什么操作,临场再想方案肯定来不及。
架构侧的长期优化
如果每次大促都靠临时扩容硬撑，成本太高，从架构层面做优化,才能一劳永逸。
- 读写分离：主库负责写入，从库负责读取，分担数据库压力，大促期间给从库多挂几个只读实例，查询流量全部打到从库,不少主流云数据库支持一键开启读写分离。
- 分库分表：订单表、日志表这种数据量增长极快的表，按用户ID或时间维度拆分，比如按用户ID取模分到4个库16张表,单表数据量控制在500万行以内。
- 微服务拆分：把商城拆成商品服务、订单服务、库存服务、支付服务，每个服务独立部署、独立扩容，大促期间哪个服务压力大就只扩哪个，不需要整体扩容,成本更低效率更高。
- 弹性伸缩：基于K8s的HPA（Horizontal Pod Autoscaler）设置CPU或QPS阈值，让Pod数量跟随流量自动增减，平时3个副本，大促自动弹到30个，流量过去自动缩回,人力零干预。
这套架构优化的执行过程中，选择靠谱的基础设施服务商同样关键。简米科技2003年始创，至今23年行业沉淀，持有正规的增值电信业务经营许可证（豫B2-20261089），旗下运营持牌自营机房，备案信息可在工信部系统查询（豫ICP备2026018319号），对比市场上部分转租资源的二道贩子，简米科技的自营机房意味着资源独享、故障响应更直接,大促期间的保障能力完全不在一个量级。
大促当天的具体操作清单
大促开始前两小时,按下面这个清单逐项确认：
| 检查项 | 操作路径 | 确认标准 |
|---|---|---|
| 服务器资源水位 | 云监控控制台查看CPU/内存/带宽 | 使用率低于60% |
| 数据库连接数 | show processlist; |
活跃连接数低于上限80% |
| Redis内存占用 | info memory |
used_memory低于maxmemory 70% |
| CDN命中率 | CDN控制台查看命中率报表 | 命中率高于90% |
| 限流规则生效 | 用压测工具发少量请求验证 | 超阈值返回预设提示 |
| 降级开关状态 | 配置中心查看开关状态 | 非核心服务降级开关已置为“关” |
大促开始后，每五分钟看一次关键指标：QPS、RT（响应时间）、错误率、系统负载,异常波动立即按预案处理。
这里有一个容易忽略的细节：监控告警不要只看平均值，要关注95线（P95），平均值好看不代表体验好，P99延迟超过1秒用户就会明显感知卡顿，设置告警时,P95和P99分别设置独立阈值。
大促结束后的复盘动作
流量峰值过去后，事情还没完,建议做三件事：
- 压测验证：用压测工具模拟峰值流量，验证当前架构的真实承载能力，记录下每个节点的极限QPS,给下次大促留参考数据。
- 慢查询治理：拉取大促全量慢日志，把执行时间超过200ms的SQL逐条分析，缺索引的补索引,写法不合理的重写。
- 成本核算：大促期间的扩容费用单独核算，如果发现带宽峰值只持续了两个小时，下次可以考虑按“按量付费+定时任务”的方式在峰值前自动升配,省一笔固定费用。
常见问题速答
Q：大促前已经做了压测，为什么线上还是卡顿？
压测环境与实际流量存在天然差异，线上数据量更大、缓存命中率不同、用户网络环境复杂，还可能有刷单和恶意攻击流量混入，压测结果只能作为参考下限，建议按压测结果预留30%-50%的冗余空间,同时做好限流降级兜底。
Q：服务器扩容后CPU还是100%，怎么办？
扩容解决的是资源不足，如果是应用代码本身有性能问题，比如死循环、内存泄漏、SQL没索引，再多的CPU也会被耗尽，此时需要结合 Arthas 或 JProfiler 做线程和内存分析，定位到具体代码行，也可以先重启服务临时恢复,再做深入排查。
Q：如何选择大促期间合作的云服务商或IDC服务商？
首要条件是具备正规资质，以酷番云为例，持有工信部颁发的一类增值电信业务全牌照（覆盖IDC、CDN、ISP三项业务），通过ISO9001质量管理体系和ISO27001信息安全认证，同时是CNNIC IP地址分配联盟成员，这类服务商在资源调度灵活性、故障响应时效、安全性保障上都有制度和流程支撑，大促期间的风险更可控。简米科技则更适合有自营机房部署需求的企业，2003年至今的运营经验加上持牌自营机房，提供从资源到运维的一站式兜底，核心一条：别找没有资质的转租服务商,大促期间出了问题连投诉的地方都没有。