关于分布式服务限流的一些思考

限流必然是很有价值的，在系统资源不足时面对外部世界的不确定性（突发流量，超预期的用户）而形成的一种自我保护机制。但是价值感是很低的，因为99.99%的时候系统总是工作在安全线之下，甚至一年到头都碰不到一次撞线的机会。这就好比法律，它始终存在，但是大部分时候对于大多数人它几乎不存在，或者说感知不到它的存在。

一、限流的作用

由于API接口无法控制调用方的行为，因此当遇到瞬时请求量激增时，会导致接口占用过多服务器资源，使得其他请求响应速度降低或是超时，更有甚者可能导致服务器宕机。

限流(Rate limiting)指对应用服务的请求进行限制，例如某一接口的请求限制为100个每秒,对超过限制的请求则进行快速失败或丢弃。

限流可以应对：

热点业务带来的突发请求；
调用方bug导致的突发请求；
恶意攻击请求。

因此，对于公开的接口最好采取限流措施。

二、为什么要分布式限流

当应用为单点应用时，只要应用进行了限流，那么应用所依赖的各种服务也都得到了保护。

但线上业务出于各种原因考虑，多是分布式系统，单节点的限流仅能保护自身节点，但无法保护应用依赖的各种服务，并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。

而如果实现了分布式限流，那么就可以方便地控制整个服务集群的请求限制，且由于整个集群的请求数量得到了限制，因此服务依赖的各种资源也得到了限流的保护。

三、限流的算法

实现限流有很多办法，在程序中时通常是根据每秒处理的事务数(Transaction per second)来衡量接口的流量。

本文介绍几种最常用的限流算法：

固定窗口计数器；
滑动窗口计数器；
漏桶；
令牌桶。

1、固定窗口计数器算法

固定窗口计数器算法概念如下：

将时间划分为多个窗口；
在每个窗口内每有一次请求就将计数器加一；
如果计数器超过了限制数量，则本窗口内所有的请求都被丢弃当时间到达下一个窗口时，计数器重置。

固定窗口计数器是最为简单的算法，但这个算法有时会让通过请求量允许为限制的两倍。考虑如下情况：限制1秒内最多通过5个请求，在第一个窗口的最后半秒内通过了5个请求，第二个窗口的前半秒内又通过了5个请求。这样看来就是在1秒内通过了10个请求。

2、滑动窗口计数器算法

滑动窗口计数器算法概念如下：

将时间划分为多个区间；
在每个区间内每有一次请求就将计数器加一维持一个时间窗口，占据多个区间；
每经过一个区间的时间，则抛弃最老的一个区间，并纳入最新的一个区间；
如果当前窗口内区间的请求计数总和超过了限制数量，则本窗口内所有的请求都被丢弃。

滑动窗口计数器是通过将窗口再细分，并且按照时间"滑动"，这种算法避免了固定窗口计数器带来的双倍突发请求，但时间区间的精度越高，算法所需的空间容量就越大。

3、漏桶算法

漏桶算法概念如下：

将每个请求视作"水滴"放入"漏桶"进行存储；
"漏桶"以固定速率向外"漏"出请求来执行如果"漏桶"空了则停止"漏水"；
如果"漏桶"满了则多余的"水滴"会被直接丢弃。

漏桶算法多使用队列实现，服务的请求会存到队列中，服务的提供方则按照固定的速率从队列中取出请求并执行，过多的请求则放在队列中排队或直接拒绝。

漏桶算法的缺陷也很明显，当短时间内有大量的突发请求时，即便此时服务器没有任何负载，每个请求也都得在队列中等待一段时间才能被响应。

4、令牌桶算法

令牌桶算法概念如下：

令牌以固定速率生成；
生成的令牌放入令牌桶中存放，如果令牌桶满了则多余的令牌会直接丢弃，当请求到达时，会尝试从令牌桶中取令牌，取到了令牌的请求可以执行；
如果桶空了，那么尝试取令牌的请求会被直接丢弃。

令牌桶算法既能够将所有的请求平均分布到时间区间内，又能接受服务器能够承受范围内的突发请求，因此是目前使用较为广泛的一种限流算法。

四、代码实现

作为如此重要的功能，在Java中自然有很多实现限流的类库，例如Google的开源项目guava提供了RateLimiter类，实现了单点的令牌桶限流。

而分布式限流常用的则有Hystrix、resilience4j、Sentinel等框架，但这些框架都需引入第三方的类库，对于国企等一些保守的企业，引入外部类库都需要经过层层审批，较为麻烦。

分布式限流本质上是一个集群并发问题，而Redis作为一个应用广泛的中间件，又拥有单进程单线程的特性，天然可以解决分布式集群的并发问题。本文简单介绍一个通过Redis实现单次请求判断限流的功能。

1、脚本编写

经过上面的对比，最适合的限流算法就是令牌桶算法。而为实现限流算法，需要反复调用Redis查询与计算，一次限流判断需要多次请求较为耗时。因此我们采用编写Lua脚本运行的方式，将运算过程放在Redis端，使得对Redis进行一次请求就能完成限流的判断。

令牌桶算法需要在Redis中存储桶的大小、当前令牌数量，并且实现每隔一段时间添加新的令牌。最简单的办法当然是每隔一段时间请求一次Redis，将存储的令牌数量递增。

但实际上我们可以通过对限流两次请求之间的时间和令牌添加速度来计算得出上次请求之后到本次请求时，令牌桶应添加的令牌数量。因此我们在Redis中只需要存储上次请求的时间和令牌桶中的令牌数量，而桶的大小和令牌的添加速度可以通过参数传入实现动态修改。

由于第一次运行脚本时默认令牌桶是满的，因此可以将数据的过期时间设置为令牌桶恢复到满所需的时间，及时释放资源。

编写完成的Lua脚本如下：

local ratelimit_info = redis.pcall('HMGET',KEYS[1],'last_time','current_token')

local last_time = ratelimit_info[1]

local current_token = tonumber(ratelimit_info[2])

local max_token = tonumber(ARGV[1])

local token_rate = tonumber(ARGV[2])

local current_time = tonumber(ARGV[3])

local reverse_time = 1000/token_rate

if current_token == nil then

  current_token = max_token

  last_time = current_time

else

  local past_time = current_time-last_time

  local reverse_token = math.floor(past_time/reverse_time)

  current_token = current_token+reverse_token

  last_time = reverse_time*reverse_token+last_time

  if current_token>max_token then

    current_token = max_token

  end

end

local result = 0

if(current_token>0) then

  result = 1

  current_token = current_token-1

end 

redis.call('HMSET',KEYS[1],'last_time',last_time,'current_token',current_token)

redis.call('pexpire',KEYS[1],math.ceil(reverse_time*(max_token-current_token)+(current_time-last_time)))

return result

2、执行限流

这里使用Spring Data Redis来进行Redis脚本的调用。

编写Redis脚本类:

public class RedisReteLimitScript implements RedisScript<String> { 

   private static final String SCRIPT = 

      "local ratelimit_info = redis.pcall('HMGET',KEYS[1],'last_time','current_token') local last_time = ratelimit_info[1] local current_token = tonumber(ratelimit_info[2]) local max_token = tonumber(ARGV[1]) local token_rate = tonumber(ARGV[2]) local current_time = tonumber(ARGV[3]) local reverse_time = 1000/token_rate if current_token == nil then current_token = max_token last_time = current_time else local past_time = current_time-last_time; local reverse_token = math.floor(past_time/reverse_time) current_token = current_token+reverse_token; last_time = reverse_time*reverse_token+last_time if current_token>max_token then current_token = max_token end end local result = '0' if(current_token>0) then result = '1' current_token = current_token-1 end redis.call('HMSET',KEYS[1],'last_time',last_time,'current_token',current_toke  redis.call('pexpire',KEYS[1],math.ceil(reverse_time*(max_tokencurrent_token)+(current_time-last_time))) return result"; 



  @Override   public String getSha1() { 

    return DigestUtils.sha1Hex(SCRIPT); 

  } 



  @Override   public Class<String> getResultType() {     return String.class; 

  } 



  @Override   public String getScriptAsString() {     return SCRIPT; 

  } 

}

通过RedisTemplate对象执行脚本：

public boolean rateLimit(String key, int max, int rate) {

    List<String> keyList = new ArrayList<>(1);

    keyList.add(key);

    return "1".equals(stringRedisTemplate

        .execute(new RedisReteLimitScript(), keyList, Integer.toString(max), Integer.toString(rate),

            Long.toString(System.currentTimeMillis())));

  }

rateLimit方法传入的key为限流接口的ID，max为令牌桶的最大大小，rate为每秒钟恢复的令牌数量，返回的boolean即为此次请求是否通过了限流。为了测试Redis脚本限流是否可以正常工作，我们编写一个单元测试进行测试看看。

@Autowired

  private RedisManager redisManager;



  @Test

  public void rateLimitTest() throws InterruptedException {

    String key = "test_rateLimit_key";

    int max = 10;  //令牌桶大小

    int rate = 10; //令牌每秒恢复速度

    AtomicInteger successCount = new AtomicInteger(0);

    Executor executor = Executors.newFixedThreadPool(10);

    CountDownLatch countDownLatch = new CountDownLatch(30);

    for (int i = 0; i < 30; i++) {

      executor.execute(() -> {

        boolean isAllow = redisManager.rateLimit(key, max, rate);

        if (isAllow) {

          successCount.addAndGet(1);

        }

        log.info(Boolean.toString(isAllow));

        countDownLatch.countDown();

      });

    }

    countDownLatch.await();

    log.info("请求成功{}次", successCount.get());

  }

设置令牌桶大小为10，令牌桶每秒恢复10个，启动10个线程在短时间内进行30次请求，并输出每次限流查询的结果。日志输出：

[19:12:50,283]true 

[19:12:50,284]true 

[19:12:50,284]true 

[19:12:50,291]true 

[19:12:50,291]true 

[19:12:50,291]true 

[19:12:50,297]true 

[19:12:50,297]true 

[19:12:50,298]true 

[19:12:50,305]true 

[19:12:50,305]false 

[19:12:50,305]true 

[19:12:50,312]false 

[19:12:50,312]false 

[19:12:50,312]false 

[19:12:50,319]false 

[19:12:50,319]false 

[19:12:50,319]false 

[19:12:50,325]false 

[19:12:50,325]false 

[19:12:50,326]false 

[19:12:50,380]false 

[19:12:50,380]false 

[19:12:50,380]false 

[19:12:50,387]false 

[19:12:50,387]false 

[19:12:50,387]false 

[19:12:50,392]false 

[19:12:50,392]false 

[19:12:50,392]false 

[19:12:50,393]请求成功11次

可以看到，在0.1秒内请求的30次请求中，除了初始的10个令牌以及随时间恢复的1个令牌外，剩下19个没有取得令牌的请求均返回了false，限流脚本正确的将超过限制的请求给判断出来了，业务中此时就可以直接返回系统繁忙或接口请求太过频繁等提示。

3、开发中遇到的问题

1）Lua变量格式

Lua中的String和Number需要通过tonumber()和tostring()进行转换。

2）Redis入参

Redis的pexpire等命令不支持小数，但Lua的Number类型可以存放小数，因此Number类型传递给 Redis时最好通过math.ceil()等方式转换以避免存在小数导致命令失败。

3）Time命令

由于Redis在集群下是通过复制脚本及参数到所有节点上，因此无法在具有不确定性的命令后面执行写入命令，因此只能请求时传入时间而无法使用Redis的Time命令获取时间。

3.2版本之后的Redis脚本支持redis.replicate_commands()，可以改为使用Time命令获取当前时间。

4）潜在的隐患

由于此Lua脚本是通过请求时传入的时间做计算，因此务必保证分布式节点上获取的时间同步，如果时间不同步会导致限流无法正常运作。

最后

一个软件系统往往会存在很多隐藏的bug，最常用的功能bug往往很少。不常用的功能因为长时间不被人关注缺少重现的机会会一直隐藏在那里伺机爆发。而且随着软件系统的迭代更新，不受关注的功能极有可能被测试人员忽视从覆盖测试中被遗忘了。结果一旦遇到了突发的场景（墨菲定律），这一段被忽视的存在bug的代码逻辑被唤醒的，然后就会导致系统出错甚至奔溃。限流功能就是这些不被关注的功能之一。那么通过本篇文章，你对分布式服务限流有一个大概的了解了吗？

本文仅代表作者的一家之言，关于本文有什么疑问可以在下面留言交流，如果您觉得本文对您有帮助，欢迎关注我的公众号【Java技术zhai】，有新文章发布会第一时间通知您。

posted @ 2019-08-15 15:16 Java技术zhai 阅读(1249) 评论(0) 编辑收藏举报

Java技术zhai