Spring Boot中Guava RateLimiter实现突发请求全放行的限流方案

问题本质 #

你碰到的情况是因为没有正确利用Guava RateLimiter的突发许可机制，默认的RateLimiter.create(5)虽然标称5请求/秒，但如果你的实现没做好实例隔离，或者误用了预热模式，就会出现固定间隔发许可的情况，导致短时间内的突发请求被拦截。

正确实现步骤 #

Guava RateLimiter有两种核心模式，你的场景必须用SmoothBursty（默认模式），它允许积累最多1秒的许可量，刚好满足你“5个请求同时/200ms内连续到达全部放行”的需求。

1. 为目标API独立维护RateLimiter实例 #

必须确保每个需要单独限流的API拥有自己的RateLimiter，不能和全局/其他API共享。用线程安全的Map存储：

private static final Map<String, RateLimiter> API_LIMITER_MAP = new ConcurrentHashMap<>();

// 初始化目标API的限流规则：5许可/秒，支持最大5个突发请求
static {
    API_LIMITER_MAP.put("/your-target-api", RateLimiter.create(5.0));
}

2. 在Filter中正确处理许可获取 #

在OncePerRequestFilter的核心逻辑里，针对目标API调用无参数的tryAcquire()（立即尝试获取许可，不等待），这样突发请求能直接拿到积累的许可：

@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
    String uri = request.getRequestURI();
    
    // 先执行全局限流、IP维度限流（保留你原有逻辑）
    if (!passGlobalLimit() || !passIpLimit(request)) {
        response.setStatus(HttpStatus.TOO_MANY_REQUESTS.value());
        return;
    }
    
    // 处理目标API的专属限流
    RateLimiter limiter = API_LIMITER_MAP.get(uri);
    if (limiter != null && !limiter.tryAcquire()) {
        response.setStatus(HttpStatus.TOO_MANY_REQUESTS.value());
        return;
    }
    
    filterChain.doFilter(request, response);
}

3. 自定义突发能力（可选） #

如果需要更大的突发空间（比如允许10个请求一次性通过），可以在创建RateLimiter时指定最大突发秒数：

// 允许积累2秒的许可，即最多10个突发请求
RateLimiter.create(5.0, 2, TimeUnit.SECONDS);

避坑指南 #

• 绝对不要用SmoothWarmingUp模式（即带预热参数的RateLimiter.create），这种模式会逐步提升发放速率，完全不支持突发请求。
• 禁止每次请求都新建RateLimiter实例，否则限流逻辑完全失效，每个请求都能通过。
• 确保RateLimiter实例是线程安全的：ConcurrentHashMap存储的实例天然支持多线程并发调用，无需额外同步。

内容的提问来源于stack exchange，提问作者kheptan