如果你的系统的 QPS 突然提升 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 根据负载自动扩缩容（需提前压测确定资源模型）

点赞多，会持续更新！