【PHP】Redis实现限流的简单思路

一般比较常见的限流思路有 计数器,滑动窗口,令牌桶。

计数器

计数器即在限定的时间内记请求的次数,如果过了这个时间段就重置次数。

这和我们平时参加一些活动很像,比如超市里有时做活动,每天一个人可以领一个鸡蛋,今天领过了就不能再领了但到了明天又可以再领了。

这里可以用 String 来实现,比如要实现一分钟限制100次,只要记下上次请求的是哪一分钟,并记住这一分钟请求的次数即可,利用过期时间可以淘汰不用的数据。

    public function checkRequest($uid)
    {
        $timeKey = self::LIMIT_TIME_KEY . $uid;
        // 得到上次请求的时间
        $lastTime = $this->redis->get($timeKey);
        if ($lastTime) {
            // 看看时间戳是不是已经过了一分钟(自己设定的时间范围)
            $nowTime = time();
            if ($nowTime - $lastTime < self::LIMIT_UNIT) {
                // 还没一分钟
                // 获取下请求了多少次
                $countKey = self::LIMIT_KEY . $lastTime . ':' . $uid;
                $count = $this->redis->get($countKey);
if ($count >= self::LIMIT_COUNT) { // 超过次数了 return false; } else { // 没超过加一 $this->redis->set($countKey, ++$count, self::TTL); }
}
else { // 超过一分钟了可以重置了 $this->initLimitData($uid); } } else { // 都没有记录肯定没请求或好久没请求了 可以重置了 $this->initLimitData($uid); } return true; }

这种实现缺点就是如果请求正好在间隔处密集请求,就大致可以被请求两倍的限额量。

 

滑动窗口

这种思路是记录下每次请求的时间,然后再统计下在规定范围内(窗口内)被请求了多少次。

这种方式可以通过Redis ZSET 有序集合来实现,通过时间戳作为分数,只要获取相应时间戳范围内的请求次数并加以判断即可。

    public function checkRequest($uid)
    {
        // 是否严重超过请求限制
        $banKey = self::LIMIT_BAN_KEY . $uid;
        $isBan = $this->redis->get($banKey);
        if ($isBan) {
            return false;
        }

        // 得到微秒 粒度太粗不好测
        // startTime 与 nowTime 形成了一个窗口的时间范围
        $nowTime = microtime(true) * 1000;
        $startTime = $nowTime - self::LIMIT_UNIT * 1000;

        $zSetKey = self::LIMIT_KEY . $uid;

        // 获取时间范围内的请求数据
        $requestHistory = $this->redis->zRangeByScore($zSetKey, $startTime, $nowTime);

        $count = count($requestHistory);
        // 首先判断是否严重超过限制
        if ($count > self::LIMIT_BAN_COUNT) {
            // 直接封
            $this->redis->set($banKey, 1, self::BAN_TTL);
            return false;
        }

        // 将下面的REDIS命令打包,使一组命令具有原子性
        $this->redis->multi();
        // 添加
        $options = [];
        $value = $uid . ':' . $nowTime . rand(0, 999);
        // 多余的数据删除
        $this->redis->zRemRangeByScore($zSetKey, 0, $startTime);
        // 添加数据
        $this->redis->zAdd($zSetKey, $options, $nowTime, $value);
        // 设置过期时间
        $this->redis->expire($zSetKey, self::TTL);
        // 执行这一组命令
        $this->redis->exec();

        if ($count >= self::LIMIT_COUNT) {
            return false;
        } else {
            return true;
        }
    }

要注意的是如果不清理窗口外的数据并有用户一直稳定地请求的话,这个用户的有序集合就会越来越大。

并且删除时也需要注意是否待删除数据会不会很多,因为删除一个BigKey是有可能造成Redis短暂的阻塞。

可以判断下用户在窗口内的请求次数有没有严重超过限制的次数,严重超过后可以考虑停用该用户的服务。

令牌桶

令牌桶的思路很像小学时候遇到的一种数学题,有个水池如果打开水龙头N小时装满,如果打开下面的水塞M小时放完,现在同时打开水龙头和水塞啥时候水流完。

令牌桶是需不断往桶里生成令牌,取的太快,取完了就会限流。

用 Redis 实现只要记录下每次请求的时间,计算这次与上次请求的两次时间内应该生成多少再减去这次消耗令牌的数量,如果算下来令牌小于0就应该限流了。

    public function checkRequest($uid)
    {
        $key = self::LIMIT_KEY . $uid;
        $data = $this->redis->get($key);
        // 是否有请求的记录数据
        if ($data) {
            $value = json_decode($data, true);

            // 计算上个请求到现在为止会生成多少个令牌
            $nowTime = microtime(true) * 1000;
            $speed = self::LIMIT_COUNT / (self::LIMIT_UNIT * 1000);

            $timeGap = $nowTime - $value['time'];
            $tokenCount = $timeGap * $speed;

            // 限制一次生成的token最大数量
            $tokenCount = min(self::MAX_TOKEN, $tokenCount) ;

            // 之前的数量 加上生成的数量 再减掉这次消耗的1个 
            $count = ($value['count'] + $tokenCount - 1) % self::MAX_LIMIT;
            // 记录下变动
            $this->redis->set($key, json_encode($this->getJsonData($count)), self::TTL);

            if ($count <= 0) {
                return false;
            } else {
                return true;
            }

        } else {
            // 设置初始时间信息
            $initData = $this->getJsonData(self::MAX_TOKEN);
            $this->redis->set($key, json_encode($initData), self::TTL);
            return true;
        }
    }

令牌桶是根据速率限流,所以会很敏感,因为生成的速率是平均的。

我在自己尝试时候发现如果一开始流量就很大并且没有初始值就很容易被限流。

漏桶算法和令牌桶算法区别


漏桶与令牌桶的思路很像,但是这里和令牌桶不同的是,漏桶控制的是进水的速度,如果流量过大进水速度过快,水就会溢出这部分的流量就会被丢弃。

令牌桶是不断生成令牌进桶,有令牌能取出就正常通过,而没有令牌能取出就会被限流。

两者正好将流量一进一出比作相反,从突发流量来看令牌桶能容忍更大的突发流量。

原子性操作

上述方法虽然可以在低并发时实现限流但如果多并发时会出现计算错误的问题。

比如A发起请求,服务器读出了A已有的限流数据并开始准备记录,服务器还没来得及写入时A又发起请求,这时读取的数据还是更新前的数据。

这种错误即限流算法不具有原子性,读和写入都是可以分开的。

通过 redis 扩展实现限流

如果实际使用还是建议基于 redis-cell 扩展去实现,redis-cell 是一个用 rust 语言编写的基于令牌桶算法的的限流模块。 

posted @ 2020-12-12 00:48  Fang20  阅读(889)  评论(0)    收藏  举报