分布式限流算法的比较

作为程序员，经常被面试官问："分布式系统如何应对突发流量？" 今天咱就唠唠常见的分布式限流算法，结合实际场景比较它们的优缺点。

一、为什么需要分布式限流？

在分布式系统中，单节点限流（如Nginx）扛不住跨服务调用。比如双十一秒杀，流量瞬间打爆服务节点——限流算法就是系统的"保险丝"，防止雪崩。

面试鸭返利网
图：流量洪峰示意图

二、主流限流算法对比

1. 固定窗口计数器

原理：每1秒统计请求数，超过阈值就拒绝。
✅ 优点：Redis的INCR就能实现，简单粗暴。
❌ 缺点：窗口边界突发流量可能超载。比如0.9秒时涌进100个请求，1.1秒又涌进100个，实际0.9-1.1秒的200请求会压垮系统。

2. 滑动窗口计数器

原理：把1秒拆成10个100ms小窗口，统计连续N个小窗口的请求和。
✅ 解决固定窗口的边界问题
❌ 内存消耗高（需存储多窗口数据），适合Redis + Lua实现

graph LR
A[请求进入] --> B{当前小窗口计数+1}
B --> C[统计最近10个窗口总和]
C --> D{>阈值?}
D -->|是| E[拒绝]
D -->|否| F[通过]

3. 令牌桶算法（面试高频！）

原理：系统以固定速率向桶里放令牌，请求需抢到令牌才能通过。
✅ 允许突发流量（桶内有存量令牌）
✅ Guava RateLimiter、Sentinel都在用
❌ 分布式场景需用Redis + Lua保证原子性

4. 漏桶算法

原理：请求像水一样流入漏桶，桶以恒定速率出水（处理请求）。
✅ 绝对平滑流量
❌ 突发流量时延迟高（需排队）
❗️对比令牌桶：漏桶控制处理速率，令牌桶控制请求速率

面试鸭返利网
图：令牌桶 vs 漏桶

三、生产环境怎么选？

| 算法 | 适用场景 | 开源实现 | |---------------|----------------------------|-----------------------| | 固定窗口 | 对精度要求低的简单场景 | Redis INCR | | 滑动窗口 | 需要精度控制的中小型系统 | Redis + Lua | | 令牌桶 | 允许突发流量的大促场景 | Sentinel/Resilience4j | | 漏桶 | 需要恒定处理速率的计费系统 | Nginx限流模块 |