摘要：# 令牌桶和漏桶，CDN限速的“油门”和“刹车”到底怎么选？ 前两天跟一个做电商的朋友聊天，他愁眉苦脸地说：“促销那会儿，CDN流量费用直接爆了，后台一看，全是爬虫在那儿疯狂薅商品详情页，跟不要钱似的。” 我问他：“你没做限速吗？” 他一脸无奈：“做…

令牌桶和漏桶，CDN限速的“油门”和“刹车”到底怎么选？

前两天跟一个做电商的朋友聊天，他愁眉苦脸地说：“促销那会儿，CDN流量费用直接爆了，后台一看，全是爬虫在那儿疯狂薅商品详情页，跟不要钱似的。”

我问他：“你没做限速吗？”

他一脸无奈：“做了啊！用的那个什么……漏桶算法。可感觉没啥用，该爆还是爆。”

我笑了：“老哥，你这属于油门当刹车用了。漏桶是稳，但对付这种突发流氓流量，你得用令牌桶——该狠的时候就得掐住脖子，该松的时候也得让人喘口气。”

今天咱们就掰开揉碎了聊聊，CDN边缘节点上这两个经典的限速算法——令牌桶和漏桶。别被那些教科书式的定义吓到，说白了，它俩就是控制流量洪水的两种不同“阀门”。选对了，成本降下来，体验提上去；选错了，就是白花钱还受罪。

漏桶算法：一个“强迫症”的出水口

想象一下一个老式的水桶，底下有个固定大小的洞。水（请求）从上面哗啦啦往里倒，但不管倒得多猛、多急，水桶都只按照那个洞的尺寸，匀速、一丝不苟地往外滴水。

这就是漏桶的核心逻辑：强行平整化。

• 优点是什么？ 稳，非常稳。它给下游（你的源站）的输出流量是绝对恒定、可预测的。比如你设置每秒漏出100个请求，那就算天塌下来，到源站那边也就是每秒100个，绝不会多。这对保护后端脆弱的数据库、防止雪崩简直是一道“铁闸”。
• 缺点呢？ 也因为它太“强迫症”了。突发流量来了，桶满了，多余的请求直接就被丢弃（或者排队等到天荒地老）。用户感觉就是：页面突然卡死，刷新也没用。它不区分“好用户”的突发（比如秒杀开始那一刻）和“坏流量”的冲击（比如CC攻击），一律按死。

所以，漏桶适合什么场景？当你后端资源是绝对的瓶颈，且一点波动都不能有的时候。 比如，你的源站服务器处理能力就那么多，多一个请求都可能崩。这时候，漏桶就是那个冷酷无情的守门员。

但说实话，现在纯用漏桶的CDN配置不多了。太死板，用户体验容易“误伤”。

令牌桶算法：一个“会攒钱”的智能闸门

令牌桶就灵活多了。它也有个桶，但这个桶里装的不是请求，是“令牌”。系统会以固定的速率（比如每秒100个）往桶里扔令牌。桶有最大容量。

当一个请求过来时，它需要从桶里拿走一个令牌，才能被放行。如果桶里有令牌，立刻拿走，请求快速通过；如果桶里没令牌了，请求就得等待，或者被拒绝。

关键来了：如果一段时间没流量，令牌会在桶里累积起来，最多攒满一桶。

这个“攒”的机制，就是令牌桶的精髓。

• 优点是什么？ 允许突发，且可控。 比如你设置平均速率100/秒，桶容量是200。在风平浪静时，桶里攒了200个令牌。这时突然来了一个秒杀活动，前200个请求可以瞬间被处理（消耗掉攒的令牌），之后才平滑降到100/秒的速率。用户感觉就是：开头抢得飞快，后面稍微排队。这比漏桶那种一开始就让人排队体验好太多了。
• 它更智能： 可以更好地应对正常的、突发性的业务流量，而不是一棍子打死。

当然，缺点也是这个“突发”。如果配置不当（比如桶太大），攻击者可能利用这个“攒”出来的容量，发起一波短时高强度的攻击，消耗完令牌后虽然会被限速，但第一波可能已经造成影响。

实战场景：CDN边缘怎么用？

在CDN的边缘节点，限速可不是随便选一个就完事的。这得看你要防的是谁，保的是谁。

场景一：防爬虫、防CC攻击 这是最常见的需求。我的建议是：主用令牌桶，但配合智能策略。

• 对单一IP的请求速率，用令牌桶限制。允许它偶尔快几下（比如正常用户快速点击刷新），但长期来看，平均速率被严格控制。
• 桶容量别设太大，防止攻击者“偷”到突发额度。
• 关键一步： 结合IP信誉库、行为分析（比如请求是否带合法Cookie、User-Agent是否像人）。对于明确是恶意的IP，直接切换到更严格的漏桶模式，甚至直接封禁，不给任何突发机会。这就叫“看人下菜碟”。

场景二：保护源站，防雪崩 如果你的源站是朵“娇花”，经不起任何风吹草动。那么可以在CDN回源的那一层，使用漏桶算法。 确保回源的请求像涓涓细流，绝对平稳。这样，无论前端边缘节点因为促销涌来多大流量，到源站这里都被熨平了。代价是，可能会增加一些在CDN层的排队延迟。

场景三：API接口分级限速 比如你的CDN上挂着一个对外API。免费用户、VIP用户、SVIP用户速率肯定不一样。这时候，多级令牌桶就很好用。 给每个用户级别分配不同的令牌生成速率和桶容量。SVIP桶又大、令牌来得又快，体验自然流畅；免费用户桶小速率慢，但偶尔也能“攒”一次快速请求。这比一刀切的漏桶公平，也更有商业想象力。

几个容易踩的坑（大实话时间）

1. 别迷信默认配置：很多CDN服务商提供的默认限速规则，为了兼容性，往往比较宽松。你真要防攻击，得自己调。把平均速率（令牌生成速率）设得比你认为的正常值再低一点。
2. “突发容量”是把双刃剑：令牌桶的桶容量（Burst Size）设置是关键。设小了，正常用户体验差；设大了，就是给攻击者送弹药。没有标准答案，得看你业务的实际流量曲线来反复调。 我一般建议先设小，观察后再慢慢放大。
3. 别忘了监控和动态调整：限速规则不是设完就一劳永逸的。你得盯着监控，看限速触发了多少次，触发的是哪些IP、哪些URL。很可能你会发现，被你限速的某个IP段，其实是某个偏远地区的正常用户群体。这时候就需要动态调整策略，或者加入白名单。
4. 组合拳才是王道：单靠任何一种算法，都不能解决所有问题。令牌桶/漏桶 + IP黑白名单 + 人机验证（Challenge） + 业务逻辑风控（比如验证登录态），这套组合拳打出来，防护效果才扎实。

结尾：怎么选？看你的“心病”在哪

最后，说点直接的：

• 如果你的心病是怕源站挂，一点波动都受不了，那就选漏桶。它是个无情的稳定器。
• 如果你的心病是用户体验差，怕误伤正常用户，同时要应对各种突发和攻击，那就选令牌桶。它是个更聪明、更有弹性的流量管家。

但更现实的是，在今天的CDN和云WAF产品里，你看到的早已不是单纯的“令牌桶”或“漏桶”，而是它们的魔改混合体。比如“支持突发但突发量有硬顶”、“前N个请求快速通过后进入严格限速”……这些本质上都是在取两家之长。

所以，作为使用者，别纠结于纯理论概念。直接看你的CDN控制台，那个限速配置项里，它允不允许你设置“突发量”（Burst）？ 允许，那它就是偏令牌桶思想的；不允许，只让你设一个固定速率，那它就是偏漏桶的。

然后，根据你的业务，去调那几个参数：速率、突发量、惩罚动作（是排队还是直接拒绝）。多试几次，观察数据，效果好坏，你的监控图表会给你最真实的答案。

毕竟，算法是死的，业务是活的。合适与否，用了才知道。