限流的常见算法有固定窗口计数器、滑动窗口计数器、漏桶算法和令牌桶算法。1. 固定窗口计数器通过设定固定时间周期内的请求数限制实现限流，但存在窗口边缘效应；2. 滑动窗口计数器维护动态时间窗口，统计过去一段时间内的请求，更精确但实现复杂；3. 漏桶算法以恒定速率处理请求，能平滑流量但无法应对突发流量；4. 令牌桶算法以恒定速率生成令牌，允许突发流量处理，更为灵活。这些算法可根据实际需求选择使用。
在Java中设置请求频率限制，核心在于跟踪特定时间窗口内的请求数量，并根据预设的阈值决定是否允许新请求通过。对于单体应用，这通常可以借助现成的并发工具库实现；而在分布式系统中，则需要一个共享的状态存储来协调多个实例的计数。基本思路都是在请求到达业务逻辑前进行拦截判断，超出限制则拒绝或排队。
在Java中实现访问速率控制，我们通常会围绕几种核心模式来构建。最直接也最容易理解的，可能就是固定窗口计数器（Fixed Window Counter）或者滑动窗口计数器（Sliding Window Counter）。但如果追求更平滑的流量控制和更好的资源利用率，令牌桶（Token Bucket）或漏桶（Leaky Bucket）算法会是更优雅的选择。
以一个简单的令牌桶为例，想象你有一个桶，里面不断有“令牌”以恒定速率生成。每次有请求进来，它都需要从桶里取走一个令牌才能被处理。如果桶里没有令牌了，请求就得等待，或者直接被拒绝。Guava库的RateLimiter就是这种思想的优秀实现，它提供了一种非常便捷的方式来做单机限流。
立即学习“Java免费学习笔记（深入）”；
import com.google.common.util.concurrent.RateLimiter;
public class ApiRateLimiter {
// 每秒允许10个请求
private final RateLimiter rateLimiter = RateLimiter.create(10.0);
public boolean tryAcquire() {
// 尝试获取一个令牌，如果立即获取不到则返回false
return rateLimiter.tryAcquire();
// 或者：rateLimiter.acquire(); // 会阻塞直到获取到令牌
}
public void processRequest() {
if (tryAcquire()) {
System.out.println(Thread.currentThread().getName() + " - 请求被允许，处理中...");
// 模拟业务处理
try {
Thread.sleep(50);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
} else {
System.out.println(Thread.currentThread().getName() + " - 请求被拒绝，超出频率限制！");
// 可以抛出异常，返回特定错误码等
}
}
public static void main(String[] args) throws InterruptedException {
ApiRateLimiter limiter = new ApiRateLimiter();
for (int i = 0; i < 20; i++) {
new Thread(() -> limiter.processRequest(), "Thread-" + i).start();
// 稍微停顿一下，模拟请求间隔
if (i % 5 == 0) {
Thread.sleep(100);
}
}
}
}这段代码展示了Guava RateLimiter的基本用法。RateLimiter.create(10.0)表示每秒生成10个令牌。tryAcquire()是非阻塞的，如果无法立即获取令牌就返回false，这对于需要快速响应的API非常有用。而acquire()则会阻塞当前线程直到获取到令牌，这适用于对延迟不那么敏感但需要确保请求最终被处理的场景。
当然，这只是单机限流。在实际的微服务架构里，单机限流往往不够，我们需要考虑分布式环境下的限流。这通常意味着你需要一个共享的状态存储，比如Redis。利用Redis的INCR命令结合过期时间（EXPIRE）可以实现一个简单的滑动窗口计数器，或者用Lua脚本来实现更复杂的令牌桶逻辑，确保操作的原子性。
谈到限流，脑子里自然会浮现几种经典算法，它们各有优劣，适用场景也不同。
固定窗口计数器（Fixed Window Counter）：这是最直观的。比如，每分钟100次请求。一个计时周期内，请求数达到上限就拒绝。简单粗暴，实现起来也容易，用一个计数器加一个定时器清零就行。但它的问题在于“窗口边缘效应”：如果很多人在窗口结束前一秒和新窗口开始后一秒集中请求，总请求量可能远超预期，形成瞬时高峰。这就像你把一小时的流量都挤在两分钟里用完。
滑动窗口计数器（Sliding Window Counter）：为了解决固定窗口的边缘效应，滑动窗口就显得更聪明了。它不再是固定的时间片，而是维护一个动态的窗口。比如，统计过去一分钟的请求数。这通常通过维护一个有序的请求时间戳列表来实现，每次请求进来就加入列表，并移除掉超出窗口时间的旧请求。这能提供更平滑的限流效果，但实现起来复杂度相对高一点，尤其是在分布式环境下，需要协调多个节点的计数。Redis的ZSET（有序集合）就很适合用来实现这个。
漏桶算法（Leaky Bucket）：这个算法的形象比喻非常贴切：一个水桶，水（请求）以不规则的速率流入，但水桶底部有个小孔，水（处理请求）以恒定速率流出。如果流入速度过快，水桶满了，那么新来的水就溢出（请求被拒绝）。它的优点是能平滑输出流量，强制请求以固定速率处理，对于后端服务稳定性很有帮助。缺点是，它无法处理突发流量，因为出口速率是固定的。
令牌桶算法（Token Bucket）：我个人更偏爱令牌桶，因为它更灵活。前面提到过，令牌以恒定速率放入桶中，请求需要令牌才能被处理。如果桶里有令牌，请求可以立即被处理，这使得它能处理一定的突发流量（桶里预存的令牌就是应对突发的“信用额度”）。如果桶空了，请求就得等待或被拒绝。Guava的RateLimiter就是令牌桶的变种，它不仅能控制速率，还能应对突发，并且支持“预消费”令牌，这在某些场景下非常有用。
选择哪种算法，真的得看你的具体需求：是追求简单实现、严格控制瞬时峰值，还是需要应对突发、平滑流量？没有银弹，只有最适合的。
在分布式环境下，限流就不是简单一个RateLimiter实例能搞定的事了。因为你的请求可能打到集群中的任何一台服务器上，每台服务器单独计数是没意义的。这时候，一个中心化的计数或协调机制就变得必不可少。
我见过也实践过几种方案：
基于Redis的限流：这是最常见也最可靠的方案之一。Redis的原子操作（如INCR、EXPIRE）是实现分布式限流的利器。
INCR操作，并设置过期时间。如果INCR后的值超过了阈值，就拒绝请求。这种方式简单，但同样面临固定窗口的边缘效应。当前时间 - 窗口大小的元素。最后统计ZSET中元素的数量。这种方式更精确，但每次操作涉及ZSET的增删查，性能开销会比简单计数器大一些。消息队列（MQ）削峰填谷：虽然不是严格意义上的“限流算法”，但将请求先放入消息队列，然后后端服务以恒定速率从队列中消费，这本身就是一种非常有效的“削峰填谷”策略。它能有效保护后端服务不被瞬时高并发压垮，但缺点是增加了请求的延迟。对于一些异步处理的业务，这是个不错的选择。
API网关层限流：在微服务架构中，API网关（如Spring Cloud Gateway, Zuul, Nginx, Kong）是请求的入口。在这里做限流非常自然，因为它能统一管理所有服务的流量。许多网关都内置了限流插件，或者可以通过集成外部限流组件（如Sentinel、RateLimiter-RxJava）来实现。这种方式的好处是，限流逻辑与业务逻辑解耦，而且可以在请求到达后端服务之前就进行拦截，保护整个系统。
分布式限流的核心挑战在于一致性和性能。选择方案时，需要权衡这些因素。我个人倾向于在API网关层做第一道粗粒度的限流，然后在关键业务服务内部再做细粒度的、基于Redis的限流，形成一个多层次的防御体系。
限流这事儿，光有算法和分布式方案还不够，粒度和动态性也是非常关键的考量点。
选择合适的粒度，需要深入理解业务场景和潜在的风险点。过度细化会增加限流规则的管理成本和系统开销，而过于粗放则可能导致某些关键资源被滥用。我的经验是，从最容易出问题的点开始，逐步细化。比如，先做API级别的限流，如果发现某个API下的某个用户行为异常，再考虑用户级别或IP级别的限流。
以上就是如何在Java中设置请求频率限制 Java实现访问速率控制逻辑的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
183
收藏
