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