Nginx 为什么用漏桶，而 Guava 用令牌桶？一文看懂限流算法的底层逻辑

在双十一大促、明星热搜或者遭受到恶意攻击时，系统的流量会瞬间飙升。
如果把服务器比作一家餐厅，平时每分钟进 10 个客人，系统运行良好。
突然来了 1000 个客人，如果全放进来，厨房（CPU/数据库）立刻就会炸锅，餐厅直接倒闭（宕机）。

为了防止这种情况，我们需要一个无情的**“守门员”，把超过处理能力的请求挡在门外。这就是限流 (Rate Limiting)**。

在微服务网关（如 Sentinel, Hystrix, Nginx）中，最经典的两位守门员就是：漏桶算法和令牌桶算法。

💻 一、技术分析：流速的控制艺术

1. 漏桶算法 (Leaky Bucket) —— “强行削峰”

• 原理: 想象一个底部有个小孔的桶。

• 入水: 请求像水一样，以任意速度灌进桶里。

• 出水: 桶底的水滴，永远以固定的速率流出（比如每秒 10 滴）。

• 溢出: 如果桶满了（缓存队列满了），新进来的水直接溢出（拒绝请求）。

• 核心特征:强行平滑流量。不管外面的请求波动多大，发给后端的请求永远是匀速的。

• 缺点:无法应对突发流量。哪怕现在桶是空的，请求也只能一滴一滴地流，处理效率有时会显得太死板。

2. 令牌桶算法 (Token Bucket) —— “支持突发”

• 原理: 想象一个专门放令牌的盒子。

• 生产令牌: 系统以固定速率往盒子里扔令牌（比如每秒扔 10 个）。

• 容量限制: 盒子有最大容量（比如 100 个），满了就不扔了。

• 消费令牌: 请求来了，必须从盒子里拿走一个令牌才能进。如果盒子里没令牌，就拒绝。

• 核心特征:允许突发。如果平时没人来，盒子里攒满了 100 个令牌。突然来了 50 个请求，它们可以瞬间拿走 50 个令牌同时处理，不需要排队。

• 优点: 既限制了平均速度，又兼顾了突发的洪峰。

🎡 二、故事场景：医院与游乐场

为了彻底搞懂它们的区别，我们看看日常生活中的两个经典场景。

1. 漏桶算法 —— “医院打吊瓶”

• 场景: 你生病了，护士给你挂点滴。
• 入水: 护士拿来一整袋药水（大量的突发请求），一下子挂在架子上。
• 出水: 无论袋子里剩多少药，滴管（漏桶出口）永远是“滴答、滴答”匀速滴下来的。
• 为什么: 因为病人的血液（后端服务器）承受能力有限，如果一大袋药水瞬间灌进去，人就没了。
• 结论:漏桶是为了保护脆弱的下游系统，不让它被冲垮。

2. 令牌桶算法 —— “游乐场检票口”

• 场景: 迪士尼乐园的快速通道。

• 生产令牌: 工作人员（系统）每秒钟往检票箱里放 10 张票。

• 存票: 如果这一分钟没人来，箱子里就积攒了 100 张票（达到上限）。

• 突发情况:

• 突然来了一个 50 人的旅行团（突发流量）。

• 因为箱子里有 100 张票，这 50 个人每人拿一张，瞬间全部通过，不需要像打吊瓶那样排队。

• 紧接着又来了 80 人。前 50 人拿走了剩下的 50 张票，后 30 人没票了，只能乖乖等工作人员发新票。

• 结论:令牌桶是为了在限制平均流量的同时，允许用户“爽一把”（处理突发请求）。

🥊 三、总结：Nginx 与 Guava 的选择

一句话总结：

• 如果你希望请求走得**“稳”**，选漏桶。
• 如果你希望请求走得**“快”**，选令牌桶。