详解【限流算法】：令牌桶、漏桶、计算器算法及Java实现

令牌桶算法

**令牌桶（Token Bucket）**算法以一个设定的速率产生令牌（Token）并放入令牌桶，每次用户请求都得申请令牌，如果令牌不足，则拒绝请求。

令牌的数量也是有上限的。令牌的数量与时间和发放速率强相关，时间流逝的时间越长，会不断往桶里加入越多的令牌，如果令牌发放的速度比申请速度快，令牌桶会放满令牌，直到令牌占满整个令牌桶。

• 想象一个固定容量的 "令牌桶"，系统按固定速率向桶中添加令牌（比如每秒放 10 个）。
• 当有请求到达时，需要从桶中获取一个令牌才能被处理；如果桶中没有令牌，请求则被丢弃或排队。
• 令牌桶的容量决定了允许的最大突发流量（比如桶容量 100，意味着最多允许 100 个请求同时突发）。

关键概念：

• 令牌生成速率（r）：每秒生成的令牌数量（控制长期平均速率）。
• 令牌桶容量（b）：桶最多能存放的令牌数（控制最大突发流量）。
• 令牌消耗：每个请求消耗 1 个令牌（可调整为按请求大小消耗）。

特点：

• 平滑流量：通过固定速率生成令牌，限制长期平均请求速率。消费速度不固定。
• 允许突发：桶中累积的令牌可应对短时间的突发流量（只要不超过桶容量）。
• 灵活性：可调整令牌生成速率和桶容量，适配不同场景。

Java代码实现

/**
 * 令牌桶限流算法
 */
public class TokenBucketLimiter {
    // 桶的容量
    private final int capacity;
    // 令牌生成速度 (个/秒)
    private final int rate;
    // 当前令牌数量
    private final AtomicInteger tokens;

    /**
     * 构造函数
     * @param capacity 桶的容量
     * @param rate     令牌生成速度 (个/秒)
     */
    public TokenBucketLimiter(int capacity, int rate) {
        this.capacity = capacity;
        this.rate = rate;
        this.tokens = new AtomicInteger(capacity); // 初始化时令牌桶是满的

        // 启动令牌生成器线程
        startTokenProducer();
    }

    /**
     * 启动一个定时任务，以固定速率向桶中添加令牌
     */
    private void startTokenProducer() {
        ScheduledExecutorService scheduledThreadPool = Executors.newSingleThreadScheduledExecutor();
        // 延迟0秒后开始执行，每隔1秒执行一次
        scheduledThreadPool.scheduleAtFixedRate(() -> {
            // 尝试增加令牌，确保不超过容量
            // getAndUpdate 是一个原子操作，它会获取当前值，根据函数计算新值，并更新它
            tokens.getAndUpdate(current -> Math.min(capacity, current + rate));
            // System.out.println("令牌已补充，当前令牌数: " + tokens.get()); // 可以注释掉，用于调试
        }, 0, 1, TimeUnit.SECONDS);
    }

    /**
     * 尝试获取一个令牌
     * @return 如果获取成功则返回 true，否则返回 false
     */
    public boolean tryAcquire() {
        return tryAcquire(1);
    }

    /**
     * 尝试获取指定数量的令牌
     * @param numberOfTokens 需要获取的令牌数量
     * @return 如果获取成功则返回 true，否则返回 false
     */
    public boolean tryAcquire(int numberOfTokens) {
        if (numberOfTokens <= 0) {
            throw new IllegalArgumentException("令牌数量必须大于0");
        }
        
        while (true) {
            int current = tokens.get();
            // 如果当前令牌数不足以获取所需数量，则直接返回 false
            if (current < numberOfTokens) {
                return false;
            }
            // 尝试原子地减少令牌数
            if (tokens.compareAndSet(current, current - numberOfTokens)) {
                // 减少成功，返回 true
                return true;
            }
            // 如果 compareAndSet 失败，说明在获取和设置之间有其他线程修改了令牌数，
            // 循环会重试，直到成功或确定无法获取为止。
        }
    }

    /**
     * 获取当前桶中的令牌数 (主要用于调试和监控)
     * @return 当前令牌数
     */
    public int getCurrentTokens() {
        return tokens.get();
    }
    
}

漏桶算法

想象一个底部有漏洞的 "漏桶"，水（请求 / 数据包）从顶部流入桶中，桶底以固定速率漏水（处理请求）。无论流入速度多快（突发流量），漏水速度始终保持不变，从而限制了输出速率。如果流入速度超过漏水速度，桶会逐渐装满，当桶满后，多余的水会溢出（丢弃请求）。

关键概念：

• 漏桶容量（b）：桶最多能容纳的请求数（或数据量），决定了允许的最大突发流量缓冲。
• 漏水速率（r）：每秒从桶中处理的请求数（固定速率，控制长期输出速率）。
• 流入速率：请求到达的速率（可变，可能突发）。

令牌桶算法是 "漏桶算法" 的改进版：漏桶算法仅限制输出速率，不允许突发流量；令牌桶允许突发，但长期速率受控。

特点：

• 平滑输出：无论输入流量如何突发，输出速率始终保持固定（由漏水速率决定）。
• 限制突发：桶容量限制了最大缓冲请求数，超过容量的突发流量会被丢弃。
• 无累积令牌：与令牌桶不同，漏桶不会累积 "处理能力"，仅被动缓冲和匀速处理。

/**
 * 漏桶限流算法
 */
public class LeakyBucketLimiter {
    // 漏桶的容量
    private final int capacity;
    // 漏水速率 (个/秒)
    private final int rate;
    // 当前桶中的请求数量
    private final AtomicInteger water = new AtomicInteger(0);

    /**
     * 构造函数
     * @param capacity 漏桶的容量
     * @param rate     漏水速率 (个/秒)
     */
    public LeakyBucketLimiter(int capacity, int rate) {
        this.capacity = capacity;
        this.rate = rate;

        // 启动漏水线程
        startLeaker();
    }

    /**
     * 启动一个定时任务，以固定速率从桶中"漏水"（处理请求）
     */
    private void startLeaker() {
        ScheduledExecutorService scheduledThreadPool = Executors.newSingleThreadScheduledExecutor();
        // 延迟0秒后开始执行，每隔1秒执行一次
        scheduledThreadPool.scheduleAtFixedRate(() -> {
            // 每次漏水，尝试将当前水量减少rate个
            // getAndUpdate 是原子操作，确保线程安全
            water.getAndUpdate(current -> {
                int newWaterLevel = current - rate;
                // 不能让水量小于0
                return Math.max(0, newWaterLevel);
            });
            // System.out.println("漏水后，当前水量: " + water.get()); // 用于调试
        }, 0, 1, TimeUnit.SECONDS);
    }

    /**
     * 尝试添加一个请求到漏桶中
     * @return 如果添加成功（桶未满）则返回 true，否则返回 false（桶满，请求被丢弃）
     */
    public boolean tryAddRequest() {
        return tryAddRequest(1);
    }

    /**
     * 尝试添加指定数量的请求到漏桶中
     * @param numberOfRequests 需要添加的请求数量
     * @return 如果添加成功（桶未满）则返回 true，否则返回 false（桶满，请求被丢弃）
     */
    public boolean tryAddRequest(int numberOfRequests) {
        if (numberOfRequests <= 0) {
            throw new IllegalArgumentException("请求数量必须大于0");
        }

        while (true) {
            int currentWaterLevel = water.get();
            // 检查添加后是否会溢出
            if (currentWaterLevel + numberOfRequests > capacity) {
                return false; // 桶满，拒绝请求
            }
            // 尝试原子地增加水量
            if (water.compareAndSet(currentWaterLevel, currentWaterLevel + numberOfRequests)) {
                return true; // 添加成功
            }
            // 如果 compareAndSet 失败，则循环重试
        }
    }

    /**
     * 获取当前桶中的请求数量 (主要用于调试和监控)
     * @return 当前水量
     */
    public int getCurrentWaterLevel() {
        return water.get();
    }
}

计数器算法

计数器算法的核心思想非常简单：在一个固定的时间窗口内，统计请求的数量，如果请求数超过了预设的阈值，就拒绝后续的请求。

可以想象成一个收费站，在一个小时内（时间窗口）最多允许 100 辆车通过（阈值）。当第 101 辆车到达时，收费站就会关闭栏杆，拒绝其通过。等到下一个小时开始，计数器清零，栏杆重新打开。

优点：

• 实现简单：逻辑非常清晰，代码容易编写和理解。
• 高效：只涉及简单的时间比较和计数操作，性能开销极小。

缺点（临界问题）：

最严重的问题是 "临界区" 或 "突刺流量" 问题 。假设时间窗口是 1 秒，阈值是 100。如果在第 0.9 秒时来了 100 个请求，全部被允许。然后在第 1.1 秒时（进入了新的窗口），又来了 100 个请求，也全部被允许。那么在 0.9 秒到 1.1 秒这短短 0.2 秒内，系统实际上处理了 200 个请求，这可能会瞬间压垮下游服务。

这个问题的根源在于时间窗口的切换是瞬间完成的，没有平滑过渡。

/**
 * 计数器限流算法
 */
public class CounterLimiter {
    // 一个时间窗口内的最大请求数
    private final int maxRequests;
    // 时间窗口大小（毫秒）
    private final long windowSize;
    // 当前窗口的请求计数器
    private final AtomicInteger currentCount = new AtomicInteger(0);
    // 当前窗口的起始时间戳（毫秒）
    private final AtomicLong windowStartTime = new AtomicLong(System.currentTimeMillis());

    /**
     * 构造函数
     * @param maxRequests 一个时间窗口内的最大请求数
     * @param windowSize  时间窗口大小（秒）
     */
    public CounterLimiter(int maxRequests, int windowSize) {
        this.maxRequests = maxRequests;
        this.windowSize = windowSize * 1000L; // 转换为毫秒

        // 启动一个定时任务，定期检查并重置窗口，避免长时间不请求导致的窗口不更新问题
        startWindowResetTask();
    }

    /**
     * 尝试获取一个请求许可
     * @return 如果获取成功则返回 true，否则返回 false
     */
    public boolean tryAcquire() {
        long now = System.currentTimeMillis();

        // 1. 检查是否进入了新的时间窗口，如果是则重置计数器和窗口起始时间
        // 使用 compareAndSet 确保重置操作的原子性
        if (now - windowStartTime.get() > windowSize) {
            // 尝试原子地将窗口起始时间更新为当前时间
            // 只有当当前窗口起始时间仍然是 oldStartTime 时才会更新成功
            // 这可以防止多个线程同时重置窗口
            long oldStartTime = windowStartTime.get();
            if (windowStartTime.compareAndSet(oldStartTime, now)) {
                // 重置计数器
                currentCount.set(0);
                System.out.println("时间窗口已重置，新窗口起始时间: " + now);
            }
        }

        // 2. 检查当前窗口内的请求数是否已超限，并原子地增加计数
        int current = currentCount.getAndIncrement();
        return current < maxRequests;
    }

    /**
     * 启动一个定时任务，定期检查窗口是否过期。
     * 这是一个守护线程，主要用于在长时间没有请求的情况下，也能保证窗口能被重置。
     */
    private void startWindowResetTask() {
        ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
        // 每隔 windowSize/2 的时间检查一次，确保窗口能及时重置
        scheduler.scheduleAtFixedRate(() -> {
            long now = System.currentTimeMillis();
            if (now - windowStartTime.get() > windowSize) {
                windowStartTime.set(now);
                currentCount.set(0);
                // System.out.println("定时任务触发窗口重置"); // 用于调试
            }
        }, this.windowSize / 2, this.windowSize / 2, TimeUnit.MILLISECONDS);
    }
}

可以通过Redis + Lua来实现计数器算法的功能。典型的场景就是用户登录场景，可以用计数器+验证码的功能来实现削峰，降低并发量。可以设定时间窗口为1s，请求根据具体业务设置请求数阈值，每当发出一个用户登录请求就通过Lua脚本在Redis中更新计数器。如果达到了阈值就使当前请求进入验证码流程，然后重置计数器。