前言：
在构建高可用、高性能的分布式系统时，流量控制是保障系统稳定性的关键一环。面对突如其来的流量洪峰或恶意攻击，合理的限流策略能够有效保护系统资源，维持服务的正常运转。在众多限流算法中，令牌桶算法
(Token Bucket Algorithm)因其独特的优势而广受欢迎。
一、简介：什么是令牌桶
令牌桶算法是一种用于控制数据传输速率或处理请求速率的流量整形和速率限制技术。它通过一个抽象的“桶”和“令牌”的概念，来实现对流量的灵活控制。
它不像其他算法那样直接限制单位时间内的请求数，而是通过一个“预付费”或“配额”的机制。系统不断地往桶里放“令牌”，请求想要通过，就必须先拿到“令牌”。这种方式天然地支持了对突发流量的处理。
核心组成：
- 一个固定容量的“桶”：用来存放令牌，其容量决定了瞬间能处理的最大请求数。
- “令牌”：代表被允许处理的单位资源或请求。
- 恒定的令牌生成速率：系统以固定的速率向桶中添加令牌。
二、令牌桶是怎么工作的，什么时候会用到
令牌桶的工作流程遵循其核心规则。系统后台以恒定速率生成令牌并放入桶中，桶满了则丢弃新令牌。当请求到来时，检查桶内令牌数，足够则消耗令牌处理请求，不足则按策略处理（拒绝/等待）。
令牌桶特别适用于那些既需要控制长期平均流量，又希望能处理一定程度突发流量的场景。它不像漏桶那样死板地强制平滑输出，而是提供了一种弹性的缓冲机制。
工作流程：
- 系统以固定速率
r向容量为c的桶中添加令牌。 - 请求到达时，尝试从桶中获取所需令牌。
- 若令牌充足，请求被处理，令牌被消耗。
- 若令牌不足，请求被拒绝或阻塞等待。
典型应用场景：
- API 接口限流：保护后端服务，防止被瞬时高并发打垮，同时允许一定程度的突发访问。
- 网络带宽控制：限制上传/下载速度，保证带宽资源的合理分配。
- 微服务间调用：防止某个服务的过载调用拖垮依赖的服务。
- 防止爬虫或恶意攻击：限制特定 IP 或用户 ID 的请求频率。
三、漏桶 vs 令牌桶
漏桶算法：所有请求先进入桶中，桶以固定的速率处理请求并流出。如果流入速率过快导致桶满了，新来的请求会溢出。
| 特性 | 令牌桶 (Token Bucket) | 漏桶 (Leaky Bucket) |
|---|---|---|
| 核心机制 | 控制令牌添加的速率，处理请求的速率是动态的。 | 控制请求漏出的速率，处理请求的速率是恒定的。 |
| 处理突发流量 | 允许。可以瞬间消耗桶内积累的令牌来处理突发流量。 | 不允许。突发流量会先在桶内堆积，超过桶容量则直接丢弃。 |
| 流量平滑性 | 输出速率可变，允许抖动。 | 输出速率平滑，强制整形。 |
| 主要目标 | 速率限制 (Rate Limiting)：保护系统不被超额流量冲击。 | 流量整形 (Traffic Shaping)：平滑输出流量，保护下游系统。 |
| 桶满时的处理 | 新生成的令牌被丢弃。 | 新来的请求被丢弃。 |
| 适用场景 | API网关、微服务保护、需要容忍短时突发的业务。 | 消息队列消费、网络出口流量整形、需要严格恒定输出的场景。 |
四、令牌桶的独特优势
- 灵活性高：既能限制长期平均速率，又能应对短期突发，在保护系统和提升用户体验之间取得绝佳平衡。
- 容忍突发：桶的容量设计为系统应对突发流量提供了“弹性空间”，避免因瞬时高峰而错误地拒绝正常请求。
- 易于理解与实现：模型简单直观，逻辑清晰，无论是基于代码还是配置都容易实现。
- 适用性广：从网络传输、API网关到单体应用内的方法调用，都可以找到其用武之地。
五、动手实现一个令牌桶
下面是一个简单的 Java 实现示例，助你快速理解其内在逻辑。
importjava.util.concurrent.locks.Lock;importjava.util.concurrent.locks.ReentrantLock;/** * 精简的线程安全令牌桶实现。 */publicclassSimpleTokenBucket{privatefinallongcapacity;// 桶容量privatefinallongtokensPerSecond;// 令牌生成速率 (每秒)privatelongcurrentTokens;// 当前令牌数privatelonglastRefillTimestamp;// 上次更新时间戳 (ns)privatefinalLocklock=newReentrantLock();// 保证线程安全/** * 构造函数 * @param capacity 桶容量 * @param tokensPerSecond 令牌生成速率 */publicSimpleTokenBucket(longcapacity,longtokensPerSecond){if(capacity<=0||tokensPerSecond<=0){thrownewIllegalArgumentException("Capacity and tokensPerSecond must be positive.");}this.capacity=capacity;this.tokensPerSecond=tokensPerSecond;this.currentTokens=capacity;// 初始化为满this.lastRefillTimestamp=System.nanoTime();}/** * 尝试消费令牌 * @param tokensNeeded 需要的令牌数 * @return 是否成功消费 */publicbooleantryConsume(longtokensNeeded){if(tokensNeeded<=0)returntrue;// 不需要令牌，直接成功lock.lock();try{refill();// 根据时间补充令牌if(currentTokens>=tokensNeeded){currentTokens-=tokensNeeded;// 消费令牌returntrue;}returnfalse;// 令牌不足}finally{lock.unlock();}}/** 根据时间流逝补充令牌 */privatevoidrefill(){longnow=System.nanoTime();doubleelapsedSeconds=(now-lastRefillTimestamp)/1_000_000_000.0;if(elapsedSeconds>0){longtokensToAdd=(long)(elapsedSeconds*tokensPerSecond);if(tokensToAdd>0){// 更新令牌数，不超过容量currentTokens=Math.min(capacity,currentTokens+tokensToAdd);lastRefillTimestamp=now;// 更新时间戳}}}// --- 辅助方法 ---/** 获取当前可用令牌数 (估算) */publiclonggetAvailableTokens(){lock.lock();try{refill();// 获取前先更新returncurrentTokens;}finally{lock.unlock();}}@OverridepublicStringtoString(){returnString.format("SimpleTokenBucket{capacity=%d, rate=%d/s, tokens=%d}",capacity,tokensPerSecond,getAvailableTokens());}}六、注意事项
令牌生成速率 r:这是你希望限制的长期平均请求速率。设置过高起不到保护作用，过低会影响正常业务。通常需要根据下游服务的处理能力、业务需求和历史流量数据来确定。
桶容量 c:这决定了可以容忍的最大突发请求数量。它充当了一个缓冲区。设置过小会频繁拒绝正常的突发请求，设置过大可能导致瞬间压力超出下游承受能力。需要平衡突发容忍度和系统保护。
冷启动问题：系统刚启动时，桶可能是空的，导致初始的请求即使在正常速率下也可能被拒绝。可以通过初始化时预填充一定令牌来缓解。
线程安全：在多线程环境下，对令牌数量和时间戳的操作必须保证原子性，否则会出现计算错误。上述代码使用了ReentrantLock和AtomicLong来保证线程安全。
七、总结
令牌桶算法以其出色的灵活性和对突发流量的容忍度，在分布式系统的流量控制设计中占据着举足轻重的地位。当然，它并非万能，在需要严格平滑流量输出的场景下，漏桶算法仍是更优的选择。
