在微服务、API 化、云原生大行其道的今天,服务治理不可或缺,而服务治理中限流几乎是必不可少的手段;微服务化往往伴随着分布式的架构,那么仅仅单机限流是不够的,还需要分布式的限流。
那么问题就来了:分布式限流中,往往会出现「限流不均衡」或「限流误差」的情况,这是为什么呢?
国庆假期,限流这个词在新闻中应该能频繁听到,就是「景区限流」。这里以无锡的两个景点为例:
📌示例:
- 无锡蠡园:最大承载量调整至 20000 人;瞬时最大承载量调整至 4000 人;
- 无锡东林书院:书院接待日最大承载量即时降至 1500 人,瞬时承载量降至 300 人。
在计算机网络中,限流就是用于控制网络接口控制器发送或接收请求的速率[1],由此延伸为:限制到达系统的并发请求数,以此来保障系统的稳定性(特别是在微服务、API 化、云原生系统上)。
本质上单机限流和分布式限流的区别就在于「承载量」存放的位置。
单机限流直接在单台服务器上实现,而在微服务、API 化、云原生系统上,应用和服务是集群部署的,因此需要集群内的多个实例协同工作,以提供集群范围的限流,这就是分布式限流。
比如上面提到的滑动窗口的算法,可以将计数器存放至 Redis 这样的 KV 数据库中。
例如滑动窗口的每个请求的时间记录可以利用 Redis 的 zset
存储,利用 ZREMRANGEBYSCORE
删除时间窗口之外的数据,再用 ZCARD
计数。
示例代码[2]如下:
package com.lizba.redis.limit;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;
import redis.clients.jedis.Response;
/**
* <p>
* Limiting current by sliding window algorithm through zset
* </p>
*
* @Author: Liziba
* @Date: 2021/9/6 18:11
*/
public class SimpleSlidingWindowByZSet {
private Jedis jedis;
public SimpleSlidingWindowByZSet(Jedis jedis) {
this.jedis = jedis;
}
/**
* Judging whether an action is allowed
*
* @param userId User id
* @param actionKey Behavior key
* @param period Current Limiting Cycle
* @param maxCount Maximum number of requests (sliding window size)
* @return
*/
public boolean isActionAllowed(String userId, String actionKey, int period, int maxCount) {
String key = this.key(userId, actionKey);
long ts = System.currentTimeMillis();
Pipeline pipe = jedis.pipelined();
pipe.multi();
pipe.zadd(key, ts, String.valueOf(ts));
// Remove data other than sliding windows
pipe.zremrangeByScore(key, 0, ts - (period * 1000));
Response<Long> count = pipe.zcard(key);
// Set the expiration time of the behavior, and if the data is cold, zset will be deleted to save memory space
pipe.expire(key, period);
pipe.exec();
pipe.close();
return count.get() <= maxCount;
}
/**
* Current limiting key
*
* @param userId
* @param actionKey
* @return
*/
public String key(String userId, String actionKey) {
return String.format("limit:%s:%s", userId, actionKey);
}
}
复制
像令牌桶也可以将令牌数量放到 Redis 中。
不过以上的方式相当于每一个请求都需要去 Redis 判断一下能不能通过,在性能上有一定的损耗,所以针对大并发系统,有个优化点就是 「批量」。例如每次取令牌不是一个一取,而是取一批,不够了再去取一批。这样可以减少对 Redis 的请求。
但是,批量获取就会导致一定范围内的限流误差。比如 a 实例此刻取了 100 个,等下一秒再用,那下一秒集群总承载量就有可能超过阈值。
这是一种原因。
分布式限流还有一种做法是「平分」,比如之前单机限流 100,现在集群部署了 5 个实例,那就让每台继续限流 100,即在总的入口做总的流量限制,比如 500,然后每个实例再自己实现限流。
这种情况下,假设总的入口放入了 500 请求,这些请求需要通过负载均衡算法(如:轮询、最小连接数、最小连接时间等)以及会话保持策略(如:源地址保持、cookie 保持或特定参数的 hash),分到每台的请求就可能是不均衡的,比如 a 实例有 70 个,b 实例有 130 个。那么 a 实例的 70 个会通过,而 b 实例的 130 个可能只有 100 个会通过。这时就出现了「限流不均衡」或「限流偏差」的情况。
这是第二种原因。
由于本人经验所限,本文只列出了我目前能想到的 2 个答案给大家参考,欢迎各位交流补充。
真实的业务场景是很复杂的,具体到一个工程,限流需要考虑的条件和资源有很多。我们要做的就是通过估算、压测、试运行、调整、再生产验证再调整来逼近理想情况。
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.