当前位置：首页 > news >正文

扛住十万并发的“冷面保安”：一文扒透限流的四大经典算法与代码实战

news 2026/5/25 13:58:13

在高并发架构中，如果说缓存和 MQ 是替服务器扛伤害的“防弹衣”，那么限流（Rate Limiting）就是守在系统大门外的“冷面保安”。

他的核心逻辑极其冷酷：不管外面排队的人有多急，只要超过了系统的最大接待能力，多出来的人直接拒之门外（或者拉入等待区返回 429 Too Many Requests）。

为了把这位“保安”训练得既严格又懂变通，前人总结了四种最经典的限流算法。今天，我们就由浅入深，一层层扒开它们的底裤，并用一段极简的代码，实战演练目前大厂使用频率最高的那一个。

一、固定窗口算法（Fixed Window）：最死板的保安

这是最简单粗暴的算法，适合用 Redis 的INCR命令结合过期时间快速实现。

核心逻辑：设定一个时间窗口（比如 1 分钟）和一个阈值（比如 100 次）。在一分钟内，来一个请求就记一次数。一旦达到 100，后续请求全部拒绝。等下一个 1 分钟到来，计数器清零，重新开始。
致命痛点（临界点突刺）：假设 0:59 秒瞬间涌入 100 个请求，计数器满了；到了 1:00 秒，计数器清零，又瞬间涌入 100 个请求。对于系统来说，它在 2 秒钟内承受了 200 个请求的暴击，而限流器竟然觉得“很合理”。这极易导致系统在这个临界点被打崩。

二、滑动窗口算法（Sliding Window）：精细化的查岗

为了解决固定窗口的“临界点突刺”问题，滑动窗口应运而生（TCP 协议底层的流量控制也是这个思想）。

核心逻辑：把 1 分钟的窗口划分成多个更小的“格子”（比如 6 个格子，每个格子 10 秒）。随着时间推移，这个窗口会以 10 秒为单位向前“滑动”。统计的时候，只统计当前窗口包含的 6 个格子里的总请求数。
优势与代价：完美抹平了临界点突刺。你划分的格子越细（比如精细到 1 秒 1 个格子），限流就越平滑。代价是需要在内存里记录每个小格子的访问记录，稍微费点内存。

三、漏桶算法（Leaky Bucket）：绝对的“强迫症”

如果我们希望系统以绝对稳定、不可改变的速率处理请求，就像工厂的流水线一样，漏桶算法就是最佳选择。常见的消息队列（MQ）削峰填谷，本质上就是漏桶思想。

核心逻辑：
1. 用户的请求就像是“往桶里倒水”，倒水的速度可以非常快、非常狂暴。
2. 如果倒水太快导致桶满了，溢出来的水（请求）直接被无情抛弃。
3. 系统处理请求的速度，就像桶底“漏水”的速度，这个速度是永远恒定的（比如绝对的 100个/秒）。
痛点：太死板了！即使你的服务器现在闲得发慌，遇到突发的一小波流量，它也只能慢吞吞地以恒定速度滴水。它完全缺乏应对合理突发流量的弹性。

四、令牌桶算法（Token Bucket）：大厂实战的最优解

这是目前业界使用最广泛的算法（各大 API 网关默认首选）。它完美融合了“平滑限流”和“允许突发流量”的需求。

核心逻辑：这次我们换个思路，桶里装的不再是请求，而是“通行证（Token）”。
1. 系统会以一个恒定的速度（比如 100个/秒）往桶里“放入”令牌。
2. 桶的容量是有限的（比如最多装 500 个令牌）。如果桶满了，新生成的令牌就会被丢弃。
3. 当一个请求过来时，它必须从桶里拿走一个令牌，才能被系统处理。如果桶里没令牌了，请求就被拒绝。
终极杀招（弹性突发）：假设系统闲置了一段时间，桶里已经攒满了 500 个令牌。此时突然有一波 500 个并发请求砸过来，令牌桶可以瞬间把 500 个令牌全部发出去，让这波突发流量瞬间通过！随后，它又会恢复到 100个/秒的平稳限制。这就是它的王牌优势。

五、令牌桶代码实战、分布式限流代码：Redisson 落地

下面我们直接拉起一个标准的生产级分布式限流示例。使用非阻塞的tryAcquire()快速失败机制，当请求拿不到令牌时，立刻触发限流兜底。

1. 引入 Maven 依赖

XML

<dependency> <groupId>org.redisson</groupId> <artifactId>redisson</artifactId> <version>3.27.0</version> </dependency>

2. 核心限流引擎实现

Java

import org.redisson.Redisson; import org.redisson.api.RRateLimiter; import org.redisson.api.RateIntervalUnit; import org.redisson.api.RateType; import org.redisson.config.Config; import java.time.LocalTime; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class DistributedRateLimiterDemo { public static void main(String[] args) throws InterruptedException { // 1. 初始化 Redisson 客户端配置（连接本地 Redis） Config config = new Config(); config.useSingleServer() .setAddress("redis://127.0.0.1:6379"); // .setPassword("your_password"); // 有密码则配置 Redisson redisson = (Redisson) Redisson.create(config); // 2. 获取一个全局分布式限流器对象 // 这个 Key 会持久化在 Redis 中，所有集群节点使用同一个 Key 即可实现全局联动 RRateLimiter rateLimiter = redisson.getRateLimiter("global_order_limiter"); // 3. 【核心配置】：设置限流规则 // 参数1：RateType.OVERALL 表示这 5 个令牌是给整个微服务集群共享的，而不是单机 // 参数2：每个时间窗口内产生的令牌数 (5个) // 参数3：时间窗口的长度 (1) // 参数4：时间窗口的单位 (秒) // 综合含义：整个分布式集群，每 1 秒钟一共只生成 5 个令牌 rateLimiter.trySetRate(RateType.OVERALL, 5, 1, RateIntervalUnit.SECONDS); System.out.println("🚀 分布式限流器初始化成功，开始模拟集群并发压测..."); // 4. 模拟高并发线程池（代表多台服务器同时收到了并发流量） ExecutorService executorService = Executors.newFixedThreadPool(15); for (int i = 1; i <= 15; i++) { final int requestId = i; executorService.submit(() -> { try { // 【高并发核心防线】：非阻塞式尝试获取 1 个令牌 // tryAcquire() 会瞬间返回结果，绝不卡死当前线程 boolean hasToken = rateLimiter.tryAcquire(1); if (hasToken) { // 拿到了全局令牌，允许执行高价值的业务逻辑（如写 MySQL、调用支付接口） System.out.println(LocalTime.now() + " | 节点线程 | ✅ 请求 " + requestId + " 抢到全局令牌，成功进入下单主链路！"); } else { // 没抢到令牌，直接触发限流快速失败，返回友好提示或走降级逻辑 System.out.println(LocalTime.now() + " | 节点线程 | ❌ 请求 " + requestId + " 被全局限流拦截 -> 返回提示: [服务太火爆，请稍后再试]"); } } catch (Exception e) { e.printStackTrace(); } }); } // 优雅关闭 executorService.shutdown(); // 生产环境中，通常伴随应用销毁时关闭 redisson 实例 // redisson.shutdown(); } }