Redis实际应用：限流

首先让我们先看一看系统架构设计中，为什么要做“限流”。不知道大家注意过没有，比如双11，刚过12点有些顾客的网页或APP会显示下单失败的提示，有些就是被限流掉了。

为什么要做限流

首先让我们先看一看系统架构设计中，为什么要做“限流”。

旅游景点通常都会有最大的接待量，不可能无限制的放游客进入，比如故宫每天只卖八万张票，超过八万的游客，无法买票进入，因为如果超过八万人，景点的工作人员可能就忙不过来，过于拥挤的景点也会影响游客的体验和心情，并且还会有安全隐患;「只卖N张票，这就是一种限流的手段」。

软件架构中的服务限流也是类似，也是当系统资源不够的时候，已经不足以应对大量的请求，为了保证服务还能够正常运行，那么按照规则，「系统会把多余的请求直接拒绝掉，以达到限流的效果」;

不知道大家注意过没有，比如双11，刚过12点有些顾客的网页或APP会显示下单失败的提示，有些就是被限流掉了。

常见的限流算法

计数法

顾名思义就是来一个，记录一个，比如我1分钟只能处理1000个请求，那么我们就可以设置一个计数器，来一个请求就incr+1，当1分钟之内的数量大于等于1000之后不处理了即可，伪代码如下

$redis = new Redis(); 
$redis->connect('127.0.0.1', 6379); 
$rate_limit = 1000;  //限制个数 
$rate_seconds = 60;  //限制时间 
$redis_key = "redis_limit"; 
$count = $redis->get($redis_key); 
if ($count >= $rate_limit){  //判断60秒内请求个数是否已经达到上限 
    //直接返回，不处理请求 
    return 
} 
$redis->incr($redis_key, 1);//请求计数 
$redis->expire($redis, $rate_seconds); //设置过期时间 60s 
//to do  业务逻辑处理....... 

这种计数方式比较简单快捷，但是有很大的缺点，因为请求的访问不一定是很平稳的，如果0:59过来了1000个请求，1:01已经是下一个窗口，又过来了1000个请求，但实际上三秒内来了2000个请求，已经超过我们的限流上限了。所以这种方法是不推荐的。

滑动窗口算法

还拿上面的例子，一分钟分6份，每份10秒;每过10秒钟，我们的时间窗口就会往右滑动一格，每个格子都有独立的计数器，我们每次都计算时间窗口内的数量，可以解决计数器法中的问题，而且当滑动窗口的格子越多，那么限流的统计就会越精确。具体可以参考下图，看图比较清晰

伪代码实现如下

function api_limit($scene,  $period, $maxCount){ 
    $redis = new Redis(); 
    $redis->connect('127.0.0.1', 6379); 
    $key = sprintf('hist:%s', $scene); //限流场景唯一标识 
    $now = msectime();   // 毫秒时间戳,这样更精确 
    $pipe=$redis->multi(Redis::PIPELINE); //使用管道提升性能 
    $pipe->zadd($key, $now, $now); //value 和 score 都使用毫秒时间戳 
    $pipe->zremrangebyscore($key, 0, $now - $period); //移除时间窗口之前的行为记录，剩下的都是时间窗口内的 
    $pipe->zcard($key);  //获取窗口内的行为数量 
    $pipe->expire($key, $period/1000 + 1);  //多加一秒过期时间 
    $replies = $pipe->exec(); 
    return $replies[2]