如果某个业务量突然提升100倍QPS你会怎么做？

“假设你负责的系统，某个业务线的QPS突然暴增100倍，你会怎么应对？”需要从架构设计、资源调度、容灾兜底等多个维度拆解。

第一步：先问“为什么”，再想“怎么做”

面对突发流量，盲目优化=挖坑埋自己。先理清关键问题：

QPS来源是否合理？

是正常业务爆发（如双十一促销），还是异常流量（如恶意攻击、代码BUG）？
若是异常，需优先拦截（风控、限流），而非盲目扩容。

流量暴增的范围和时间？

是全局流量激增，还是单个接口/功能？
是短期高峰（如秒杀），还是长期持续？

当前系统的瓶颈在哪里？

CPU/内存/磁盘/网络？
数据库？缓存？第三方服务？

第二步：分层拆解，针对性优化

快速止血：限流降级，保住核心业务

限流：对非核心接口设置QPS阈值（如令牌桶算法），超限请求直接熔断。
降级：关闭次要功能（如评论、推荐），确保核心链路（如支付、下单）可用。
预案：提前配置好降级开关，通过配置中心实时生效。

横向扩展：无状态服务快速扩容

容器化+弹性伸缩：Kubernetes自动扩缩容，应对流量波动。
负载均衡：调整权重，将流量分流到压力较小的节点。
注意点：确保服务无状态，避免扩容后Session丢失等问题。

缓存为王：减少穿透击穿数据库

本地缓存：高频读数据（如商品信息）。
分布式缓存：Redis集群抗住大部分查询请求，设置多级缓存架构。
缓存预热：提前加载热点数据，避免冷启动雪崩。

数据库优化：分库分表+读写分离

读写分离：主库负责写，从库集群承担读请求。
分库分表：按业务拆分（用户库、订单库），或按Hash分片。
连接池优化：调整最大连接数、超时时间，避免线程阻塞。

异步化：削峰填谷，解耦系统

消息队列：Kafka/RocketMQ承接突发流量，后端异步消费。
批量处理：合并多次请求（如库存扣减），减少数据库压力。

第三步：长期防御，构建弹性架构

全链路压测

定期模拟极端流量，暴露系统瓶颈（如数据库连接池耗尽、慢SQL）。阿里的“全链路压测”已成为大厂标配。也可以定期压测跑自动化用例。

监控告警体系

关键指标实时监控：CPU、内存、QPS、RT、错误率。
设置多级阈值（预警、严重、致命），通过企业微信/钉钉通知。

容灾演练

定期演练机房断电、网络分区、缓存崩溃等极端场景。
确保故障发生时，能自动切换灾备节点。