限流算法中的令牌桶和漏桶哪个更适合业务场景
摘要：# 限流算法选哪个？聊聊令牌桶和漏桶的实战“手感” 搞过网站防护或者系统架构的朋友，对“限流”这个词肯定不陌生。服务器扛不住了、带宽快炸了，第一反应就是“得限个流”。但真到选方案的时候，面对“令牌桶”和“漏桶”这两位老将，很多人就懵了——**这俩听起来都…
限流算法选哪个？聊聊令牌桶和漏桶的实战“手感”
搞过网站防护或者系统架构的朋友，对“限流”这个词肯定不陌生。服务器扛不住了、带宽快炸了，第一反应就是“得限个流”。但真到选方案的时候，面对“令牌桶”和“漏桶”这两位老将，很多人就懵了——这俩听起来都挺有道理，到底该用哪个？
别急着翻教科书，咱们今天不聊那些复杂的数学公式，就说说我这些年调参、踩坑下来的真实感受。说白了，这俩算法的区别，有点像“弹性水龙头”和“固定漏斗”的区别。选哪个，真得看你业务是什么“脾气”。
先来个“人话版”解释：它俩到底在干啥？
我知道很多技术文章一上来就画图、列公式，看着就头疼。咱们换个方式。
想象一个网红奶茶店。
-
漏桶算法：就像店里有个固定大小的漏斗（漏桶）。不管外面顾客（请求）多疯狂、多挤，点单员（系统）都必须把订单（请求处理）一杯一杯、匀速地通过漏斗漏下去给后厨。漏斗的出口速度是恒定的。哪怕一瞬间涌进来100个订单，后厨也只能按部就班地，比如每分钟处理10杯。超出的订单？要么在漏斗里排队（如果桶没满），要么就直接被拒绝（桶满了）。它的核心是：绝对均匀的输出，保护后厨（下游系统）不被冲垮。
-
令牌桶算法：则像是一种“取号机”。后厨（系统）会以一个固定的速率生产“取餐牌”（令牌），放进一个桶里。顾客（请求）来了，必须先拿到一个“牌”，才能点单并被处理。如果一瞬间来了100个顾客，而桶里恰好攒了30个牌，那么前30个顾客能立刻拿到牌开始点单，后面的70个就得等新的牌生产出来。它的核心是：允许一定程度的突发流量，只要桶里有“存货”。
看出区别了吗？漏桶关心的是“出水的速度绝对平稳”，而令牌桶关心的是“进来的流量在总量上别太离谱，但偶尔爆一下可以接受”。
实战掰头：什么时候该选谁？
好了，理论太枯燥，咱们直接上场景。这也是我经常跟团队“吵架”（友好讨论）的地方。
场景一：保护“脆弱”的下游服务——请用漏桶
如果你的系统前面是个“暴脾气”的用户入口，后面连着一个“老心脏”的数据库或者某个第三方支付接口，漏桶是你的好朋友。
我经历过一个坑：一个促销活动页，调用一个老旧的核心查询接口。一开始用了令牌桶，想着能应对开抢时的突发。结果呢？突发请求是过去了，那个老接口在并发稍微一高的时候，响应时间就会指数级增长，最后直接拖死。令牌桶放了“一群人”进去，反而成了压死骆驼的最后一根稻草。
后来换成漏桶，把流出速率严格限制在老旧接口能承受的并发以下。虽然前端排队时间变长了，用户得等，但系统整体再也没挂过。 这就是漏桶的价值：它用绝对的、平滑的输出，给你的核心脆弱系统穿上了防弹衣。 用户可能会抱怨“慢”，但绝不会看到“服务器错误500”。
说白了：当你需要的是一个“整流器”，把一切不规则的流量都熨烫平整时，选漏桶。 比如消息队列的消费者、写入数据库的速率控制。
场景二：兼顾体验与系统安全——请用令牌桶
现在大部分Web API、微服务网关，其实更常用令牌桶。为什么？因为业务需要“弹性”。
想象一个API接口，平时每秒就几十个请求。突然有个大客户导数据，或者一个正常的运营活动开始，可能瞬间需要几百个请求。如果用漏桶，这些请求会被强行拉平成一条直线，体验极差。
但用令牌桶呢？只要你的“令牌桶”平时有积累（比如桶大小设置得合理），这波突发请求就能立刻消耗掉库存的令牌，快速得到响应。等桶里的令牌用完了，后续请求才会被平滑限制。这对用户来说，感觉就是“开始很快，后来稍微慢点”，体验上友好得多。
我自己在配高防IP或WAF的CC防护规则时，如果业务是面向真实用户的Web服务，首选也是基于令牌桶思想的策略。 因为它更符合人类访问的“波峰波谷”特性，不会因为一个正常的、短暂的访问高峰就把所有用户一棍子打死。
说白了：当你的业务允许、甚至需要短时间内“猛冲一下”，但又不想被持续攻击搞垮时，选令牌桶。 比如对外提供的API服务、网站的动态页面。
一些“踩坑”得来的私货心得
-
别神话算法，参数才是灵魂。 你给漏桶一个每秒10万流的出口速率，它也能“突发”。令牌桶的桶大小设为1，它也比漏桶还严格。选型只是第一步，真正的功夫在根据业务压测数据调整参数。 我见过太多人套了个默认参数就上生产，然后抱怨算法不好用。
-
组合拳往往更香。 在真实的大型系统里，尤其是金融、支付场景，经常是多层限流。比如：
- 网关层用令牌桶，允许应用级别的突发，防止误伤正常用户。
- 到了核心交易服务前，再用漏桶，确保每秒写入数据库的交易笔数绝对可控。
- （这个组合很经典，能帮你挡掉大部分麻烦）
-
“适合业务”比“算法先进”重要一万倍。 有些团队为了追求“技术范儿”，非要给一个内部后台管理系统上复杂的动态令牌桶。其实，一个简单的、固定速率的漏桶可能更稳定，运维成本也更低。技术是为人服务的，别搞反了。
-
没有“银弹”，监控和动态调整是关键。 上了限流不是就高枕无忧了。必须配好监控大盘，看限流触发的情况、排队队列的长度。业务量增长了，促销周期来了，参数该调就得调。限流策略应该是活的，不是配置完就扔那的石头。
所以，回到开头的问题
令牌桶和漏桶哪个更适合你的业务场景？
我的答案是：去看看你的业务流量曲线，去问问你的下游系统最怕什么。
- 如果你的业务像平稳的溪流，偶尔有小浪花，下游又比较健壮——优先考虑令牌桶，让用户体验更好。
- 如果你的业务像喜怒无常的山洪，而下游是座必须保护的老桥——果断用漏桶，把一切风险熨平。
- 如果都很重要？那就别纠结，分层设计，混合使用。
技术方案没有绝对的好坏，只有合不合适的场景。别听那些PPT里吹得天花乱坠的方案，真到了线上，能稳稳扛住流量、不误杀正常用户、还能让你晚上睡个安稳觉的，就是最适合你的好方案。
行了，关于限流，今天就聊这么多。参数怎么调？那又是另一个充满“惊喜”的故事了。