"假设你负责的系统，某个业务线的QPS突然暴增100倍，你会怎么应对？"
------这是上周朋友去面试，被问到一道题，他答了"加机器扩容"，结果面试官眉头一皱："如果机器不够呢？如果数据库崩了呢？"朋友当场卡壳。其实这道题就像"高压水枪"，专冲知识漏洞。
作为开发者，如果只回答"加机器""扩容"，可能直接暴露知识盲区。
真正的答案，需要从架构设计、资源调度、容灾兜底等多个维度拆解。
第一步：先问"为什么"，再想"怎么做"
面对突发流量，盲目优化=挖坑埋自己 。
先理清关键问题：
QPS来源是否合理？
- 是正常业务爆发（如双十一促销），还是异常流量（如恶意攻击、代码BUG）？
- 若是异常，需优先拦截（风控、限流），而非盲目扩容。
流量暴增的范围和时间？
- 是全局流量激增，还是单个接口/功能？
- 是短期高峰（如秒杀），还是长期持续？
当前系统的瓶颈在哪里？
- CPU/内存/磁盘/网络？
- 数据库？缓存？第三方服务？
第二步：分层拆解，针对性优化
快速止血：限流降级，保住核心业务
- 限流 ：对非核心接口设置QPS阈值（如令牌桶算法），超限请求直接熔断。
- 降级 ：关闭次要功能（如评论、推荐），确保核心链路（如支付、下单）可用。
- 预案 ：提前配置好降级开关，通过配置中心实时生效。
横向扩展：无状态服务快速扩容
- 容器化+弹性伸缩 ：Kubernetes自动扩缩容，应对流量波动。
- 负载均衡 ：调整权重，将流量分流到压力较小的节点。
- 注意点 ：确保服务无状态，避免扩容后Session丢失等问题。
缓存为王：减少穿透击穿数据库
- 本地缓存 ：高频读数据（如商品信息）。
- 分布式缓存 ：Redis集群抗住大部分查询请求，设置多级缓存架构。
- 缓存预热 ：提前加载热点数据，避免冷启动雪崩。
数据库优化：分库分表+读写分离
- 读写分离 ：主库负责写，从库集群承担读请求。
- 分库分表 ：按业务拆分（用户库、订单库），或按Hash分片。
- 连接池优化 ：调整最大连接数、超时时间，避免线程阻塞。
异步化：削峰填谷，解耦系统
- 消息队列 ：Kafka/RocketMQ承接突发流量，后端异步消费。
- 批量处理 ：合并多次请求（如库存扣减），减少数据库压力。
第三步：长期防御，构建弹性架构
全链路压测
- 定期模拟极端流量，暴露系统瓶颈（如数据库连接池耗尽、慢SQL）。
- 阿里的"全链路压测"已成为大厂标配。
监控告警体系
- 关键指标实时监控：CPU、内存、QPS、RT、错误率。
- 设置多级阈值（预警、严重、致命），通过企业微信/钉钉通知。
容灾演练
- 定期演练机房断电、网络分区、缓存崩溃等极端场景。
- 确保故障发生时，能自动切换灾备节点。
总结：高并发的本质是"分治"
应对突发流量的核心逻辑：
🔹 横向拆分 ：用空间换时间（扩容、分库分表）。
🔹 纵向分层 ：每层专注单一问题（缓存、异步、限流）。
🔹 冗余设计 ：假设任何环节都会挂，做好兜底方案。
如果老板要求"零预算优化"，不能加机器，你会怎么做？
欢迎评论区讨论！💡
