常用限流算法

你好，我是阿彬。今天我们来聊一聊常用的限流算法。

在后端开发中，限流（Rate Limiting）是保护系统不被突发流量冲垮的“保险丝”。常见的限流算法可以分为两类：固定窗口类（实现简单但有波动）和 桶/令牌类（平滑流量、应对突发）。

固定窗口算法 (Fixed Window)

这是最简单的算法。将时间划分为固定的周期（如 1 分钟），并在每个周期内维护一个计数器。

• 原理： 请求到达时计数器加 1，超过阈值则拒绝；进入下个周期时计数器清零。
• 优点：实现极其简单，占用内存小。
• 缺点：临界点效应（突刺现象）。如果在窗口切换的前后瞬间各涌入大量请求，实际流量可能是限流值的两倍。

滑动窗口算法 (Sliding Window Log/Counter)

为了解决固定窗口的“突刺”问题，滑动窗口将时间细分为更小的格子。

• 原理： 窗口随时间平滑移动。每次请求到来时，统计当前时刻向前推一个完整窗口期内的总请求数。
• 优点： 解决了固定窗口的临界点问题，限流更平滑。
• 缺点：结构相对复杂，由于需要记录多个小窗口的计数，内存占用比固定窗口高。

漏桶算法 (Leaky Bucket)

漏桶算法强制要求系统以恒定的速率处理请求，就像一个底下有小孔的桶。

• 原理：无论上方注水的速度（请求流入）多快，下方的出水速度（处理请求）始终固定。如果桶满了，多余的水直接溢出（拒绝请求）。
• 优点：能够绝对平滑地限制请求流出的速率。
• 缺点：无法应对突发流量。即便系统负载很低，请求也必须按死板的速率排队，缺乏灵活性。

令牌桶算法 (Token Bucket)

这是目前互联网公司（如 Google, Amazon）最常用的算法，因为它兼顾了平滑性和灵活性。

• 原理：系统以恒定速率向桶里发放“令牌”。请求到来时必须先取走一个令牌，取不到则限流。
• 优点：允许一定程度的突发流量（只要桶里有积攒的令牌，就可以瞬间处理多个请求），同时又限制了长期的平均速率。
• 缺点：需要维护令牌发放逻辑，在高并发下对性能有微小影响（通常通过 Redis + Lua 脚本解决）。

总结

算法	平滑度	允许突发流量	实现复杂度	适用场景
固定窗口	低	否	最低	简单场景，精度要求不高
滑动窗口	中	否	中	Sentinel、Hystrix 等流控组件
漏桶算法	最高	否	中	数据库写入、强一致性流量整形
令牌桶算法	高	是	中	主流网关、API 限流首选