1. 理解分布式限流与挑战
在构建高并发、高可用性的现代应用时，限流（Rate Limiting）是不可或缺的一环。它能够保护后端服务免受过载，防止恶意攻击，并确保系统资源的公平分配。对于分布式系统而言，限流的挑战在于如何跨多个实例同步和管理限流状态。Redis因其高性能和原子操作特性，成为实现分布式限流的理想选择。
常见的限流算法包括漏桶（Leaky Bucket）和令牌桶（Token Bucket）。令牌桶算法因其允许一定程度的突发流量而更受青睐。本文将围绕令牌桶算法，并结合“滚动窗口”的概念来构建限流器。
核心需求点：
- 滚动窗口（Rolling Window）：限制在过去某个时间窗口内的请求数量，而非固定时间段。虽然令牌桶本身是基于速率和容量的，但通过巧妙配置，可以模拟出滚动窗口的行为。
- 回退机制（Back-off / Retry-After）：当请求因限流而被拒绝时，能够返回一个建议的等待时间，指导客户端何时可以重试，从而避免客户端无意义的重试风暴。
2. 为什么选择Bucket4j？
在Java生态中，有多种限流库和实现方式。例如，一些基于Redis的Lua脚本实现，或像Redisson这样的综合性框架。然而，对于本文所关注的“滚动窗口”和“回退时间”这两个核心需求，Bucket4j库提供了非常强大和灵活的支持。
立即学习“Java免费学习笔记（深入）”；
Bucket4j是一个Java的令牌桶限流库，它支持多种持久化方式，包括内存、JCache、Redis等。其强大的API能够提供详细的限流结果，包括剩余令牌数和下次可重试的时间。
初学者可能会误解Bucket4j不提供回退时间，但实际上，它通过 ConsumptionProbe 对象提供了非常详细的诊断信息，其中包括 getNanosToWaitForRefill() 方法，这正是我们所需的回退时间。
3. Bucket4j实现滚动窗口限流
虽然Bucket4j是令牌桶算法的实现，但其“令牌填充速率”和“桶容量”的组合，可以有效地模拟出对“滚动窗口”的限制效果。例如，一个每秒填充10个令牌，容量为100个令牌的桶，意味着在过去一段时间内，平均每秒最多处理10个请求，且在短时间内最多允许100个请求的突发。
以下是一个基于Redis和Bucket4j实现分布式限流的示例。我们将使用Jedis作为Redis客户端的集成。
3.1 引入依赖
首先，在pom.xml中添加Bucket4j及其Jedis集成依赖：
com.github.vladimir-bukhtoyarov bucket4j-core 8.1.1 com.github.vladimir-bukhtoyarov bucket4j-redis 8.1.1 redis.clients jedis 4.3.1
3.2 配置和初始化限流器
接下来，我们将配置一个基于Redis的限流器。这里我们创建一个每秒允许10个请求，最大突发容量为20个请求的限流器。
import io.github.bucket4j.Bandwidth;
import io.github.bucket4j.Bucket;
import io.github.bucket4j.Bucket4j;
import io.github.bucket4j.ConsumptionProbe;
import io.github.bucket4j.redis.jedis.JedisBasedProxyManager;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;
import java.time.Duration;
import java.util.concurrent.TimeUnit;
import java.util.function.Supplier;
public class DistributedRateLimiter {
private static JedisPool jedisPool;
private static JedisBasedProxyManager proxyManager;
public static void initRedis(String redisHost, int redisPort) {
JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxTotal(10); // 最大连接数
poolConfig.setMaxIdle(5); // 最大空闲连接数
jedisPool = new JedisPool(poolConfig, redisHost, redisPort);
proxyManager = new JedisBasedProxyManager(jedisPool);
}
/**
* 获取或创建限流桶。
* 每个唯一的key对应一个独立的限流桶。
*
* @param key 限流的唯一标识符（例如：用户ID, IP地址, API路径）
* @param capacity 令牌桶容量
* @param refillTokens 每次填充的令牌数
* @param refillPeriod 令牌填充周期
* @return 配置好的限流桶
*/
public static Bucket getOrCreateLimiterBucket(String key, long capacity, long refillTokens, Duration refillPeriod) {
// 定义限流带宽
Bandwidth limit = Bandwidth.builder()
.capacity(capacity) // 令牌桶容量
.refillGreedy(refillTokens, refillPeriod) // 令牌填充策略：每 refillPeriod 填充 refillTokens 个令牌
.build();
// 使用proxyManager获取或创建分布式桶
// key是限流器的唯一标识，Supplier是当key不存在时如何创建桶的定义
return Bucket4j.builder()
.addLimit(limit)
.build(proxyManager, key);
}
public static void main(String[] args) throws InterruptedException {
// 初始化Redis连接池
initRedis("localhost", 6379); // 假设Redis运行在本地默认端口
String userId = "user:123";
// 为该用户设置限流：每秒10个请求，最大突发20个请求
Bucket userBucket = getOrCreateLimiterBucket(userId, 20, 10, Duration.ofSeconds(1));
System.out.println("--- 模拟用户请求 ---");
for (int i = 0; i < 30; i++) {
// 尝试消费一个令牌
ConsumptionProbe probe = userBucket.tryConsumeAndReturnRemaining(1);
if (probe.isConsumed()) {
// 请求成功
System.out.printf("请求 %d 成功！剩余令牌：%d%n", i + 1, probe.getRemainingTokens());
} else {
// 请求被拒绝
long nanosToWaitForRefill = probe.getNanosToWaitForRefill();
long millisToWaitForRefill = TimeUnit.NANOSECONDS.toMillis(nanosToWaitForRefill);
System.err.printf("请求 %d 被拒绝！需要等待 %d 毫秒后重试。当前剩余令牌：%d%n",
i + 1, millisToWaitForRefill, probe.getRemainingTokens());
// 模拟客户端等待回退时间
if (millisToWaitForRefill > 0) {
Thread.sleep(millisToWaitForRefill);
}
}
// 每次请求间隔模拟
Thread.sleep(50);
}
// 关闭Redis连接池
jedisPool.close();
}
}3.3 代码解析与回退机制
- initRedis(String redisHost, int redisPort): 初始化Jedis连接池和JedisBasedProxyManager。ProxyManager是Bucket4j与底层存储（这里是Redis）交互的抽象层。
-
getOrCreateLimiterBucket(String key, ...):
- Bandwidth limit = Bandwidth.builder().capacity(capacity).refillGreedy(refillTokens, refillPeriod).build();：定义了限流的规则。
- capacity(capacity)：设置令牌桶的最大容量。
- refillGreedy(refillTokens, refillPeriod)：定义了令牌的填充策略。例如，refillGreedy(10, Duration.ofSeconds(1)) 表示每秒会向桶中添加10个令牌。
- Bucket4j.builder().addLimit(limit).build(proxyManager, key);：这是关键一步。它使用proxyManager来为给定的key获取或创建一个分布式共享的限流桶。如果桶不存在，它会使用addLimit定义的规则来创建。
- Bandwidth limit = Bandwidth.builder().capacity(capacity).refillGreedy(refillTokens, refillPeriod).build();：定义了限流的规则。
-
userBucket.tryConsumeAndReturnRemaining(1): 尝试从桶中消费1个令牌。
- 这个方法返回一个ConsumptionProbe对象，这是Bucket4j提供详细诊断信息的关键。
-
probe.isConsumed(): 判断令牌是否成功消费。
- 如果为true，表示请求被允许。probe.getRemainingTokens() 可以获取当前桶中剩余的令牌数。
- 如果为false，表示请求被拒绝。
- probe.getNanosToWaitForRefill()：这就是我们所需的回退时间！它返回的是以纳秒为单位的，直到有足够令牌可供消费所需的等待时间。我们可以将其转换为毫秒或秒，并告知客户端。
- probe.getRemainingTokens()：在这种情况下，通常是负值，表示请求被拒绝。
通过模拟客户端在请求被拒绝后等待millisToWaitForRefill，我们实现了有效的回退机制，避免了无效的重试，保护了服务。
4. 注意事项与最佳实践
- 限流粒度：根据业务需求选择合适的key来定义限流粒度，可以是用户ID、IP地址、API端点、组合键等。
- 异常处理：在实际应用中，需要对Redis连接异常、网络中断等情况进行适当的异常处理。
- 性能考量：虽然Redis性能很高，但频繁的读写操作仍然会带来一定的网络开销。合理设置令牌桶容量和填充速率，避免过于频繁的Redis操作。
- 多重限流规则：Bucket4j支持为同一个桶定义多个Bandwidth规则，例如，可以同时设置每秒限流和每分钟限流。
- 监控与告警：将限流器的运行状态（如拒绝率、平均等待时间）纳入监控系统，并设置告警，以便及时发现和处理问题。
- 客户端配合：限流器的回退机制需要客户端的积极配合。客户端收到Retry-After信息后，应遵循该指示进行等待，而非立即重试。对于HTTP API，通常会在响应头中添加X-Rate-Limit-Retry-After-Seconds或Retry-After。
5. 总结
本文详细介绍了如何在Java中使用Bucket4j和Redis构建一个强大的分布式限流器，重点解决了如何实现类似“滚动窗口”的行为以及获取“回退时间”的需求。Bucket4j的ConsumptionProbe机制提供了丰富的信息，使得实现智能的限流策略和友好的客户端交互成为可能。通过合理配置和应用，开发者可以有效保护系统，提升服务稳定性。
