6种限流方法之服务端漏桶算法

### 令牌桶算法与漏桶算法对比 #### 实现原理 令牌桶算法（Token Bucket Algorithm）通过维持一个固定容量的令牌桶来控制数据包的发送速率。每当有新请求到来时，会尝试消耗一定数量的令牌；如果此时有足够的令牌，则允许该操作继续执行并减少相应数量的令牌。反之则拒绝服务或延迟处理直至获得足够的资源许可[^3]。 相比之下，漏桶算法（Leaky Bucket Algorithm）采用了一种更为严格的流量调控机制——想象有一个带有孔洞的容器持续向外渗水，当新的水流进入此装置内部时会被暂时储存起来等待缓慢流出。这意味着即使短时间内有大量的输入到达也只会按照固定的滴速排出，从而实现了平滑的数据流输出效果[^1]。 #### 主要差异 最显著的不同之处在于两者对于突发流量的支持程度： - **突发支持**：由于其设计特性，“令牌桶”可以容纳一定程度上的瞬时高峰负荷，在满足预设条件的情况下允许一次性释放较多量级的信息传递出去； - **严格限速**：“漏桶”的工作方式决定了它不具备这样的灵活性，始终保持着恒定不变的速度对外提供服务而不受外界因素干扰[^2]。 #### 应用场景 基于上述特点，两种方法适用于不同类型的业务需求： - 对于那些可能经历间歇性高并发访问压力的服务端接口而言，比如社交平台的消息推送功能或是电商平台促销活动期间的商品详情页加载过程，选用“令牌桶”策略往往更加合适因为这能兼顾性能优化的同时保障用户体验不受太大影响； - 而在网络通信领域内涉及到实时性强且对延时敏感的任务时（例如VoIP通话），为了确保音视频质量稳定可靠，则更倾向于依赖“漏桶”来进行精准的时间间隔调整以防止抖动现象发生。 ```python import time from threading import Thread, Lock class TokenBucket: def __init__(self, rate_limit, bucket_size): self.rate_limit = rate_limit # 每秒产生的token数目 self.bucket_size = bucket_size # token桶的最大容量 self.tokens = min(bucket_size, rate_limit * (time.time() % 1)) self.lock = Lock() def consume(self, tokens_needed=1): with self.lock: now = int(time.time()) if (now > self.last_time and self.tokens < self.bucket_size): elapsed = now - self.last_time new_tokens = elapsed * self.rate_limit self.tokens = min(self.bucket_size, self.tokens + new_tokens) self.last_time = now if self.tokens >= tokens_needed: self.tokens -= tokens_needed return True return False def leaky_bucket(data_rate, max_queue_length): queue = [] while True: data_incoming = yield from get_data() if len(queue) < max_queue_length: queue.append(data_incoming) processed_item = None if queue: processed_item = queue.pop(0) send_to_next_hop(processed_item) time.sleep(1 / data_rate) # Note: The above code snippets are simplified examples to illustrate the concepts. ```