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

在高并发架构中如果说缓存和 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削峰填谷本质上就是漏桶思想。核心逻辑用户的请求就像是“往桶里倒水”倒水的速度可以非常快、非常狂暴。如果倒水太快导致桶满了溢出来的水请求直接被无情抛弃。系统处理请求的速度就像桶底“漏水”的速度这个速度是永远恒定的比如绝对的 100个/秒。痛点太死板了即使你的服务器现在闲得发慌遇到突发的一小波流量它也只能慢吞吞地以恒定速度滴水。它完全缺乏应对合理突发流量的弹性。四、 令牌桶算法Token Bucket大厂实战的最优解这是目前业界使用最广泛的算法各大 API 网关默认首选。它完美融合了“平滑限流”和“允许突发流量”的需求。核心逻辑这次我们换个思路桶里装的不再是请求而是“通行证Token”。系统会以一个恒定的速度比如 100个/秒往桶里“放入”令牌。桶的容量是有限的比如最多装 500 个令牌。如果桶满了新生成的令牌就会被丢弃。当一个请求过来时它必须从桶里拿走一个令牌才能被系统处理。如果桶里没令牌了请求就被拒绝。终极杀招弹性突发假设系统闲置了一段时间桶里已经攒满了 500 个令牌。此时突然有一波 500 个并发请求砸过来令牌桶可以瞬间把 500 个令牌全部发出去让这波突发流量瞬间通过随后它又会恢复到 100个/秒 的平稳限制。这就是它的王牌优势。五、 令牌桶代码实战、分布式限流代码Redisson 落地下面我们直接拉起一个标准的生产级分布式限流示例。使用非阻塞的tryAcquire()快速失败机制当请求拿不到令牌时立刻触发限流兜底。1. 引入 Maven 依赖XMLdependency groupIdorg.redisson/groupId artifactIdredisson/artifactId version3.27.0/version /dependency2. 核心限流引擎实现Javaimport 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. 【核心配置】设置限流规则 // 参数1RateType.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(); } }深入底层Redisson 是如何避免“系统休克”的在前面的设计中聪明的架构师一定会问一个深刻的问题“如果 Redis 里的限流器空闲了很久突然放进去一个巨大的并发会不会瞬间把系统冲垮”仔细观察rateLimiter.trySetRate(RateType.OVERALL, 5, 1, RateIntervalUnit.SECONDS)这行代码。Redisson 在内部 Lua 脚本中做了一个非常聪明的防御设定在一个时间窗口如 1 秒内允许积攒的最大令牌总数是严格受限于你设置的rate值即 5 个的。这意味着即使你的系统在深夜几个小时无人访问全局水桶里的令牌也不会无限膨胀到几万个。当第二天的第一波突发流量砸过来时Redis 最多也只会瞬间放行 5 个请求后续的请求依旧要严格按照“每秒生成 5 个”的平滑速率规律流转。这在分布式架构中被称为“防休克保护Anti-Shock Protection”完美兼顾了对突发流量的轻度弹性又死死守住了后端持久层数据库的最后一道红线。结语高并发架构没有银弹。如果你要保护的是绝对不能承受突发压力的老旧底层数据库选漏桶。如果你要保护的是对外暴露的 Web API 接口希望在平时平滑限制偶尔遇到大促又能扛住一波突发的积攒流量果断选令牌桶。认清每种算法的脾气才能给你的服务器配上最合适的“冷面保安”。