高并发下接口耗时狂飙？这3个高可用设计让QPS从500冲到5000

关注

原创最新推荐文章于 2026-08-19 14:24:08 发布 190 阅读 AI 写同款· GEO 优化 ›

MRDIMM、GDDR7、LPDDR5X原理与应用场景解读当AI大模型训练迈入千亿参数时代，当数据中心CPU核心数突破百核大关，一个沉寂多年的“老问题”再次成为行业瓶颈——内存墙。CPU算力、PCIe带宽每年都在以两位数增速狂飙，但传统内存的带宽、容量、功耗平衡始终跟不上节奏。就在此时，三款重量级内存技术登场：MRDIMM、GDDR7、LPDDR5X，它们并非“替代关系”，而是分别瞄准数据中心高性能计算、边缘AI推理、低功耗云原生三大场景，共同掀起一场内存技术的颠覆性革命。今天我们就来深度拆解这三款“性能利器”，看看它们各自藏着什么黑科技，又能解决哪些实际痛点。阅读详情

@TOC

上回书说完，这次来点更刺激的

Day5-1咱们聊了怎么用自定义线程池 + 连接池调优把接口从3秒拉到200毫秒，单机QPS稳在500。我记得那天晚上11点改完上线，信心满满地去睡觉，结果第二天凌晨3点……电话还是响了。

运维小哥声音都劈叉了：“哥！订单接口又炸了！现在QPS没到1000，CPU直接飙到90%，响应时间5秒起步……”

我一脸懵，赶紧爬起来看监控。好家伙，真是单机能扛500，超过500就开始排队，线程池满了直接拒绝请求。老板第二天黑着脸问我：“这系统能撑住促销吗？”我说……能。但心里直打鼓。

后来我花了三个周末，硬是把QPS从500干到了5000。用的就是今天要讲的3个高可用设计：

多活架构（多台机器一起扛）
故障转移（Redis主从，自动切换）
降级策略（关键时刻保核心，弃车保帅）

这篇你读完，直接拿配置去用，QPS至少翻10倍，还能睡个安稳觉。

一、多活架构：一台机器不行，就加三台

1. 原始场景还原

先复现一下那个凌晨的惨案。咱们有个订单查询接口，核心逻辑是查MySQL，顺带查用户标签服务（内部RPC），代码大概长这样：

@RestController
public class OrderController {
    @Autowired
    private OrderService orderService;

    @GetMapping("/order/{id}")
    public Order getOrder(@PathVariable Long id) {
        return orderService.queryOrder(id);
    }
}

Day5-1已经调过自定义线程池了，Tomcat也配了：

# application.yml
server:
  tomcat:
    threads:
      max: 400
      min-spare: 100

本地用JMeter压，500QPS稳稳的。但一到1000并发，错误率直接上去，RT（响应时间）暴涨。

问题出在哪？单机天花板。CPU就2核，内存就4G，400线程全满了，新的请求排队，排到超时。这就是典型的“单活”问题——流量全压在单个节点上。

2. 多活架构的落地

所谓的“多活”，听起来高大上，说白了就是多台机器同时提供服务。咱们搞三台ECS，每个上面部署同一个Spring Boot应用，然后用Nginx做负载均衡。

架构图大概这样：

用户请求 -> Nginx -> 应用节点1 (192.168.1.10)
                  -> 应用节点2 (192.168.1.11)
                  -> 应用节点3 (192.168.1.12)

Nginx配置超级简单：

upstream order-backend {
    server 192.168.1.10:8080 weight=1;
    server 192.168.1.11:8080 weight=1;
    server 192.168.1.12:8080 weight=1;
}

server {
    listen 80;
    location /order/ {
        proxy_pass http://order-backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

人话解释：Nginx把请求平均分给三台机器，每台机器的负载从1000QPS降到了300多，理论上整体能抗的QPS变成原来的3倍。

3. 实践中的血泪教训

你可能觉得这就完了？我当时也是这么以为的，配完Nginx直接压测，结果QPS只翻了一倍多，离5000还差得远。排查半天发现两个坑：

Session粘滞问题：如果接口用了Spring Session或JWT，Nginx默认轮询，不需要粘滞，但如果业务依赖了服务器本地内存（比如用了ConcurrentHashMap存用户状态），就会导致请求发到不同节点找不到数据。血的教训：做多活前，先干掉本地内存状态，转为Redis或分布式缓存。
数据库连接数暴增：三台节点同时连MySQL，连接数从20直接飙到60，如果数据库没优化好，反而成为瓶颈。所以Day5-1的连接池调优得多机器一起考虑，每台机器的最大连接数 = 数据库总连接数 / 节点数，提前规划好。

二、故障转移：别让Redis宕机拖垮整个集群

1. 缓存雪崩的恐怖

多活搞完后，QPS上到了3000，但离5000还有距离。我一拍脑袋，加Redis！把订单数据缓存起来，数据库压力瞬间下降。

@Service
public class OrderService {
    @Autowired
    private StringRedisTemplate redisTemplate;

    public Order queryOrder(Long id) {
        String cacheKey = "order:" + id;
        String json = redisTemplate.opsForValue().get(cacheKey);
        if (json != null) {
            return JSON.parseObject(json, Order.class);
        }
        // 查数据库，再写缓存
        Order order = orderMapper.selectById(id);
        redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(order), 
                                        30, TimeUnit.MINUTES);
        return order;
    }
}

压测一看，QPS直接冲到4500，RT降到20ms，心里美滋滋。

然后，又一次深夜，告警来了。Redis实例因为内存满了挂了，重启后所有请求穿透到数据库，数据库瞬间被打崩，集群的QPS跌到0。

这就是典型的缓存雪崩 + 单点故障：Redis只有一台主库，挂了就全完。咱们需要故障转移机制。

2. Redis哨兵模式落地

Redis Sentinel（哨兵）能自动监控主从节点，主库挂了会选举新的主库，应用层几乎无感。

配置步骤（核心）：

在3台机器上分别部署一个Redis实例，一主两从。

给每个Redis配上哨兵监控。哨兵配置 sentinel.conf：

sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 15000

Spring Boot集成哨兵，YAML配置：

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.1.10:26379
        - 192.168.1.11:26379
        - 192.168.1.12:26379
    lettuce:
      pool:
        max-active: 50
        min-idle: 10

这样，主库挂了，哨兵自动把从库提升为主库，你的Spring Boot应用通过哨兵拿到新地址，整个集群继续服务。我那次凌晨3点就是没配哨兵，手动登录机器改配置，足足搞了40分钟。

3. 故障转移带来的QPS提升

加了哨兵后，即使Redis出问题，故障转移在15秒内完成，期间因为熔断降级（下面会讲），接口不至于全挂，数据库也能顶住。单节点缓存可靠性从“看天吃饭”变成了自动修复，整体集群的可用性直接拉满。

数据说话：加上哨兵后，集群抗住了一波5000QPS压测，RT稳定在30ms以内，0错误。

三、降级策略：关键时刻，保命要紧

1. 不是所有功能都值得死扛

上了多活和故障转移，按理说可以躺平了。但有一天运营搞了个“新品推荐”活动，用户点进订单页时，后台会调用一个推荐服务，返回你可能喜欢的商品。这个推荐服务偶尔会慢到2秒，导致整个订单接口被拖慢。

我又被老板叫去：“为什么订单接口这么慢？推荐不显示也行啊，先把订单展示出来！”

对啊，非核心功能，关键时刻可以降级。

2. Resilience4j 实现降级

Spring Boot 3.x 原生支持Resilience4j，咱们用它来实现熔断+降级。

添加依赖：

<dependency>
    <groupId>io.github.resilience4j</groupId>
    <artifactId>resilience4j-spring-boot3</artifactId>
</dependency>

编写推荐服务调用，加上降级逻辑：

@Service
public class RecommendService {
    
    @CircuitBreaker(name = "recommendBackend", fallbackMethod = "fallbackReco")
    public List<Product> getRecommendProducts(Long userId) {
        // 远程调用推荐服务，可能很慢
        return restTemplate.postForObject("http://reco-service/api/reco", userId, List.class);
    }

    // 降级方法：返回空列表或默认推荐
    public List<Product> fallbackReco(Long userId, Throwable t) {
        log.warn("推荐服务降级，返回空列表。原因：{}", t.getMessage());
        return Collections.emptyList();
    }
}

YAML配置熔断规则：

resilience4j:
  circuitbreaker:
    instances:
      recommendBackend:
        sliding-window-size: 10           # 窗口大小
        failure-rate-threshold: 50        # 失败率超过50%就熔断
        wait-duration-in-open-state: 30s  # 熔断30秒后尝试半开
        permitted-number-of-calls-in-half-open-state: 3
        slow-call-rate-threshold: 100     # 慢调用阈值
        slow-call-duration-threshold: 1s  # 超过1秒视为慢调用

人话解释：当推荐服务最近10次调用中失败或超时比例超过50%时，熔断器打开，接下来30秒内所有调用直接走降级方法（返回空列表），避免拖垮整个订单接口。30秒后尝试少量请求，如果恢复正常就关闭熔断器。

3. 降级策略带来的压测效果

我把这个配置上线后，再压5000QPS，即使故意把推荐服务延迟调到5秒，订单接口的RT一直稳定在40ms以内。因为一旦触发熔断，推荐调用直接短路，主流程丝毫不受影响。

对比数据：

| 方案 | QPS能力 | 平均RT(ms) | 99线(ms) | 错误率 | |------|---------|-----------|----------|--------| | 单机+无缓存 | 500 | 200 | 1200 | 5% | | 三节点集群+缓存 | 4500 | 20 | 150 | 0.1% | | 集群+缓存+降级 | 5000 | 18 | 100 | 0% |

看到了吧，降级策略不光是可用性的保障，还能在异常场景下稳住性能。

四、避坑指南：这些烂坑，我全踩过

⚠️ 坑1：多活≠随便加机器 我早期觉得加机器就能线性提升QPS，结果加到5台时，QPS不升反降。排查发现数据库连接池满了，每台机器默认连20个，5台就是100个，MySQL配置的max_connections只有100。解决：统一调配连接池大小，用HikariCP的maximumPoolSize限制，总共别超过数据库上限。血的教训：先评估数据库和中间件的承载能力，再决定加多少节点。