shigen坚持更新文章的博客写手，记录成长，分享认知，留住感动。个人IP：shigen
背景
接口的限流相信大家并不陌生，如果服务不做好限流的话，极容易造成网络、内存、磁盘等等性能的波动，重则出现服务被流量打挂的场景，服务的限流更多的是主动的防御。那么服务调用三方的接口不限流的话，就容易造成三方服务的大面积报错。最近在阅读同事的代码时候，就遇到了这样的一个问题：在for循环中调用第三方接口：
for (int i=0;i< ids.length(); i++) {
callApi(args);
}
最后查看日志，三方接口疯狂的抛出错误：
too many requests!
先来说下我是怎么解决的。批量调用三方的API场景是捞取数据库中某个字段为空的记录，然后去调用三方的接口，解析接口返回的字段，更新DB。因为这些数据是需要我们在开发环境和预发环境提前准备好的，所以不会考虑到生产环境的并发。没错，解决起来也是很简单的。
查看了文档，发现官方的描述是这样的：
As a free api, only allows one request peer secord.
意思也就是qps是1。或许搞惯了高并发的，觉得qps是1就很low，但是免费的才是最贵的这句话不是没有道理的。
于是果断的修改了下代码，在原来的代码中加上这样的逻辑：
for (int i=0;i< ids.length(); i++) {
Thread.sleep(1000);
callApi(args);
}
让每个线程的执行时间间隔1s。再重新部署代码，调度下来，虽然执行的慢了许多，但是基本上调用三方接口没有再出现请求次数过多的错误了。
优化
似乎以上的方式就能很好的解决这个问题，但是稍微再往深处想一下，如果是多线程的调用、如果是集群的并发调用怎么办。在这里，我们把这两种场景分开讨论。
多线程实现
简单的Thread.sleep()貌似确实可以解决问题，但是我们也得看下它的弊端：
- 会阻塞当前的线程，不适合高并发的场景，会占用系统的资源
- 不是很灵活
- 最重要的是并发场景下，根本起不到流控的作用
我们写个多线程的代码看下：
private static void MethodOne() {
for (int i = 0; i < CALL_TIMES; i++) {
int finalI = i;
new Thread(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
callApi(finalI);
log.info("exec subThread other task....");
}).start();
}
}
代码很简单，就是在for循环中起多线程然后去调用接口。来看下实际的调用结果：
可以看出这里并发情况下，并没有做好流控。
Google的Guava RateLimiter就更的解决这个问题，先看下代码：
// permitsPerSecond 一秒钟一个请求
static RateLimiter limiter = RateLimiter.create(1);
private static void MethodTwo() {
for (int i = 0; i < CALL_TIMES; i++) {
int finalI = i;
new Thread(() -> {
limiter.acquire();
callApi(finalI);
log.info("exec subThread other task....");
}).start();
}
}
这里就是用到了guava的com.google.common.util.concurrent.RateLimiter,实现的类似令牌桶的算法（相关的流控算法可参考文章：常见的限流算法- python版本)。查看日志，符合我们想要的流控效果：
这个令牌是基于JVM层面的，和JUC包下的各种锁一样。
分布式环境
上边已经提交到了google的Guava是基于JVM层面的，那么在分布式环境下，这些就都不适用了。这里我能想到的就是Redis，天然的分布式资源解决方案。相关的文章其实很早之前就有过分享了，可以查看原文：如何优雅地实现接口防刷。
其实核心就是这个全局的拦截器：
当然，对于Redis的操作并不是原子性的，这里可以有一个优化点：使用LUA脚本。
好了，以上就是今天的全部内容了，与shigen一起，每天不一样！
