在双十一大促、明星热搜或者遭受到恶意攻击时，系统的流量会瞬间飙升。
如果把服务器比作一家餐厅，平时每分钟进 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 的选择
| 维度 | 漏桶 (Leaky Bucket) | 令牌桶 (Token Bucket) |
|---|---|---|
| 流出速率 | 恒定(平滑) | 可变(允许瞬间飙升) |
| 突发流量 | 不支持 | 支持 |
| 核心作用 | 削峰填谷，保护下游 | 限制平均速率，兼顾体验 |
| 典型代表 | Nginx(limit_req模块) | Guava(RateLimiter类) |
| 适用场景 | 流量整形，防止数据库被打挂 | 网关限流，API 调用配额 |
一句话总结：
- 如果你希望请求走得**“稳”**，选漏桶。
- 如果你希望请求走得**“快”**，选令牌桶。
