基本API速率限制

您可能正在开发某种形式的（Web / RESTful）API，并且如果它是面向公众的（甚至是内部的），通常您希望以某种方式对其进行速率限制。即，限制一段时间内执行的请求数，以节省资源并防止滥用。

这可能可以通过一些聪明的配置在Web服务器/负载均衡器级别上实现，但是通常您希望速率限制器是特定于客户端的（即，API的每个客户端都应具有单独的速率限制），以及客户端的方式被确定是不同的。可能仍然可以在负载均衡器上执行此操作，但是我认为将其放在应用程序级别上是有意义的。

我将使用spring-mvc作为示例，但是任何Web框架都有插入拦截器的好方法。

因此，这是一个spring-mvc拦截器的示例：

@Component
public class RateLimitingInterceptor extends HandlerInterceptorAdapter {private static final Logger logger = LoggerFactory.getLogger(RateLimitingInterceptor.class);@Value("${rate.limit.enabled}")private boolean enabled;@Value("${rate.limit.hourly.limit}")private int hourlyLimit;private Map<String, Optional<SimpleRateLimiter>> limiters = new ConcurrentHashMap<>();@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)throws Exception {if (!enabled) {return true;}String clientId = request.getHeader("Client-Id");// let non-API requests passif (clientId == null) {return true;}SimpleRateLimiter rateLimiter = getRateLimiter(clientId);boolean allowRequest = limiter.tryAcquire();if (!allowRequest) {response.setStatus(HttpStatus.TOO_MANY_REQUESTS.value());}response.addHeader("X-RateLimit-Limit", String.valueOf(hourlyLimit));return allowRequest;}private SimpleRateLimiter getRateLimiter(String clientId) {if (limiters.containsKey(clientId)) {return limiters.get(clientId);} else {synchronized(clientId.intern()) {// double-checked locking to avoid multiple-reinitializationsif (limiters.containsKey(clientId)) {return limiters.get(clientId);}SimpleRateLimiter rateLimiter = createRateLimiter(clientId);limiters.put(clientId, rateLimiter);return rateLimiter;}}}@PreDestroypublic void destroy() {// loop and finalize all limiters}
}

这将按需初始化每个客户端的速率限制器。另外，在启动时，您可以遍历所有已注册的API客户端，并为每个客户端创建一个速率限制器。如果速率限制器不允许更多请求（tryAcquire（）返回false），则取消“ Too many requests”（太多请求）并中止请求的执行（从拦截器返回“ false”）。

这听起来很简单。但是有一些问题。您可能想知道上面的SimpleRateLimiter在哪里定义。我们将到达那里，但首先让我们看看我们对速率限制器实现有哪些选择。

最受欢迎的似乎是番石榴RateLimiter 。它具有简单的工厂方法，可为您提供指定速率（每秒允许）的速率限制器。但是，它不能很好地适应Web API，因为您无法使用预先存在的许可数量初始化RateLimiter。这意味着在限制器允许请求之前，应经过一段时间。还有另一个问题–如果您每秒的许可数量少于一个（例如，如果您希望的速率限制为“每小时200个请求”），则可以传递一个分数（hourlyLimit / secondsInHour），但仍然无法达到您的目的可以预期，因为内部有一个“ maxPermits”字段，可以将许可证数量的上限限制为比您想要的要少得多。此外，速率限制器不允许突发-您每秒恰好有X个许可，但您不能长时间分散它们，例如在一秒钟内有5个请求，然后在接下来的几秒钟内没有请求。实际上，上述所有问题都可以解决，但遗憾的是，可以通过您无法访问的隐藏字段来解决。多年来存在多个功能请求，但是Guava不会更新速率限制器，从而使其不适用于API速率限制。

使用反射，您可以调整参数并使限制器工作。但是，这很丑陋，并且不能保证它会按预期工作。我在这里展示了如何使用每小时X许可，爆破性和完整的初始许可来初始化番石榴速率限制器。当我认为这样做的时候，我看到tryAcquire()有一块tryAcquire() synchronized(..)块。这是否意味着在简单地检查是否允许发出请求时，所有请求都会彼此等待？那太可怕了。

因此，实际上番石榴RateLimiter并不旨在用于（网络）API速率限制。也许保持功能贫乏是Guava劝阻人们不要滥用它的方法吗？

这就是为什么我决定根据Java信号量自己实现一些简单的事情。这是朴素的实现：

public class SimpleRateLimiter {private Semaphore semaphore;private int maxPermits;private TimeUnit timePeriod;private ScheduledExecutorService scheduler;public static SimpleRateLimiter create(int permits, TimeUnit timePeriod) {SimpleRateLimiter limiter = new SimpleRateLimiter(permits, timePeriod);limiter.schedulePermitReplenishment();return limiter;}private SimpleRateLimiter(int permits, TimeUnit timePeriod) {this.semaphore = new Semaphore(permits);this.maxPermits = permits;this.timePeriod = timePeriod;}public boolean tryAcquire() {return semaphore.tryAcquire();}public void stop() {scheduler.shutdownNow();}public void schedulePermitReplenishment() {scheduler = Executors.newScheduledThreadPool(1);scheduler.schedule(() -> {semaphore.release(maxPermits - semaphore.availablePermits());}, 1, timePeriod);}
}

它需要一定数量的许可（允许的请求数量）和一段时间。时间段为“ 1 X”，其中X可以是每秒/分钟/小时/每天-取决于您希望如何配置限制-每秒，每分钟，每小时，每天。调度程序每1 X补充所获得的许可证。无法控制突发事件（客户端可以用快速连续的请求来花费所有许可），没有热身功能，没有逐步的补充。根据您的需要，这可能并不理想，但这只是一个基本的速率限制器，它是线程安全的，没有任何阻塞。我编写了一个单元测试，以确认限制器的行为正确，并且还对本地应用程序进行了性能测试，以确保遵守限制。到目前为止，它似乎正在工作。

有其他选择吗？好吧，是的–像RateLimitJ这样的库使用Redis来实现速率限制。但是，这意味着您需要设置和运行Redis。对于“简单地”进行限速似乎是开销。

另一方面，限速将如何在一组应用程序节点中正常工作？应用程序节点可能需要一些数据库或八卦协议来共享有关剩余的每个客户端许可（请求）的数据？不必要。解决此问题的一种非常简单的方法是假设负载平衡器在节点之间平均分配负载。这样，您只需要将每个节点上的限制设置为等于总限制除以节点数即可。它不是很精确，但是您很少需要做到这一点–允许5-10个以上的请求不会终止您的应用程序，允许5-10个以下的请求对用户来说并不算太大。

但是，那将意味着您必须知道应用程序节点的数量。如果您使用自动缩放（例如在AWS中），则节点数可能会根据负载而变化。在这种情况下，通过调用AWS（或其他云提供商）API来获取节点中的节点数，而不是配置硬编码的许可数，补给排定的作业可以即时计算“ maxPermits”。当前的自动缩放组。这比仅支持Redis部署要简单得多。

总的来说，我很惊讶没有一种“规范的”方式来实现速率限制（在Java中）。也许限制速率的需求并不像看起来那样普遍。或者，它是手动实施的-通过暂时禁止使用“资源过多”的API客户端。