漏桶、令牌桶与滑动窗口业务场景选型

一、漏桶 VS 令牌桶

1.1 核心观点

微服务之间的调用适合漏桶算法，核心原因是微服务架构追求稳定性和可预测性，而漏桶的核心优势就是强制流量平滑输出，避免下游服务被突发请求压垮；而秒杀场景并非不适合微服务调用，只是要分环节、分场景选择限流算法。

1.2 微服务调用偏爱漏桶的核心逻辑

微服务之间是强依赖的协作关系，比如支付服务→风控服务，选择漏桶算法的核心逻辑可总结为三点：

1.2.1 下游服务的资源是刚性约束

风控服务的CPU、内存、线程数都是有限的，它的处理能力有明确的上限（比如每秒最多处理50次请求）。令牌桶允许突发流量（令牌攒够了可以一次性取走），这会瞬间把请求推给下游，导致下游CPU飙升、线程池排队；而漏桶不管上游来多少请求，都以固定速率放行，刚好匹配下游的处理能力，不会让下游的负载出现剧烈波动。

1.2.2 微服务调用更怕"雪崩"，而非"少量请求丢失"

微服务是链式调用的，一个服务被打垮，可能会牵连上游服务（比如支付服务因为风控服务超时，导致自己的线程池被占满），进而引发雪崩。漏桶的"平滑输出"本质是保护下游服务的稳定性，宁可让上游请求在漏桶里排队，也不让下游过载。

1.2.3 微服务间的调用多是"实时且必须成功"的场景

像支付→风控这种调用，不是"来了就能丢"的，需要尽可能保证请求被处理。漏桶的阻塞队列可以缓冲请求，而令牌桶如果令牌耗尽，请求会直接被拒绝（除非额外加队列）。

1.3 秒杀场景的微服务调用：分层选用算法

秒杀是微服务调用的高频场景，但不同环节适合不同的限流算法，核心思路是"前端扛突发、后端保稳定"：

1.3.1 前端/网关层：适合令牌桶

秒杀的入口会有大量突发流量涌入，这一层需要允许"合理的突发"------比如用户集中点击的那1秒，流量瞬间冲高，令牌桶可以快速发放积攒的令牌，处理掉这波突发请求，避免正常用户的请求被误杀（例如商品详情页用令牌桶提升转化率）。

1.3.2 核心业务层：适合漏桶

当请求到了核心微服务调用环节（比如订单服务→库存服务），就需要严格控制流量了。库存服务的扣减能力是固定的（比如每秒最多扣1000单），如果用令牌桶允许突发，库存服务的CPU会瞬间到100%，导致扣减超时、数据不一致。这时候用漏桶，以固定速率把请求发给库存服务，就能保证库存服务的稳定运行。

1.3.3 总结

微服务调用的核心需求是"保护下游"→ 漏桶的平滑输出刚好匹配这个需求
秒杀场景是"分层需求"→ 前端扛突发用令牌桶，后端保稳定用漏桶

二、滑动窗口算法：精准计数型限流方案

2.1 核心结论

滑动窗口算法是「计数型限流」的进阶优化方案，核心解决「固定窗口临界值突发流量」问题，适合对流量控制精度要求高、需要平滑限制单位时间内请求数的场景，尤其适配「接口调用频次限制、消息消费速度控制、API访问配额管控」等业务场景。

简单来说：固定窗口是"粗粒度控量"，滑动窗口是"细粒度控流"，在需要精准限制「每X秒/Y次」的场景下，滑动窗口是最优选择。

2.2 核心适用场景

滑动窗口的核心优势是「时间粒度的连续划分+流量的平滑计数」，完美适配以下3类核心场景，且是这些场景的首选限流方案：

接口频次精准限流（最常用）：限制用户/IP在「连续1分钟内最多调用100次接口」「每秒最多5次登录请求」；
消息队列消费速度控制：限制消费端「每1秒最多消费50条消息」，避免瞬间消费过多压垮下游业务；
第三方API配额管控：调用外部接口时，按服务商要求「每分钟最多调用200次」，精准匹配配额避免超量扣费。

核心适配原则：当业务需要「连续的、无临界突发的、精准的单位时间计数限流」，而非"允许突发"（令牌桶）或"强制固定速率"（漏桶）时，优先选择滑动窗口。

2.3 具体业务场景案例：用户登录接口频次限流（生产级落地）

用户登录接口防暴力破解是滑动窗口最典型、最常用的业务场景，以下结合实际需求讲透落地逻辑：

2.3.1 业务背景与痛点

业务需求：为防止暴力破解密码，需限制「同一用户/IP在连续1分钟内，最多只能发起5次登录请求」，超过则拒绝并提示"操作频繁"；
传统方案痛点 ：若用固定窗口算法实现（比如把1分钟划分为1个窗口，计数达到5则拒绝），会存在临界值突发漏洞：
- 例：用户在第59秒发起5次请求（窗口1计数满），第61秒又发起5次请求（窗口2重新计数），实际2秒内发起了10次请求，突破了"1分钟最多5次"的限制，暴力破解仍可实现；
- 这种临界值的突发流量，会直接绕过固定窗口的限流规则，导致业务防护失效。

2.3.2 滑动窗口算法的落地实现（精准解决痛点）

（1）窗口划分设计

将「1分钟（60秒）」的时间窗口，拆分为6个连续的子窗口，每个子窗口时长10秒，窗口总长度始终保持60秒，且每10秒向前滑动一次。

子窗口数量越多，时间粒度越细，限流精度越高（比如拆分为60个1秒的子窗口，精度最高）；
生产中一般按「1秒/5秒/10秒」划分子窗口，平衡精度与性能。

（2）计数与限流逻辑

初始化：创建6个10秒的子窗口，每个子窗口维护一个「登录请求计数器」；
接收请求：用户发起登录请求时，先计算当前时间所属的子窗口，将该窗口的计数器+1；
总和校验：累加当前所有有效子窗口（共6个，总时长60秒）的计数器值，若总和≥5，则拒绝请求；
窗口滑动：每10秒，窗口向前滑动一次，丢弃最旧的1个子窗口，新建1个空的子窗口，保证总时长始终为60秒。

（3）效果验证（彻底解决临界值问题）

仍以上述临界场景为例：

第59秒：用户发起5次请求，被计入「第6个子窗口（50-60秒）」，6个窗口总和=5，触发限流；
第61秒：窗口已滑动1次，丢弃了「0-10秒」的旧窗口，新建了「60-70秒」的新窗口，当前有效窗口为「10-70秒」（总时长60秒）；
此时用户发起请求，会被计入「60-70秒」的新窗口，累加6个窗口的总和：前5个窗口（10-60秒）总和=5，新窗口+1后总和=6，直接拒绝请求；

✅ 最终效果：无论用户在哪个时间点发起请求，滑动窗口都会校验「连续60秒内」的总次数，彻底杜绝临界值突发漏洞。

（4）代码核心逻辑（Java极简实现，生产可复用）

java 复制代码

import java.util.LinkedList;
import java.util.Queue;

/**
 * 滑动窗口实现：用户登录接口限流（1分钟最多5次）
 */
public class LoginSlideWindowLimiter {
    // 窗口总时长（毫秒）：1分钟
    private static final long WINDOW_TOTAL_TIME = 60 * 1000L;
    // 子窗口数量：6个
    private static final int SUB_WINDOW_COUNT = 6;
    // 每个子窗口时长
    private static final long SUB_WINDOW_TIME = WINDOW_TOTAL_TIME / SUB_WINDOW_COUNT;
    // 1分钟内最大请求数
    private static final int MAX_REQUEST_COUNT = 5;
    // 存储子窗口的计数器（队列：先进先出，方便滑动）
    private final Queue<Long> subWindowCounter = new LinkedList<>();

    public LoginSlideWindowLimiter() {
        // 初始化：6个子窗口，计数器初始化为0
        for (int i = 0; i < SUB_WINDOW_COUNT; i++) {
            subWindowCounter.offer(0L);
        }
    }

    /**
     * 校验是否允许登录请求
     * @return true-允许，false-拒绝
     */
    public synchronized boolean allowLogin() {
        // 1. 窗口滑动：移除过期的子窗口，补充新的空窗口
        slideWindow();
        // 2. 累加所有子窗口的计数
        long totalCount = subWindowCounter.stream().mapToLong(Long::longValue).sum();
        // 3. 判断是否超过阈值
        if (totalCount >= MAX_REQUEST_COUNT) {
            return false;
        }
        // 4. 当前子窗口计数+1
        subWindowCounter.poll();
        subWindowCounter.offer(totalCount + 1);
        return true;
    }

    /**
     * 窗口滑动逻辑：移除过期子窗口，补充新窗口
     */
    private void slideWindow() {
        long currentTime = System.currentTimeMillis();
        // 计算需要移除的过期子窗口数量
        while (!subWindowCounter.isEmpty()) {
            // 若最旧的子窗口已过期，移除
            if (currentTime - subWindowCounter.peek() > WINDOW_TOTAL_TIME) {
                subWindowCounter.poll();
            } else {
                break;
            }
        }
        // 补充新的空窗口，保证子窗口数量始终为6
        while (subWindowCounter.size() < SUB_WINDOW_COUNT) {
            subWindowCounter.offer(0L);
        }
    }

    // 测试
    public static void main(String[] args) throws InterruptedException {
        LoginSlideWindowLimiter limiter = new LoginSlideWindowLimiter();
        // 模拟第59秒发起5次请求
        for (int i = 0; i < 5; i++) {
            System.out.println("第" + (i+1) + "次登录请求：" + limiter.allowLogin()); // 前5次均为true
        }
        // 模拟第61秒发起第6次请求
        Thread.sleep(2000);
        System.out.println("第6次登录请求：" + limiter.allowLogin()); // false，触发限流
    }
}

三、三种限流算法核心区别与选型指南

以下通过对比表清晰呈现三种算法的核心差异，帮助快速完成场景选型：

限流算法	核心特性	流量控制效果	核心适用场景	缺点
滑动窗口	计数型，按连续时间窗口统计请求数，超过阈值则拒绝	精准限制单位时间内的总请求数，无临界突发，流量相对平滑	接口频次限流、登录防暴力破解、API配额管控	无法应对突发流量（即使下游有能力处理，也会直接拒绝）；子窗口越多，性能损耗越大
漏桶	流量整形，固定速率放行请求，多余请求排队	强制流量平滑输出，绝对保护下游	微服务间调用、核心业务层限流（如订单→库存）	无法利用下游的突发处理能力；请求排队可能导致超时
令牌桶	按需取令牌，令牌可积攒，支持突发流量	允许合理突发，兼顾流量限制与突发处理	前端/网关层限流、秒杀入口、商品详情页	突发流量可能压垮下游；需要合理设置令牌生成速率

3.1 选型核心总结

核心适用场景：需要精准限制连续单位时间内请求数（如1分钟5次登录），且要求无临界突发漏洞的场景，优先选滑动窗口（计数型限流最优解）；
控速率保下游：若核心需求是保护下游服务稳定，避免负载波动，选漏桶；
允许突发提性能：若需要应对前端/网关的突发流量，减少正常请求误杀，选令牌桶。