Java中的速率限制：如何保护API免受过载和机器人攻击

Java中的速率限制与节流：从理论到实战代码

想象一下：您新开发的Java微服务刚刚上线，突然遭遇了请求洪流。不是恶意攻击，只是某个粗心的客户端忘记在脚本中设置延迟。结果：数据库崩溃，服务器不堪重负，而用户（包括那些守规矩的）收到了502 Bad Gateway错误。熟悉吗？

今天我们来讨论如何避免这种情况。我们的话题是——Java中的速率限制与节流。这不仅仅是DevOps领域的时髦术语，而是任何公共API的第一道防线。我们将分析“速率限制”与“节流”的区别，探讨流行的算法，最重要的是，编写真实的代码。

如果您使用Java开发，并希望您的服务在任何负载下都能保持正常运行，那么您来对地方了。开始吧！

速率限制 vs 节流：有什么区别？

这两个概念经常被混淆，尽管它们解决的是不同但相关的任务。

• 速率限制 —— 这是一个严格的屏障。“每个IP每秒不超过10个请求”。超出限制？返回429 Too Many Requests。公平合理。
• 节流 —— 这是一种更温和的机制。服务不会阻塞请求，而是减慢其处理速度。例如，您将请求放入队列，并以固定速度处理它们。

在实际项目中，Java中的节流通常通过具有有限吞吐量的线程池（ThreadPoolExecutor）来实现，而速率限制则通过计数器、缓存和中间过滤器来实现。

速率限制算法：选择您的武器

在编写代码之前，让我们先选择策略。以下是Java请求限制的三种最流行的算法。

1. 令牌桶

经典算法。我们有一个“桶”，每秒向其中滴入N个新令牌。要执行请求，需要取走一个令牌。如果桶空了，请求被拒绝。该算法能很好地处理突发流量，允许“预支”令牌（不超过桶的容量）。

2. 滑动窗口

更精确的方法。我们不计算日历秒内的请求，而是滑动时间窗口。例如，“过去60秒内不超过100个请求”。这可以防止每个时间间隔开始时的“突发”。

3. 固定窗口

最简单但危险的方法。每N秒重置一次计数器。问题：在窗口结束时可以发送一千个请求，在下一个窗口开始时又可以发送一千个。不适用于关键系统。

我们将重点放在前两种算法上——它们在性能和精度之间提供了最佳平衡。

编写代码：亲手实现速率限制器

让我们使用令牌桶算法实现一个Java速率限制器。这是一个很好的例子，可以帮助理解限制系统内部的工作原理。

import java.util.concurrent.ConcurrentHashMap;import java.util.concurrent.TimeUnit;import java.util.concurrent.atomic.AtomicLong;

public class TokenBucketRateLimiter {

    private final long maxTokens;         // 桶的最大容量    private final long refillRate;        // 每秒补充的令牌数    private final ConcurrentHashMap<String, Bucket> buckets = new ConcurrentHashMap<>();

    public TokenBucketRateLimiter(long maxTokens, long refillRate) {        this.maxTokens = maxTokens;        this.refillRate = refillRate;    }

    public boolean tryAcquire(String clientId) {        Bucket bucket = buckets.computeIfAbsent(clientId, k -> new Bucket(maxTokens));        return bucket.tryConsume();    }

    private class Bucket {        private final AtomicLong tokens;        private volatile long lastRefillTimestamp;

        Bucket(long cap