一、概述
在分布式系统中,限流是保障服务稳定性的重要手段。本文详细对比三种基于 Redis 的分布式限流方案:固定窗口、滑动窗口、令牌桶,帮助你在不同场景下做出合理的技术选型。
二、方案一:固定窗口(Fixed Window)
2.1 原理
将时间划分为固定长度的时间窗口(如 1 秒),每个窗口独立计数。窗口内计数器累加,超过阈值则拦截。
时间轴: |--- 第1秒 ---|--- 第2秒 ---|--- 第3秒 ---| ① ② ③ ④ ⑤ ⑥ ① ② ③ ① ② ③ ④ ⑤ ↓ ↓ ↓ 计数=6 计数=3 计数=5 阈值=5 阈值=5 阈值=5 ❌ 拦截2个 ✅ 全部放行 ✅ 全部放行
2.2 Redis 实现(Lua 脚本)
localkey=KEYS[1]locallimit=tonumber(ARGV[1])localttl=tonumber(ARGV[2])-- 原子性自增localcurrent=redis.call('INCR',key)-- 首次访问设置过期时间ifcurrent==1thenredis.call('EXPIRE',key,ttl)endreturncurrent
2.3 优缺点
| 维度 | 评价 |
|---|
| 实现复杂度 | ⭐ 极低,代码简洁 |
| 性能 | ⭐⭐⭐ 最高,单次 Redis 调用 |
| 内存占用 | ⭐⭐⭐ 最低,每个窗口只存一个计数器 |
| 流量均匀性 | ⭐⭐ 存在边界突发问题 |
2.4 边界突发问题
时间线: |---- 第1秒 (阈值10) ----|---- 第2秒 (阈值10) ----| 请求: 第9、10个在 999ms 到达 第1、2个在 1001ms 到达 结果:在 2ms 内通过了 12 个请求(超了 10 的限制)
2.5 适用场景
| 场景 | 是否适用 | 说明 |
|---|
| API 防刷 | ✅ 推荐 | 正常用户不会卡时间边界,边界问题可接受 |
| 登录限流 | ✅ 推荐 | 防暴力破解,简单高效 |
| IP 限流 | ✅ 推荐 | 最常见的防刷场景 |
| 严格流量整形 | ❌ 不推荐 | 边界突发不符合要求 |
| 秒杀/抢购 | ⚠️ 慎用 | 边界突发可能导致不公平 |
2.6 代码示例
@ComponentpublicclassFixedWindowRateLimiter{privatestaticfinalStringLUA_SCRIPT="local current = redis.call('INCR', KEYS[1])\n"+"if current == 1 then\n"+" redis.call('EXPIRE', KEYS[1], ARGV[2])\n"+"end\n"+"return current";publicbooleanallow(Stringkey,intlimit,intwindowSeconds){Longcount=redisTemplate.execute(newDefaultRedisScript<>(LUA_SCRIPT,Long.class),Collections.singletonList(key),String.valueOf(limit),String.valueOf(windowSeconds));returncount!=null&&count<=limit;}}
三、方案二:滑动窗口(Sliding Window)
3.1 原理
使用 Redis 的Sorted Set(ZSET)存储每个请求的时间戳,通过移除窗口外的旧数据,精确统计窗口内的请求数。
时间轴: |---- 过去1秒 ----|现在 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ↓ ↓ ZSET 存储所有请求时间戳 ZREMRANGEBYSCORE 移除窗口外数据 ZCARD 统计窗口内数量
3.2 Redis 实现(Lua 脚本)
localkey=KEYS[1]localnow=tonumber(ARGV[1])localwindow=tonumber(ARGV[2])-- 窗口大小(毫秒)locallimit=tonumber(ARGV[3])-- 移除窗口外的旧数据redis.call('ZREMRANGEBYSCORE',key,0,now-window)-- 获取当前窗口内的请求数localcount=redis.call('ZCARD',key)ifcount>=limitthenreturncount-- 拦截end-- 添加当前请求(使用毫秒时间戳 + 随机数作为 member,避免重复)redis.call('ZADD',key,now,now..':'..math.random())-- 设置过期时间(窗口 + 1 秒)redis.call('PEXPIRE',key,window+1000)return0-- 放行
3.3 优缺点
| 维度 | 评价 |
|---|
| 实现复杂度 | ⭐⭐ 中等,需要理解 ZSET 操作 |
| 性能 | ⭐⭐ 较高,ZREMRANGEBYSCORE + ZCARD + ZADD |
| 内存占用 | ⭐⭐ 较高,每个请求存一条记录 |
| 流量均匀性 | ⭐⭐⭐ 最精确,无边界问题 |
3.4 滑动窗口精度示意
固定窗口(边界突发): 第1秒 第2秒 |██████████| |██████████| 9 10 1 2 ← 2ms 内通过 12 个 滑动窗口(精确控制): |◄─── 1秒 ───►|◄─── 1秒 ───►| 请求均匀分布,任意 1 秒窗口内 ≤ 阈值
3.5 适用场景
| 场景 | 是否适用 | 说明 |
|---|
| 严格 QPS 控制 | ✅ 推荐 | 需要精确控制每秒请求数 |
| 金融交易限流 | ✅ 推荐 | 对流量均匀性要求高 |
| API 网关精确限流 | ✅ 推荐 | 用户感知要求高 |
| 防刷场景 | ⚠️ 可用 | 但固定窗口更简单,性价比更高 |
| 高并发场景 | ⚠️ 慎用 | 内存占用随请求量线性增长 |
3.6 代码示例
@ComponentpublicclassSlidingWindowRateLimiter{privatestaticfinalStringLUA_SCRIPT="local window = tonumber(ARGV[2])\n"+"local now = tonumber(ARGV[1])\n"+"local limit = tonumber(ARGV[3])\n"+"redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, now - window)\n"+"local count = redis.call('ZCARD', KEYS[1])\n"+"if count >= limit then return count end\n"+"redis.call('ZADD', KEYS[1], now, now .. ':' .. math.random())\n"+"redis.call('PEXPIRE', KEYS[1], window + 1000)\n"+"return 0";publicbooleanallow(Stringkey,intlimit,intwindowMs){longnow=System.currentTimeMillis();Longcount=redisTemplate.execute(newDefaultRedisScript<>(LUA_SCRIPT,Long.class),Collections.singletonList(key),String.valueOf(now),String.valueOf(windowMs),String.valueOf(limit));returncount!=null&&count==0;}}
四、方案三:令牌桶(Token Bucket)
4.1 原理
系统以固定速率向桶中放入令牌,每个请求需要消耗一个令牌。桶有容量上限,允许一定程度的突发流量。
┌─────────────────────┐ │ 令牌桶 (容量 20) │ │ 🪙🪙🪙🪙🪙🪙🪙🪙 │ │ 🪙🪙🪙🪙🪙🪙🪙🪙 │ │ 🪙🪙🪙🪙 │ └──────────┬──────────┘ │ ┌──────────▼──────────┐ │ 固定速率填充 │ │ 10 令牌/秒 │ └─────────────────────┘
4.2 Redis 实现(Lua 脚本)
localkey=KEYS[1]locallimit=tonumber(ARGV[1])-- 桶容量localrate=tonumber(ARGV[2])-- 填充速率(令牌/秒)localnow=tonumber(ARGV[3])-- 获取桶状态localstate=redis.call('HMGET',key,'tokens','last_time')localtokens=tonumber(state[1])orlimitlocallastTime=tonumber(state[2])ornow-- 计算应该补充的令牌数localdelta=math.max(0,now-lastTime)localfilledTokens=math.min(limit,tokens+(delta*rate/1000))-- 判断是否有足够令牌iffilledTokens>=1then-- 消耗 1 个令牌localnewTokens=filledTokens-1redis.call('HMSET',key,'tokens',newTokens,'last_time',now)redis.call('EXPIRE',key,10)return1-- 放行else-- 更新状态(不消耗)redis.call('HMSET',key,'tokens',filledTokens,'last_time',now)redis.call('EXPIRE',key,10)return0-- 拦截end
4.3 优缺点
| 维度 | 评价 |
|---|
| 实现复杂度 | ⭐⭐⭐ 最高,需要维护桶状态 |
| 性能 | ⭐⭐ 较高,HMGET + HMSET 多次操作 |
| 内存占用 | ⭐⭐⭐ 低,仅存两个字段 |
| 流量均匀性 | ⭐⭐⭐ 最平滑,允许可控突发 |
4.4 突发流量处理对比
固定窗口: 请求数 ▲ 20│ ████████ (瞬间突发被拦截) 10│ ████████ └─────────────────► 时间 令牌桶: 请求数 ▲ 20│ ████████ (突发被平滑) 10│ ████████ └─────────────────► 时间
4.5 适用场景
| 场景 | 是否适用 | 说明 |
|---|
| 秒杀/抢购 | ✅ 推荐 | 允许初期突发,平滑后续流量 |
| 消息队列消费 | ✅ 推荐 | 控制消费速率,平滑处理 |
| 第三方 API 调用 | ✅ 推荐 | 严格遵守对方限流规则 |
| 网关流量整形 | ⚠️ 可用 | 功能强大但实现复杂,收益不高 |
| 简单防刷 | ❌ 过度设计 | 固定窗口足够,没必要上令牌桶 |
4.6 代码示例
@ComponentpublicclassTokenBucketRateLimiter{privatestaticfinalStringLUA_SCRIPT="local limit = tonumber(ARGV[1])\n"+"local rate = tonumber(ARGV[2])\n"+"local now = tonumber(ARGV[3])\n"+"local state = redis.call('HMGET', KEYS[1], 'tokens', 'last_time')\n"+"local tokens = tonumber(state[1]) or limit\n"+"local lastTime = tonumber(state[2]) or now\n"+"local delta = math.max(0, now - lastTime)\n"+"local filled = math.min(limit, tokens + (delta * rate / 1000))\n"+"if filled >= 1 then\n"+" redis.call('HMSET', KEYS[1], 'tokens', filled - 1, 'last_time', now)\n"+" redis.call('EXPIRE', KEYS[1], 10)\n"+" return 1\n"+"end\n"+"redis.call('HMSET', KEYS[1], 'tokens', filled, 'last_time', now)\n"+"return 0";publicbooleanallow(Stringkey,intcapacity,intratePerSecond){longnow=System.currentTimeMillis();Longresult=redisTemplate.execute(newDefaultRedisScript<>(LUA_SCRIPT,Long.class),Collections.singletonList(key),String.valueOf(capacity),String.valueOf(ratePerSecond),String.valueOf(now));returnresult!=null&&result==1;}}
五、三种方案全景对比
| 维度 | 固定窗口 | 滑动窗口 | 令牌桶 |
|---|
| 实现复杂度 | ⭐ 低 | ⭐⭐ 中 | ⭐⭐⭐ 高 |
| 性能 (Redis调用) | 1 次 | 3 次 | 2 次 |
| 内存占用 | ⭐⭐⭐ 低 (1个Key) | ⭐⭐ 中 (N个成员) | ⭐⭐⭐ 低 (2个字段) |
| 流量均匀性 | ⭐⭐ 边界突发 | ⭐⭐⭐ 最精确 | ⭐⭐⭐ 最平滑 |
| 允许突发 | ❌ 突发即拦截 | ❌ 突发即拦截 | ✅ 可控突发 |
| 时间精度 | 秒级 | 毫秒级 | 毫秒级 |
| Key 过期处理 | 自动过期 | 自动过期 | 需设置 TTL |
| 适用场景 | 防刷、限流 | 精确控制 | 流量整形 |
性能基准测试(参考值)
| 方案 | 单次请求耗时 | 每秒处理能力 |
|---|
| 固定窗口 | ~0.5ms | 20000+ |
| 滑动窗口 | ~1.2ms | 8000+ |
| 令牌桶 | ~1.0ms | 10000+ |
六、选型决策树
开始 │ ▼ 是否需要严格均匀的流量分布? │ ├── 是 ──► 是否允许突发流量? │ │ │ ├── 是 ──► 令牌桶 │ │ │ └── 否 ──► 滑动窗口 │ └── 否 ──► 是否需要毫秒级精度? │ ├── 是 ──► 滑动窗口 │ └── 否 ──► 固定窗口 ✅ 最推荐
七、场景化推荐
| 业务场景 | 推荐方案 | 理由 |
|---|
| API 防刷 | 固定窗口 | 简单、高效、够用 |
| IP 限流 | 固定窗口 | 最常见场景,性价比最高 |
| 登录暴力破解防护 | 固定窗口 | 3-5次/秒,固定窗口足够 |
| 秒杀/抢购 | 令牌桶 | 允许初期突发,平滑后续 |
| 消息队列消费 | 令牌桶 | 控制消费速率 |
| 第三方 API 调用 | 令牌桶 | 遵守对方限流规则 |
| 金融交易限流 | 滑动窗口 | 精确控制,无边界问题 |
| 严格 QPS 保证 | 滑动窗口 | 任意时刻都不超限 |
| 网关通用限流 | 固定窗口 | 性能最优,运维简单 |
八、总结
一句话选型
大部分场景选固定窗口,需要精确控制选滑动窗口,需要流量整形选令牌桶。
最终建议
| 优先级 | 方案 | 说明 |
|---|
| 首选 | 固定窗口 | 覆盖 80% 场景,简单可靠 |
| 按需 | 滑动窗口 | 对精度有严格要求时使用 |
| 慎用 | 令牌桶 | 功能强大但实现复杂,非必要不用 |
记住:过度设计是最大的敌人。先用最简单的方案解决问题,等真正遇到瓶颈再升级。