Leaky Bucket漏桶算法对比：两种限流方式适用场景分析-编程实验室

Leaky Bucket漏桶算法对比：两种限流方式适用场景分析

在大模型服务日益普及的今天，一个看似简单的推理请求背后，可能正牵动着整张GPU集群的资源调度神经。你有没有遇到过这样的情况：多个用户同时发起文本生成任务，系统突然卡顿甚至崩溃？或者某些请求长时间排队，响应延迟飙升到无法接受的程度？

这些问题往往不是因为模型不够强，而是流量控制没做好——特别是当高频并发请求涌向昂贵且脆弱的GPU资源时，缺乏有效的限流机制，再强大的推理引擎也扛不住。

这时候，漏桶算法就登场了。它不像令牌桶那样允许“短时爆发”，而是像一根稳扎稳打的水管，以恒定速度向外排水，哪怕上游洪水滔天，下游也能保持节奏不乱。这种“平滑输出”的特性，让它成为保护后端计算资源的理想选择。

但问题来了：同样是漏桶，为什么有的系统用起来延迟低、吞吐高，而有的却卡在队列里动弹不得？关键就在于实现方式的不同。我们常见的“经典漏桶”和近年来在云原生架构中兴起的“动态漏桶”，虽然名字一样，设计理念却大相径庭。

从一个真实场景说起

设想你在运营一个基于ms-swift的大模型服务平台，支持团队A和B共享一套vLLM推理集群。某天，团队A突然上线了一个营销活动，QPS瞬间从5飙到30，而单张A100卡最多只能稳定处理20个请求/秒。结果显而易见：显存溢出、OOM Killer启动、所有请求集体失败。

如果此时有一个限流层，会怎样？

请求进来先过一道关卡；
超出处理能力的部分被暂时“装进桶里”排队；
系统按固定速率一个个拉出来处理；
整体负载被压平，服务依然可用。

这就是漏桶的核心价值：用可控的延迟换取系统的稳定性。

它的基本逻辑非常直观——把请求看作水滴，流入一个容量固定的桶。桶底有个小孔，以恒定速率漏水（即处理请求）。如果来水太快，桶满了，多余的水就会溢出（请求被拒绝）。无论输入多么剧烈波动，输出始终平稳如一。

这个模型听起来简单，但在工程落地时却有两条截然不同的路径：

经典漏桶：每次请求到达时检查是否该“漏水”了，然后决定是否接纳新请求。这是一种同步、阻塞式的判断逻辑，适合轻量级或本地部署场景。
动态漏桶：不再由请求触发检查，而是让后台独立线程或协程定时“主动漏水”。前端只负责入队，后端异步消费。这种方式解耦了接收与处理，更适合高并发、分布式环境。

两者都叫“漏桶”，也都遵循相同的数学模型，但适用场景完全不同。

经典漏桶：稳定可靠，胜在简洁

我们先来看一段典型的Python实现：

import time from collections import deque class LeakyBucket: def __init__(self, capacity: int, leak_rate: float): self.capacity = capacity self.leak_rate = leak_rate self.queue = deque() self.last_leak_time = time.time() def _leak(self): now = time.time() elapsed = now - self.last_leak_time num_to_leak = int(elapsed * self.leak_rate) for _ in range(num_to_leak): if self.queue: self.queue.popleft() self.last_leak_time = now def allow_request(self) -> bool: self._leak() if len(self.queue) < self.capacity: self.queue.append(True) return True return False

这段代码有几个关键点值得注意：

_leak()方法在每次allow_request()调用时执行，根据时间差计算应处理的请求数；
队列长度代表当前积压量，直接影响是否接受新请求；
所有操作都在主线程完成，意味着每个请求都要等待“漏水”判断结束才能得到响应。

这带来一个明显的副作用：在高并发下，频繁的时间计算和队列操作可能成为性能瓶颈。更麻烦的是，如果“漏水”间隔太长，可能导致短时间内大量请求涌入，造成瞬时堆积。

但它也有不可替代的优势：逻辑清晰、无外部依赖、易于调试。对于边缘设备上的小型模型服务，或是内部工具类API，完全够用。

动态漏桶：为云原生而生的演进形态

当你把服务搬到Kubernetes上，接入Prometheus监控，使用Redis做任务队列时，经典的同步漏桶就显得格格不入了。你不再希望每一个HTTP请求都被阻塞去查状态，而是希望快速返回“已接收”，然后由后台慢慢处理。

于是，“动态漏桶”应运而生。

它的核心思想是：将“漏水”动作从请求路径中剥离，交给独立的异步任务来驱动。前端只管进，后端按时出，彻底实现非阻塞。

以下是一个基于asyncio的实现示例：

import asyncio from collections import deque import aiohttp class AsyncLeakyBucket: def __init__(self, capacity: int, leak_rate: float): self.capacity = capacity self.leak_rate = leak_rate self.queue = deque() self.is_running = False async def start(self): self.is_running = True asyncio.create_task(self._background_leak()) async def _background_leak(self): while self.is_running: await asyncio.sleep(1 / self.leak_rate) if self.queue: request_ctx = self.queue.popleft() await self._process_request(request_ctx) async def _process_request(self, ctx): async with aiohttp.ClientSession() as session: try: async with session.post("http://localhost:8080/generate", json=ctx) as resp: result = await resp.json() print("处理完成:", result) except Exception as e: print("处理失败:", e) def add_request(self, request_data: dict) -> bool: if len(self.queue) < self.capacity: self.queue.append(request_data) return True return False

这里的关键变化在于：

add_request()是纯内存操作，几乎无延迟；
_background_leak()协程独立运行，按设定频率消费队列；
整个流程可以无缝集成进FastAPI中间件，作为推理接口的前置限流层。

更重要的是，这种结构天然支持扩展：

可以结合Redis List + Lua脚本实现跨实例共享桶状态；
可通过Prometheus采集队列长度、处理延迟等指标；
可配合HPA（Horizontal Pod Autoscaler）实现自动扩缩容；
甚至能引入优先级队列机制，为VIP用户提供更快通道。

在ms-swift这类支持一键部署、量化导出与多后端推理（如LmDeploy、SGLang）的全链路工具链中，动态漏桶已经成为构建弹性服务架构的事实标准。

实际应用中的设计权衡

回到那个多租户共用集群的问题：如何避免团队之间的资源争抢？

答案是：为每个租户分配独立的漏桶实例。你可以用配置文件定义不同策略：

tenants: team-a: bucket_capacity: 10 leak_rate: 3.0 team-b: bucket_capacity: 20 leak_rate: 5.0

结合RBAC权限系统，就能实现逻辑层面的QoS隔离。比如市场部临时需要跑批量生成任务，可以适当调高其配额；而客服机器人则保持低延迟、小容量的稳定节奏。

但这背后也有一些容易被忽视的设计细节：

桶容量怎么设？

太大，会导致请求积压太久，用户体验差；太小，又容易频繁触发限流。建议设置为平均峰值请求量的1.2~1.5倍，并配合超时机制清理长期滞留请求。

漏水速率怎么定？

必须基于实际硬件能力。例如，在A100上运行Llama3-8B，实测吞吐约为20 req/s，那么全局速率就不应超过此值。可以通过压力测试+监控数据反复校准。

存储后端选什么？

小规模服务可以直接用内存队列；一旦涉及多副本部署，就必须使用Redis等共享存储，否则各实例之间无法协同。注意使用Lua脚本保证入队和判断的原子性。

是否要记录日志？

一定要。被限流的请求IP、时间戳、目标模型名都应该记录下来，便于后续分析行为模式、调整配额或识别恶意调用。

两种漏桶的本质差异

维度	经典漏桶	动态漏桶
执行模型	同步、请求驱动	异步、事件驱动
性能影响	每次请求都有额外开销	前端近乎零成本
架构耦合度	高，嵌入业务逻辑	低，可独立部署
扩展性	差，难以跨节点共享状态	强，支持分布式队列
适用场景	单机服务、边缘计算、测试环境	微服务、K8s、生产级推理平台