漏桶算法本质是恒速排水器，以固定速率r处理请求、容量b限制积压，桶满即拒，不支持突发容忍；适用于强顺序、低延迟场景，实现需精确时间补漏与状态同步。

漏桶算法的核心作用不是缓冲并发，而是强制平滑输出——它不放大突发，也不保留“等待权”，只允许以恒定速率放行请求。

漏桶的本质是“恒速排水器”，不是“弹性队列”

桶里存的不是待处理的请求，而是已接纳但尚未被系统处理的请求积压。它的容量（b）代表最大允许积压量，漏水速率（r）代表系统真实稳定的处理能力。一旦新请求到来时桶已满，就直接拒绝，不会排队或延迟；也不会因为当前空闲就加速处理——空闲时段桶只是“干着”，不补漏、不提速。

• 桶满即拒：没有重试、不进队列、不降级转发
• 漏速恒定：无论上游是1QPS还是1000QPS，下游永远按r QPS稳定消费
• 无突发容忍：它不支持“先攒后冲”，与令牌桶的burst能力有本质区别

关键参数如何影响实际效果

桶容量b和漏速r需结合业务SLA与资源水位共同设定。例如一个数据库写接口，连接池上限为50，平均单次耗时200ms，则理论可持续吞吐为5 req/s（50 ÷ 0.2）。此时若设r = 5，b可设为10～20——足够容纳短时毛刺，又不至于让失败请求堆积太久。

• b太小：正常波动也会触发丢弃，可用性下降
• b太大：积压请求长时间滞留，响应延迟不可控，甚至掩盖真实过载
• r高于真实处理能力：系统持续过载，错误率上升
• r远低于能力：资源闲置，吞吐浪费

适合用漏桶的典型场景

适用于对响应一致性、节奏稳定性要求高，且能接受少量丢弃的链路。比如计费扣款、日志上报、审计事件推送等不允许乱序、不能超频、也不宜延迟的强顺序型操作。

• 下游依赖强时效性硬件（如嵌入式设备通信）
• 协议层要求严格恒定帧率（如视频流码率整形）
• 金融类最终一致性事务的异步补偿通道
• 网关对恶意扫描流量做匀速限速导出分析

代码实现中容易忽略的细节

真实落地时，常见误区是用简单计数器模拟漏桶，却忽略了时间连续性。正确做法是每次检查前先按时间差“补漏”：water = max(0, water − (now − lastTime) × r)，再判断是否可入桶。否则在低频请求下会误判桶“长期不满”，导致限流失效。

• 必须维护lastTime和当前water状态，不能每次重置
• 浮点运算需防精度漂移，建议用整型微秒+固定单位（如每毫秒漏0.001个）
• 高并发下需加锁或用CAS更新，避免water被多线程写乱