限流方案设计#

一句话答案#

多层限流：前端→网关（Nginx 漏桶/Gateway 令牌桶）→服务（Sentinel 滑动窗口）→DB，分布式用 Redis+Lua。

算法原理深挖#

令牌桶 vs 漏桶（最高频）： 两者形状像，机制相反。

• 令牌桶为何容突发： 桶容量 = 攒令牌上限。系统空闲一段时间后桶里攒满令牌，此时突然来一批请求，能一次性把存量令牌取光，瞬时放行量 = 桶容量，超过平均速率——这正是”容忍突发”的本质。
• 漏桶为何整流： 不管进水多猛，出水阀门恒速。突发流量只会让桶内排队变长（满了就丢），下游永远收到平滑的恒定速率。代价是即使下游有余力也不会加速，牺牲了突发吞吐换稳定。
• 惰性补令牌（lazy refill）： 工程实现不开后台线程定时加令牌，而是每次请求来时按 (now - lastTime) × rate 一次性补算应新增的令牌数，再判断够不够扣。省线程、零误差。

滑动窗口消除临界突刺： 固定窗口的致命缺陷——窗口边界。设限 100次/分，若在 0:59 涌入 100 次、1:01 再涌入 100 次，跨越两个窗口但实际 2 秒内放行了 200 次，瞬时翻倍击穿。

• 解法：把 1 分钟切成 N 个小格（如 6 格、每格 10 秒），窗口随时间向前滑动，统计「当前时刻往前推 1 分钟」覆盖到的所有格子计数之和。旧格子滑出窗口即不再计入，临界点不再有翻倍空档。格子越细，精度越高、内存开销越大。

Guava RateLimiter 预热（warmup）： 令牌桶的变体 SmoothWarmingUp。系统冷启动时（缓存空、连接池未建立）直接打满速率会击垮下游，所以预热期内令牌发放速率从慢逐渐加速到稳态，给下游一个爬坡缓冲。底层用一个”梯形面积”模型计算冷启动期每个令牌的等待时间，平滑过渡，避免冷系统被瞬时打满。

Redis + Lua 滑动窗口（ZSET 实现）： 分布式滑动窗口的标准答案。

• 用一个 ZSET 存请求记录：member = 请求唯一 ID，score = 请求时间戳（毫秒）。
• Lua 脚本里原子完成四步：① ZREMRANGEBYSCORE key 0 (now - window) 滑掉窗口外的过期记录；② ZCARD key 统计窗口内当前请求数；③ 若未超阈值则 ZADD key now reqId 记入本次；④ EXPIRE key 兜底防泄漏。
• 为何要 Lua：判断 + 写入若分两条命令，并发下会有竞态；Lua 在 Redis 单线程里串行执行不被打断，保证「读计数-判断-写入」原子。