百万并发下的限流与熔断：从 Guava 到 Sentinel 实战

在构建高并发系统时，我们总是致力于提升 QPS（吞吐量）。我们加缓存、上消息队列、切分数据库…… 但物理资源终究是有极限的。当“双十一”的秒杀流量或者恶意的爬虫攻击如海啸般涌来，瞬间流量超过了系统承载能力的 10 倍。

此时，如果你没有任何保护措施，你的线程池会被瞬间打满，紧接着 CPU 100%，数据库连接池耗尽，最后整个系统雪崩，所有用户都无法访问。

在 2026 年的架构防御战中，限流（Rate Limiting）与熔断（Circuit Breaking） 是保命的最后两道大门。

1. 面试必问的四大限流算法底座

在实操工具之前，你必须懂算法。目前的限流工具底层逃不出这四种模型：

固定窗口（Fixed Window）：最简单。在 Redis 里设个 Key，一分钟最多 100 次，过期时间 1 分钟。缺陷：临界点突刺。如果用户在第 59 秒发了 100 次，在第 1 分钟 01 秒又发了 100 次，实际上两秒内系统承受了 200 次请求，限流失效。
滑动窗口（Sliding Window）：固定窗口的改进版。把一分钟切分成 6 个 10 秒的小格子，时间往前推移时，废弃最老的格子。这是目前统计 QPS 最精准的方案。
漏桶算法（Leaky Bucket）：像一个漏水的桶。无论上游水流多大多狂暴，桶底下漏出来的水（放行到业务系统的请求）速度是恒定的。优势：绝对平滑的流量整形（Traffic Shaping）。劣势：无法应对突发的合法流量。
令牌桶算法（Token Bucket）：系统以恒定的速度往桶里放 Token，请求来了必须拿走一个 Token 才能执行。如果桶满了 Token 就会溢出。优势：因为桶里可以预存 Token，它允许系统在瞬间处理一波突发洪峰流量，是目前绝大多数限流框架的首选。

2. 单机限流的轻骑兵：Guava RateLimiter

如果你的项目比较小，或者你只想对单台机器内部的某个耗时方法（比如导出 Excel 报表）做个保护，不需要去搞什么高大上的集群配置。

直接使用 Google 的 Guava RateLimiter，它是经典的令牌桶算法实现。

// 创建一个限流器，每秒生成 5 个令牌（限制 QPS 为 5）
private final RateLimiter rateLimiter = RateLimiter.create(5.0);

public void exportData() {
    // tryAcquire 尝试获取令牌，最多等 0.5 秒。等不到直接拉倒，不阻塞线程
    if (rateLimiter.tryAcquire(500, TimeUnit.MILLISECONDS)) {
        // 拿到令牌，执行耗时的报表导出
        database.heavyQuery();
    } else {
        // 没拿到令牌，直接抛异常或返回提示
        throw new RuntimeException("当前导出人数过多，请稍后再试！");
    }
}

3. 分布式防护重型装甲：Alibaba Sentinel

在 2026 年的微服务网关集群里，单机限流显然不够看了。如果你们有 10 台网关节点，总 QPS 要限制在 10,000 以内。我们需要全局的防护墙。

曾经的王者是 Netflix Hystrix，但它早已停止维护。现在国内的绝对标准是 Alibaba Sentinel。

Sentinel 不仅支持集群限流，更可怕的是它在熔断降级和自适应保护上的造诣。

场景一：接口限流保护 (Flow Control)

你可以直接在管理后台配置：/api/order/create 这个接口，整个集群每秒最多放行 2000 个请求。多出来的请求直接触发 BlockException 返回给前端“活动太火爆”。

场景二：熔断降级 (Circuit Breaking) - 防止被猪队友拖死

微服务最怕的是“雪崩效应”。你的服务 A 调用了服务 B。某天服务 B 的数据库卡了，原本 10ms 的接口变成了 10s 才返回。此时服务 A 所有的线程都会因为等待 B 而被卡死，最终导致 A 也崩溃。

Sentinel 的熔断器会在后台偷偷算一笔账：如果发现过去一分钟内，调用 B 服务的接口慢请求比例超过了 50%，或者异常率超过了 20%。 Sentinel 会直接**“熔断（断路器打开）”**。此后 A 调用 B 的请求，根本不会发出去网络包，而是在 A 本地瞬间直接返回一个 Fallback（默认降级数据）。等 B 恢复健康了，Sentinel 还会半开（Half-Open）去试探一下，确认没问题了再恢复流量。

场景三：系统自适应保护 (System Load Protection)

这是 Sentinel 最黑科技的地方。有时候你根本不知道你的接口应该限流多少 QPS（因为随着新代码上线，性能一直在变）。你可以开启系统的自适应保护：不管 QPS 是多少，只要 Sentinel 探针发现当前 Linux 服务器的 CPU 使用率飙升到了 80% 以上，或者系统 Load (负载) 超过了危险线，它就会自动开始拒接新的入口流量。这是一种完全基于机器物理体征的绝对防御。

总结

一个没有限流和熔断措施的系统，就像是在雷雨天裸奔。

保护内部单点耗时方法，用轻量的 Guava RateLimiter。
保护微服务集群、处理上游接口超时拖垮雪崩、实现可视化运维，全面拥抱 Sentinel。

记住，真正的架构师不仅要考虑系统正常时跑得有多快，更要考虑系统面临崩溃时，如何以最体面的方式断臂求生。