深入理解令牌桶算法：实现分布式系统高效限流的秘籍

Code季风2025-07-28 10:20

​ 在高并发系统中，"限流" 是保障服务稳定的核心手段 ------ 当请求量超过系统承载能力时，合理的限流策略能避免服务过载崩溃。令牌桶算法（Token Bucket）作为最经典的限流算法之一，既能控制请求的平均速率，又能容忍短时间的流量峰值，被广泛应用于 API 网关、微服务限流等场景。本文将从原理、特性、实现到应用，全方位解析令牌桶算法，帮你彻底掌握这一面试高频考点。

一、为什么需要限流？从 "秒杀系统崩溃" 说起

想象一个场景：某电商平台的秒杀活动中，正常情况下服务器每秒能处理 1000 个请求，但活动开始瞬间涌入 10 万个请求 ------ 此时若不加以控制，服务器会因 CPU、内存耗尽而崩溃，甚至引发数据库宕机，导致整个系统不可用。

限流的作用就是 "削峰填谷 "，通过控制请求的处理速率，让系统在承载范围内平稳运行。常见的限流算法有三种：固定窗口、滑动窗口、令牌桶，其中令牌桶算法因兼顾 "平均速率" 和 "瞬时峰值" 控制，成为最常用的方案。

二、令牌桶算法：核心原理与特性

令牌桶算法的核心思想是 "通过发放令牌控制请求的处理权限"，只有拿到令牌的请求才能被处理。我们可以把它想象成一个 "收费站"：

1. 算法模型：一个不断 "产币" 的桶

令牌桶算法包含两个核心组件：

  • 令牌桶：一个有固定容量的容器（比如最多装 100 个令牌）；
  • 令牌生成器：按固定速率向桶中发放令牌（比如每秒放 10 个）。

工作流程：

  1. 令牌生成器以固定速率（r个 / 秒）向桶中添加令牌，当桶满时（达到最大容量n），多余令牌会被丢弃；

  2. 每当有请求到达时，会尝试从桶中获取 1 个令牌：

    • 若获取成功（桶中有令牌），则请求被处理；
    • 若获取失败（桶中无令牌），则请求被限流（拒绝或排队等待）；

  3. 令牌的消耗与请求处理一一对应，处理完一个请求，桶中令牌数减 1。

​编辑

2. 关键特性：平均速率与瞬时峰值的平衡

令牌桶算法的强大之处在于，它同时控制了平均处理速率 和瞬时处理能力：

  • 平均速率可控 ：
    令牌生成速率r决定了系统的长期平均处理速率 ------ 无论短期流量如何波动，最终每秒处理的请求数会稳定在r附近（因为令牌生成速率固定）。
    例如：r=100（每秒生成 100 个令牌），则系统平均每秒最多处理 100 个请求。
  • 瞬时峰值可控 ：
    令牌桶的最大容量n决定了系统能承受的瞬时流量 ------ 如果某一时刻突然有大量请求（如秒杀开始），只要桶中令牌充足（最多n个），这些请求可以被瞬间处理，无需等待令牌生成。
    例如：n=500，则系统最多能一次性处理 500 个突发请求（前提是桶中积累了足够令牌）。

对比固定窗口算法 ：

固定窗口（如每秒最多处理 100 个请求）会严格限制 "每秒请求数≤100"，但无法应对瞬时峰值（即使前 59 秒请求为 0，第 60 秒也只能处理 100 个）；而令牌桶通过 "预存令牌" 的机制，允许合理的流量峰值，更符合实际业务场景（如用户集中在某一时刻操作）。

三、令牌桶算法的实现：从理论到代码

理解原理后，我们可以通过代码实现一个简单的令牌桶限流器。核心是动态计算当前可用令牌数，并判断请求是否能获取令牌。

1. 核心变量与逻辑

实现令牌桶需要维护三个关键变量：

  • capacity：桶的最大容量（最多存放多少令牌）；
  • rate：令牌生成速率（每秒生成多少个令牌）；
  • tokens：当前桶中的令牌数；
  • lastRefillTime：上次添加令牌的时间戳（用于计算这段时间应生成的令牌数）。

令牌补充逻辑 ：

每次有请求到达时，先根据 "当前时间 - 上次补充时间" 计算这段时间内应生成的令牌数，更新tokens（但不超过capacity），再判断是否能获取令牌。

公式：

ini 复制代码 
// 时间差（秒）
elapsedTime = (当前时间戳 - lastRefillTime) / 1000  
// 应补充的令牌数（不超过剩余容量）
newTokens = elapsedTime * rate  
tokens = min(tokens + newTokens, capacity)  
// 更新上次补充时间
lastRefillTime = 当前时间戳

2. Java 实现：一个简单的令牌桶限流器

java 复制代码 
import java.util.concurrent.TimeUnit;

public class TokenBucket {
    // 桶的最大容量
    private final long capacity;
    // 令牌生成速率（个/秒）
    private final double rate;
    // 当前令牌数
    private double tokens;
    // 上次补充令牌的时间戳（毫秒）
    private long lastRefillTime;

    public TokenBucket(long capacity, double rate) {
        this.capacity = capacity;
        this.rate = rate;
        this.tokens = capacity; // 初始时桶是满的
        this.lastRefillTime = System.currentTimeMillis();
    }

    /**
     * 尝试获取令牌
     * @return true：获取成功；false：被限流
     */
    public synchronized boolean tryAcquire() {
        // 1. 补充令牌
        refill();

        // 2. 尝试获取1个令牌
        if (tokens >= 1) {
            tokens--;
            return true;
        } else {
            // 令牌不足，限流
            return false;
        }
    }

    /**
     * 补充令牌（根据时间差计算应生成的令牌数）
     */
    private void refill() {
        long now = System.currentTimeMillis();
        // 计算时间差（秒）
        double elapsedTime = (now - lastRefillTime) / 1000.0;
        // 生成的新令牌数
        double newTokens = elapsedTime * rate;

        if (newTokens > 0) {
            // 更新令牌数（不超过最大容量）
            tokens = Math.min(tokens + newTokens, capacity);
            // 更新上次补充时间
            lastRefillTime = now;
        }
    }

    public static void main(String[] args) throws InterruptedException {
        // 测试：容量100，速率50个/秒
        TokenBucket tokenBucket = new TokenBucket(100, 50);

        // 模拟100个并发请求（瞬时峰值）
        for (int i = 0; i < 100; i++) {
            new Thread(() -> {
                if (tokenBucket.tryAcquire()) {
                    System.out.println(Thread.currentThread().getName() + "：获取令牌成功，处理请求");
                } else {
                    System.out.println(Thread.currentThread().getName() + "：被限流");
                }
            }).start();
        }

        // 等待1秒，让令牌生成
        TimeUnit.SECONDS.sleep(1);
        System.out.println("--- 1秒后 ---");

        // 再模拟60个请求（测试平均速率）
        for (int i = 0; i < 60; i++) {
            new Thread(() -> {
                if (tokenBucket.tryAcquire()) {
                    System.out.println(Thread.currentThread().getName() + "：获取令牌成功，处理请求");
                } else {
                    System.out.println(Thread.currentThread().getName() + "：被限流");
                }
            }).start();
        }
    }
}

3. 代码解析与测试结果

  • 初始状态 ：桶是满的（tokens = capacity），因此前 100 个请求会全部获取到令牌（瞬时峰值控制）；
  • 1 秒后：令牌生成速率为 50 个 / 秒，因此 1 秒内会生成 50 个令牌，此时 60 个请求中只有 50 个能获取到令牌（平均速率控制）。

测试结果符合预期：

diff 复制代码 
Thread-0：获取令牌成功，处理请求
...（共100个成功）
--- 1秒后 ---
Thread-101：获取令牌成功，处理请求
...（共50个成功）
Thread-151：被限流
...（共10个被限流）

四、令牌桶 vs 漏桶：为什么令牌桶更受欢迎？

另一种常见的限流算法是 "漏桶算法"，它的模型是 "请求像水一样注入漏桶，漏桶以固定速率出水（处理请求），水满则溢出（限流）"。两者的核心区别在于对 "瞬时流量" 的处理：

特性 令牌桶算法 漏桶算法
平均速率 可控制（由 rate 决定） 可控制（由出水速率决定）
瞬时峰值 允许（不超过 capacity） 不允许（严格按固定速率处理）
灵活性 高（适合突发流量场景） 低（适合严格控制速率的场景）
典型应用 API 网关、秒杀系统 网络传输（如 TCP 流量控制）

为什么令牌桶更常用？

在实际业务中，系统往往能承受短时间的流量峰值（只要不超过硬件上限）。例如：电商平台的 "整点抢购" 会瞬间产生大量请求，但只要服务器能处理，就应该允许这些请求通过 ------ 令牌桶的 "瞬时峰值容忍" 特性更符合这种场景，而漏桶的 "严格匀速" 可能会错过有效流量。

五、分布式场景：如何实现全局令牌桶？

单机令牌桶只能控制单个实例的流量，而分布式系统需要 "全局限流"（如限制某 API 的总 QPS 为 1000，无论多少个实例）。此时需要一个中心化的令牌桶实现：

1. 基于 Redis 的分布式令牌桶

利用 Redis 的INCR和过期时间特性，可以实现分布式令牌桶：

  • 用一个 Redis 键（如token:bucket:api）记录当前可用令牌数；
  • 用定时任务（如 Redis 的EXPIRE配合 Lua 脚本）按速率生成令牌；
  • 每个请求通过 Lua 脚本原子性地 "获取令牌"（DECR操作，若结果≥0 则成功）。

Lua 脚本示例（获取令牌） ：

lua 复制代码 
-- 键：令牌数；参数：capacity, rate
local tokens = tonumber(redis.call('get', KEYS[1]) or 0)
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])

-- 补充令牌（简化版：假设每100ms调用一次补充）
local newTokens = math.min(tokens + rate * 0.1, capacity)
redis.call('set', KEYS[1], newTokens)

-- 尝试获取1个令牌
if newTokens >= 1 then
    redis.call('decr', KEYS[1])
    return 1  -- 成功
else
    return 0  -- 失败
end

2. 成熟组件：不用重复造轮子

生产环境中，推荐使用成熟的限流组件，它们已内置令牌桶算法：

  • Java ：Spring Cloud Gateway 的RequestRateLimiter过滤器（支持 Redis 令牌桶）、Sentinel 的TokenBucketRateLimiter；
  • Go ：golang.org/x/time/rate包（官方令牌桶实现）；
  • API 网关 ：Kong、Nginx（通过ngx_http_limit_req_module模拟令牌桶）。

六、实战技巧：令牌桶参数如何设置？

合理设置capacity和rate是令牌桶生效的关键，可参考以下经验：

  1. rate（令牌生成速率） ：
    参考系统的实际承载能力（如压测得出的最大 QPS），设置为略低于此值（如压测 QPS=1000，rate=800，留 20% 缓冲）。
  2. capacity（桶容量） ：
    参考业务的 "突发流量预期"，一般设置为rate * 1~5（如 rate=100，capacity=500，允许 5 秒的突发流量）。
  3. 动态调整 ：
    在流量波动大的场景（如电商大促），可通过监控实时调整参数 ------ 例如：高峰期临时提高capacity以应对突发流量。

七、总结：令牌桶是 "刚性限流" 与 "柔性体验" 的平衡

令牌桶算法的核心价值在于：它既通过rate控制了系统的长期负载（避免过载），又通过capacity容忍了短时间的流量峰值（提升用户体验）。这种 "刚柔并济" 的特性，让它成为高并发系统中限流的首选方案。

理解令牌桶不仅能帮你应对面试，更能在实际工作中设计出更合理的限流策略 ------ 记住：限流的最终目的不是 "拒绝请求"，而是 "让系统在可控范围内稳定运行"，令牌桶正是这一目标的完美实现。

​

相关推荐
Eloudy3 分钟前
复矩阵与共轭转置矩阵乘积及其平方根矩阵
人工智能·算法·矩阵
m0_631354455 分钟前
VTK开发day2:切片矩阵
人工智能·算法·矩阵
GEM的左耳返10 分钟前
Java面试全方位解析：从基础到AI的技术交锋
spring boot·微服务·java面试·互联网大厂·rag技术·ai面试·java技术栈
go546315846523 分钟前
在本地环境中运行 ‘dom-distiller‘ GitHub 库的完整指南
人工智能·深度学习·神经网络·算法·矩阵·github
微笑听雨41 分钟前
Java 设计模式之单例模式（详细解析）
java·后端
微笑听雨41 分钟前
【Drools】（二）基于业务需求动态生成 DRL 规则文件：事实与动作定义详解
java·后端
Serendipity2611 小时前
微服务架构
前端·微服务
weixin_537590451 小时前
【任务6.13】计算肇事汽车号码
c++·算法·汽车
从今天开始学习Verilog1 小时前
FFT算法实现之fft IP核
算法·fpga开发
猫猫的小茶馆1 小时前
【STM32】FreeRTOS 任务的删除（三）
java·linux·stm32·单片机·嵌入式硬件·mcu·51单片机
热门推荐
01Qwen3-Coder 快速上手教程 | Qwen Code + Claude Code02扣子开源本地部署教程 丨Coze智能体小白喂饭级指南03Coze 开源了，送上保姆级私有化部署方案【建议收藏】04全球最强模型Grok4，国内已可免费使用！（附教程）05vue数据变化但页面不变06KGG转MP3工具|非KGM文件|解密音频07干翻 Typora！MilkUp：完全免费的桌面端 Markdown 编辑器！0801-开源版COZE-字节 Coze Studio 重磅开源！保姆级本地安装教程，手把手带你体验09腾讯还是太全面了，限时免费！超全CodeBuddy IDE保姆级教程！（附案例）10sqli-labs 靶场 less-8、9、10 第八关到第十关详解：布尔注入，时间注入