如果你的系统的 QPS 突然提升 10 倍，你会怎么设计？（持续更新中）

一键三连，让算法推荐更多类似干货 ~  
你最近面试被问到的最难的题是什么？         评论区交流，我来解答。
突然发现自己欠了一屁股 技术债 ？               别薅头发了  ——   关注本专栏，带你清债～

（一）口诀：

QPS 突增别慌张，应急扩容先顶上；
硬件缓存加限流，核心业务保正常；
长期拆分读写离，分库分表扛量大；
压测预案提前做，十倍流量也敢闯。

（二）答案：

系统 QPS 突然提升 10 倍时，需结合短期应急和长期扩容双维度设计方案，核心思路是 “先扛住再优化”，具体措施如下：

一、短期应急方案（1 小时内见效）

1、硬件与网络层扩容

服务器：快速扩容应用服务器集群（如通过云平台弹性伸缩，5 分钟内新增 10 倍实例），确保能承接基础流量。

网络：临时提升带宽，避免因网络拥堵导致请求失败；启用 CDN 承载静态资源，分流 80% 静态请求。

2、缓存紧急强化

本地缓存：在应用层新增 Caffeine 本地缓存，缓存高频访问的静态数据（如商品基础信息），减少 Redis 请求。

Redis 扩容：临时增加 Redis 集群分片数，提升缓存读写能力；开启 “热点 key” 自动识别，对高频 key 增加副本。

3、流量控制与削峰

限流：Nginx 层按 IP 限流（如单 IP 每分钟最多 10 次请求），业务层用令牌桶算法限制核心接口 QPS（如订单接口限制为原 10 倍）。

削峰：非核心接口（如评价、收藏）暂时降级为 “只读”，用 RocketMQ 异步处理写请求；核心接口（如下单）优先保障，非核心参数（如优惠券）暂时忽略校验。

二、长期扩容方案（24 小时内落地）

架构层优化

微服务拆分：将单体应用拆分为独立服务（如订单、商品、支付），各自独立扩容，避免某模块瓶颈影响整体。

读写分离：数据库开启读写分离，读请求路由到从库，主库仅处理写请求；新增从库数量，提升读能力 10 倍。

存储层强化

分库分表：对高频写表（如订单表）按用户 ID 哈希分库，将数据分散到 10 个库，降低单库压力。

冷热数据分离：历史订单等冷数据迁移到低成本存储（如 HBase），仅保留近 3 个月热数据在 MySQL，提升查询效率。

全链路压测与预案

模拟 10 倍 QPS 压测，定位瓶颈（如某 Redis 节点性能不足、数据库索引失效），针对性优化。

制定降级预案：明确核心 / 非核心功能清单，QPS 超阈值时自动降级非核心功能（如关闭推荐商品），释放资源。

零、为什么必须分 “短期应急” 和 “长期扩容”？

突发 10 倍 QPS 的场景（如突然上热搜、大 V 带货）往往具有 “紧迫性” 和 “阶段性”：

• 短期（1 小时内）：流量已经压过来，系统随时可能崩溃，首要目标是 “先扛住，不宕机”，措施必须能快速落地（分钟级 / 小时级），不能依赖复杂架构改造；
• 长期（1-7 天）：流量可能持续一段时间（如促销活动持续 3 天），需要从根本上提升系统承载能力，避免反复应急，措施需兼顾稳定性和可扩展性。

先治标再治本 。

• 短期措施是 “救命稻草”，解决 “现在就崩溃” 的问题；
• 长期措施是 “强身健体”，解决 “未来还会崩溃” 的问题。

（三）STAR 法则回答：

情境（S）：

电商平台日常 QPS 为 1 万，某促销活动突发流量，QPS 瞬间升至 10 万，系统响应延迟超 5 秒，部分接口超时。

任务（T）：

1 小时内恢复系统稳定，24 小时内实现支撑 10 万 QPS 的长期方案，保证核心业务（下单、支付）可用。

行动（A）：

短期应急：

扩容应用服务器至 10 台，Redis 集群新增 5 个分片，CDN 承载静态资源，分流 60% 请求；

Nginx 按 IP 限流（单 IP / 分钟 5 次），非核心接口（评价）降级为异步处理，用 RocketMQ 缓冲请求。

长期优化：

将订单模块拆分为独立微服务，部署 20 个实例；数据库拆分为 1 主 10 从，订单表按用户 ID 分 10 库；

压测后优化 Redis 热点 key（增加副本）、数据库索引（新增订单表用户 ID + 时间索引），制定降级预案（QPS 超 12 万时关闭推荐功能）。

结果（R）：

1 小时内系统响应延迟降至 200ms，核心接口成功率 100%；

24 小时后长期方案落地，稳定支撑 10 万 QPS，后续活动中未再出现性能问题，用户投诉量下降 90%。

（四）生活例子：

类比 “餐厅突然涌入 10 倍客人”：

• 短期应急：临时加桌子（硬件扩容），只上招牌菜（核心功能优先），让客人先排队拿号（限流），后厨先做简单菜品（异步处理）；
• 长期扩容：扩建餐厅（架构拆分），增加厨师和服务员（服务集群），分开凉菜区和热菜区（读写分离），提前备料（缓存预热）。

---

可忽略以下旧答案：

一、口诀：

QPS 突增莫慌张，分层设计来扛；

CDN 挡流量，WAF 拦恶意；

网关先限流，服务再降级；

缓存多级建，数据分片存；

监控全链路，预案提前备。

二、生活例子

场景：火锅店突然涌入 10 倍客人（从 100 人 / 小时 → 1000 人 / 小时）

1、门口拦截：

保安（CDN）：引导客人先看菜单（静态资源），避免全挤到收银台

迎宾（WAF）：拦住闹事的人（恶意请求），只放正常客人进入

2、店内分流：

取号机（限流）：限制同时进入的人数（如最多 100 人在店）

服务员（熔断）：告诉客人甜品供应完了（非核心业务熔断）

3、后厨优化：

预制菜（缓存）：热门菜提前切好（本地缓存），直接下锅

多灶台（分库分表）：把一个大厨房拆成 10 个小厨房（分库），每个负责一类菜

4、供应链保障：

实时补货（弹性伸缩）：发现食材快用完，立即通知供应商加送

三、答案：

（1）微服务的拆分

（2）高性能 RPC

（3）消息队列削峰解耦

（4）三级缓存架构

（5）分库分表
（6）高可用

a）熔断
b）限流
c）降级
d）预案
e）核对

1. 分层应对策略

（1）流量拦截层

1）CDN：静态资源全量缓存（命中率需 > 90%），动态内容走网关

2）WAF：实时拦截恶意请求（如 CC 攻击），规则动态更新

3）验证码：人机识别，防爬虫和自动化工具

（2）流量控制层

1）网关限流：按用户 / IP / 接口限流（如单机 5000QPS → 集群 50 万 QPS）

2）熔断降级：非核心业务直接熔断（如评论、推荐），SLA 降级到 90%

3）削峰填谷：消息队列异步处理（如订单创建），最大堆积量需评估

（3）缓存层

1）多级缓存：本地缓存（Caffeine）+ 分布式缓存（Redis 集群）

2）热点数据：预加载到本地缓存，Redis 用读写分离集群（主节点写，从节点读）

3）缓存失效策略：LRU+TTL 结合，避免缓存雪崩

（4）数据层

1）分库分表：单库 10 万 QPS → 拆分为 10 个库，每个库 1 万 QPS

2）读写分离：主库写，从库读（3 个从节点分担读压力）

3）索引优化：覆盖索引减少回表，慢查询自动告警

（5）服务层

1）微服务拆分：按业务领域拆分（如用户、订单、支付），独立扩容

2）RPC 优化：Dubbo（高性能）替代 Feign（适合中小流量），压缩请求体

3）异步化：非关键路径用 MQ 异步处理（如日志记录、短信通知）

2. 技术选型细节

RPC 框架：

Feign → Dubbo：Dubbo 吞吐量约为 Feign 的 3 倍（实测数据），且支持连接池复用、异步调用

协议优化：默认 HTTP/1.1 → gRPC（二进制协议，性能提升 50%+）

消息队列：

RocketMQ → Kafka：Kafka 吞吐量更高（单集群可达百万 QPS），适合纯异步场景

配置优化：Kafkaacks=0（牺牲少量可靠性换极致性能），批量发送（batch.size=16384）

数据库：

MySQL → TiDB：TiDB 支持水平扩展，单集群可支撑百万 QPS（需分表 1000+）

缓存穿透防护：布隆过滤器拦截不存在的 key

3. 监控与预案

全链路监控：

调用链：Skywalking/Zipkin 实时追踪，定位性能瓶颈

指标监控：QPS、RT、错误率，阈值动态调整（如 RT>200ms 自动熔断）

应急预案：

降级开关：通过配置中心（如 Nacos）动态关闭非核心功能

熔断策略：Sentinel 熔断规则（如接口错误率 > 5% 自动熔断）

弹性伸缩：云服务器 ECS 根据负载自动扩缩容（需提前压测确定资源模型）

---

一键三连，让算法推荐更多类似干货 ~            持续更新中，点关注，看下篇文章。
你最近面试被问到的最难的题是什么？           评论区交流，我来解答。
突然发现自己欠了一屁股 技术债 ？                 别薅头发了  ——   关注本专栏，带你清债～