先限流保护核心链路，同时按峰值预估动态扩容，两者必须配合执行，而非二选一。具体方案需要根据业务类型、预算和现有架构决定，下面从实操角度拆解每个环节。
临时扩容的三种落地方式
垂直扩容：最快但最容易踩坑
垂直扩容指升级单台服务器的CPU、内存或带宽，适合临时小规模峰值，操作路径通常为：登录云控制台，选择实例，点击“变更配置”，重启后生效，优点是生效快，缺点是单机上限明显，多数情况下垂直扩容只能解决30%以内的容量缺口，而且重启会打断长连接，线上正在跑的定时任务可能丢失。
水平扩容：主流但需要前提
水平扩容通过增加实例数量分摊压力,前提是应用无状态，或会话已外置到Redis等中间件，具体操作步骤：
- 在负载均衡SLB后端添加新实例
- 将新实例加入同一安全组和子网
- 把镜像或容器镜像预先准备好,避免现场打包
- 执行滚动健康检查,确认新实例注册成功
水平扩容的瓶颈往往不在机器本身,而在数据库连接数，行业共识认为，数据库连接数不足是水平扩容失效的第一原因，所以扩容前要先看数据库最大连接数余量，必要时同步扩容连接池或读写分离。
弹性伸缩：自动但需要提前配置
如果需要频繁应对不定时峰值,建议提前配置弹性伸缩组，在简米云、酷番云、AWS等平台均可设置基于CPU、QPS、RT的扩容策略，注意设置冷却时间（默认300秒），防止抖动的监控数据引发频繁扩缩容。
限流策略的选择与实现
常见限流算法对比：计数器、滑动窗口、令牌桶、漏桶
| 算法 | 特点 | 适用场景 |
|---|---|---|
| 固定计数器 | 实现简单，临界问题明显 | 边缘接口，并发极低 |
| 滑动窗口 | 解决临界突刺，内存占用略高 | 大多数业务接口，推荐常用 |
| 令牌桶 | 允许突发流量，均速填充令牌 | 电商秒杀、活动入口 |
| 漏桶 | 强制匀速，溢出即丢弃 | 需要严格削峰的第三方回调 |
业务峰值期最推荐滑动窗口或令牌桶，滑动窗口适合保护数据库，令牌桶适合保护下游脆弱的第三方接口，常见的限流组件包括Sentinel、Resilience4j、Nginx的limit_req模块，以及网关层的Spring Cloud Gateway内置过滤器。
限流粒度实操建议
不要只对整体入口限流,要拆细：
- 接口级限流：每个URL单独配置阈值，比如登录接口限流100次/秒，下单接口限流50次/秒
- 用户级限流：同一用户每秒最多N次请求，防止单账号刷接口
- IP级限流：防止爬虫或攻击，但注意办公楼出口IP会误伤，要搭配白名单
阈值怎么定？推荐压测得出基线，用JMeter或wrk对核心接口打满压力，观察RT出现拐点时的QPS，取该值的70%作为限流阈值，留30%余量给正常波动。
限流后的降级动作
限流不是只返回报错,更优的做法是分层降级：
- 第一层：动态调整限流阈值，允许排队，比如返回503并附带Retry-After头
- 第二层：返回兜底数据，比如缓存的热门商品信息
- 第三层：直接拒绝，记录日志供后续分析
降级开关要能一键操作,通过配置中心实时下发，不需要重启应用。
扩容和限流的协同配合顺序
先扩容还是先限流？看时间窗口
如果是突发流量（提前半小时才感知），先限流保证系统不挂，同时立刻扩容，如果是可预知的峰值（双11、春节抢票），提前一周就要扩容到位，限流只作为最后防线。
一个常见误区：以为扩容后就不需要限流，实际上存在“雪崩效应”，流量短时间翻倍，扩容的机器还在启动中，老机器已经过载，此时限流反而能保护新机器成功注册，所以流程模板如下：
- 监控系统发出扩容告警
- 自动规则先开启弹性扩容,同时将限流阈值临时下调20%
- 等待新节点健康检查通过后,再恢复限流阈值
- 如果扩容后仍持续打满,继续下调阈值，直到流量平稳
如何预估需要扩多少容量
没有精确公式,但可参考历史数据，统计最近一年内最大的三次峰值流量，计算它们的平均值，再乘以1.5倍余量，比如历史最大峰值是每秒2万请求，那么这次按3万准备，如果无法预估，可以分两批扩容：第一批扩到预估值的60%，观察10分钟，再决定是否继续。
具体场景的操作路径
电商大促闪现流量高峰
假设下午3点有秒杀活动,2点开始流量爬坡，参考路径：
- 提前1小时把Redis热数据预加载,预热商品库存和详情页
- 提前30分钟开启弹性伸缩组,最小实例数调高两倍
- 秒杀接口限流阈值临时降为日常的50%，用令牌桶允许小幅突发
- 非核心接口（评价、收藏）直接降级返回空数据，不影响下单主链路
- 活动结束后10分钟恢复限流阈值,但扩容实例保持到活动结束2小时再缩容
春节抢票系统的高并发挤压
抢票业务的特点是瞬时峰值高,持续时间短，单纯靠扩容机器不划算，因为90%的时间流量很低，更合理的方式是“队列化”，把抢票请求放入消息队列，后端按固定速率消费，前端显示排队人数，限流放在接入层，每台Nginx限制该接口的连接数，避免请求打满网关，扩容只针对消息消费集群，而不是入口网关。
限流与扩容的常见坑
- 扩容后连接池未同步调大：新实例默认连接数只有10或20，需要跟随实例数量调整
- 限流阈值写死：高峰期手动改代码再发布，流程太长，应使用配置中心或监控系统联动
- 忽略网络出口带宽：流量异常增大时，服务器CPU没满但带宽先打满，扩容没用，要先扩容带宽或限流
- 监控指标只看CPU：大量短连接请求会先耗尽进程文件描述符或线程池，CPU反而不高，建议同时监控线程数和活跃连接数
Q&A：关于业务高峰期临时扩容与限流的常见疑问
问：限流算法用Nginx自带模式还是引入Sentinel好？
如果只在网关层做统一限流,Nginx的limit_req就够用，轻量且性能损耗小，但如果你需要给每个接口、每个用户差异化限流，并且要动态调整阈值，引入Sentinel更合适，它在客户端内嵌，能直接拿到方法级调用数据，也支持接入配置中心实时修改规则，具体选型取决于你被限流对象的位置：入口流量选Nginx，应用内部调用选Sentinel。
问：临时扩容需要额外购买多少机器才算够？
没有统一答案,但可以按“数据库连接数倒推”，假设你的数据库实例最大连接数是1000，现有应用连接池已占600，那么最多还能支撑大约400个连接，每个应用实例通常占用20~30个连接，那么最多额外扩13台机器，超过这个数再扩也没用，因为数据库连接会成为瓶颈，此时更应该做读写分离或缓存降级。
问：业务高峰期扩容后流量回落，应该什么时候缩容？
建议不要立刻缩容,等流量回落到峰值的30%以下且持续15分钟以上再缩容，因为缩容过程会中断正在处理的请求，如果流量还有反弹可能，会造成二次故障，使用弹性伸缩时，设置缩容策略的冷却时间拉长到600秒，避免频繁震荡。
临时扩容和限流不是对立的方案,而是同一套系统的两个安全阀。限流控制流量入口，扩容增加资源池容量，两者配合才能让业务在高峰期稳住核心链路。先把限流阈值和降级动作准备好，再按实际流量做垂直或水平扩容，并始终保留20%的冗余能力，这是多数系统稳定渡过高峰的基础配置。