一、概述在分布式系统中限流是保障服务稳定性的重要手段。本文详细对比三种基于 Redis 的分布式限流方案固定窗口、滑动窗口、令牌桶帮助你在不同场景下做出合理的技术选型。二、方案一固定窗口Fixed Window2.1 原理将时间划分为固定长度的时间窗口如 1 秒每个窗口独立计数。窗口内计数器累加超过阈值则拦截。时间轴 |--- 第1秒 ---|--- 第2秒 ---|--- 第3秒 ---| ① ② ③ ④ ⑤ ⑥ ① ② ③ ① ② ③ ④ ⑤ ↓ ↓ ↓ 计数6 计数3 计数5 阈值5 阈值5 阈值5 ❌ 拦截2个 ✅ 全部放行 ✅ 全部放行2.2 Redis 实现Lua 脚本localkeyKEYS[1]locallimittonumber(ARGV[1])localttltonumber(ARGV[2])-- 原子性自增localcurrentredis.call(INCR,key)-- 首次访问设置过期时间ifcurrent1thenredis.call(EXPIRE,key,ttl)endreturncurrent2.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_SCRIPTlocal current redis.call(INCR, KEYS[1])\nif current 1 then\n redis.call(EXPIRE, KEYS[1], ARGV[2])\nend\nreturn current;publicbooleanallow(Stringkey,intlimit,intwindowSeconds){LongcountredisTemplate.execute(newDefaultRedisScript(LUA_SCRIPT,Long.class),Collections.singletonList(key),String.valueOf(limit),String.valueOf(windowSeconds));returncount!nullcountlimit;}}三、方案二滑动窗口Sliding Window3.1 原理使用 Redis 的Sorted SetZSET存储每个请求的时间戳通过移除窗口外的旧数据精确统计窗口内的请求数。时间轴 |---- 过去1秒 ----|现在 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ↓ ↓ ZSET 存储所有请求时间戳 ZREMRANGEBYSCORE 移除窗口外数据 ZCARD 统计窗口内数量3.2 Redis 实现Lua 脚本localkeyKEYS[1]localnowtonumber(ARGV[1])localwindowtonumber(ARGV[2])-- 窗口大小毫秒locallimittonumber(ARGV[3])-- 移除窗口外的旧数据redis.call(ZREMRANGEBYSCORE,key,0,now-window)-- 获取当前窗口内的请求数localcountredis.call(ZCARD,key)ifcountlimitthenreturncount-- 拦截end-- 添加当前请求使用毫秒时间戳 随机数作为 member避免重复redis.call(ZADD,key,now,now..:..math.random())-- 设置过期时间窗口 1 秒redis.call(PEXPIRE,key,window1000)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_SCRIPTlocal window tonumber(ARGV[2])\nlocal now tonumber(ARGV[1])\nlocal limit tonumber(ARGV[3])\nredis.call(ZREMRANGEBYSCORE, KEYS[1], 0, now - window)\nlocal count redis.call(ZCARD, KEYS[1])\nif count limit then return count end\nredis.call(ZADD, KEYS[1], now, now .. : .. math.random())\nredis.call(PEXPIRE, KEYS[1], window 1000)\nreturn 0;publicbooleanallow(Stringkey,intlimit,intwindowMs){longnowSystem.currentTimeMillis();LongcountredisTemplate.execute(newDefaultRedisScript(LUA_SCRIPT,Long.class),Collections.singletonList(key),String.valueOf(now),String.valueOf(windowMs),String.valueOf(limit));returncount!nullcount0;}}四、方案三令牌桶Token Bucket4.1 原理系统以固定速率向桶中放入令牌每个请求需要消耗一个令牌。桶有容量上限允许一定程度的突发流量。┌─────────────────────┐ │ 令牌桶 (容量 20) │ │ │ │ │ │ │ └──────────┬──────────┘ │ ┌──────────▼──────────┐ │ 固定速率填充 │ │ 10 令牌/秒 │ └─────────────────────┘4.2 Redis 实现Lua 脚本localkeyKEYS[1]locallimittonumber(ARGV[1])-- 桶容量localratetonumber(ARGV[2])-- 填充速率令牌/秒localnowtonumber(ARGV[3])-- 获取桶状态localstateredis.call(HMGET,key,tokens,last_time)localtokenstonumber(state[1])orlimitlocallastTimetonumber(state[2])ornow-- 计算应该补充的令牌数localdeltamath.max(0,now-lastTime)localfilledTokensmath.min(limit,tokens(delta*rate/1000))-- 判断是否有足够令牌iffilledTokens1then-- 消耗 1 个令牌localnewTokensfilledTokens-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-- 拦截end4.3 优缺点维度评价实现复杂度⭐⭐⭐ 最高需要维护桶状态性能⭐⭐ 较高HMGET HMSET 多次操作内存占用⭐⭐⭐ 低仅存两个字段流量均匀性⭐⭐⭐ 最平滑允许可控突发4.4 突发流量处理对比固定窗口 请求数 ▲ 20│ ████████ (瞬间突发被拦截) 10│ ████████ └─────────────────► 时间 令牌桶 请求数 ▲ 20│ ████████ (突发被平滑) 10│ ████████ └─────────────────► 时间4.5 适用场景场景是否适用说明秒杀/抢购✅ 推荐允许初期突发平滑后续流量消息队列消费✅ 推荐控制消费速率平滑处理第三方 API 调用✅ 推荐严格遵守对方限流规则网关流量整形⚠️ 可用功能强大但实现复杂收益不高简单防刷❌ 过度设计固定窗口足够没必要上令牌桶4.6 代码示例ComponentpublicclassTokenBucketRateLimiter{privatestaticfinalStringLUA_SCRIPTlocal limit tonumber(ARGV[1])\nlocal rate tonumber(ARGV[2])\nlocal now tonumber(ARGV[3])\nlocal state redis.call(HMGET, KEYS[1], tokens, last_time)\nlocal tokens tonumber(state[1]) or limit\nlocal lastTime tonumber(state[2]) or now\nlocal delta math.max(0, now - lastTime)\nlocal filled math.min(limit, tokens (delta * rate / 1000))\nif 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\nend\nredis.call(HMSET, KEYS[1], tokens, filled, last_time, now)\nreturn 0;publicbooleanallow(Stringkey,intcapacity,intratePerSecond){longnowSystem.currentTimeMillis();LongresultredisTemplate.execute(newDefaultRedisScript(LUA_SCRIPT,Long.class),Collections.singletonList(key),String.valueOf(capacity),String.valueOf(ratePerSecond),String.valueOf(now));returnresult!nullresult1;}}五、三种方案全景对比维度固定窗口滑动窗口令牌桶实现复杂度⭐ 低⭐⭐ 中⭐⭐⭐ 高性能 (Redis调用)1 次3 次2 次内存占用⭐⭐⭐ 低 (1个Key)⭐⭐ 中 (N个成员)⭐⭐⭐ 低 (2个字段)流量均匀性⭐⭐ 边界突发⭐⭐⭐ 最精确⭐⭐⭐ 最平滑允许突发❌ 突发即拦截❌ 突发即拦截✅ 可控突发时间精度秒级毫秒级毫秒级Key 过期处理自动过期自动过期需设置 TTL适用场景防刷、限流精确控制流量整形性能基准测试参考值方案单次请求耗时每秒处理能力固定窗口~0.5ms20000滑动窗口~1.2ms8000令牌桶~1.0ms10000六、选型决策树开始 │ ▼ 是否需要严格均匀的流量分布 │ ├── 是 ──► 是否允许突发流量 │ │ │ ├── 是 ──► 令牌桶 │ │ │ └── 否 ──► 滑动窗口 │ └── 否 ──► 是否需要毫秒级精度 │ ├── 是 ──► 滑动窗口 │ └── 否 ──► 固定窗口 ✅ 最推荐七、场景化推荐业务场景推荐方案理由API 防刷固定窗口简单、高效、够用IP 限流固定窗口最常见场景性价比最高登录暴力破解防护固定窗口3-5次/秒固定窗口足够秒杀/抢购令牌桶允许初期突发平滑后续消息队列消费令牌桶控制消费速率第三方 API 调用令牌桶遵守对方限流规则金融交易限流滑动窗口精确控制无边界问题严格 QPS 保证滑动窗口任意时刻都不超限网关通用限流固定窗口性能最优运维简单八、总结一句话选型大部分场景选固定窗口需要精确控制选滑动窗口需要流量整形选令牌桶。最终建议优先级方案说明首选固定窗口覆盖 80% 场景简单可靠按需滑动窗口对精度有严格要求时使用慎用令牌桶功能强大但实现复杂非必要不用记住过度设计是最大的敌人。先用最简单的方案解决问题等真正遇到瓶颈再升级。