限流实现的思路比较多,一般比较常见的思路有 计数器,滑动窗口,令牌桶。
而Redis有着丰富的数据结构以及分布式的支持,使用Redis实现限流的业务还是比较适合的。
并且在Redis 4.0 上可以安装限流模块 redis-cell,其思路也是令牌桶,其提供了限流的原子操作使用起来很方便可靠。
计数器
计数器即在限定的时间内记请求的次数,如果过了这个时间段就重置次数。
这和我们平时参加一些活动很像,比如超市里有时做活动,每天一个人可以领一个鸡蛋,今天领过了就不能再领了但到了明天又可以再领了。
这里可以用 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 = min([$nowTime - $value[‘time‘], self::MAX_GAP * 1000]);
$tokenCount = $timeGap * $speed;
// 之前的数量 加上生成的数量 再减掉这次消耗的1个
$count = $value[‘count‘] + $tokenCount - 1;
// 记录下令牌的变动
$this->redis->set($key, json_encode($this->getJsonData($count)), self::TTL);
if ($count <= 0) {
return false;
} else {
return true;
}
} else {
// 设置初始时间信息
$initData = $this->getJsonData(1);
$this->redis->set($key, json_encode($initData), self::TTL);
return true;
}
}
令牌桶是根据速率限流,所以会很敏感,因为生成的速率是平均的,如果一开始流量就突然很大就很容易被限流。当然根据不同的业务场景和需求可以因地制宜的修改与实现。
前段时间基础架构组、DBA还有云盘团队一起推广了phpredis的RedisCluster的线上使用,目前线上业务已经稳定,单业务的规模水平是:Qps平均15W,数据量在700G左右。现对这段时间的工作和所遇到的一些常见问题进行简单总结
redis常用数据结构strig、list、hash、set、zset,这是最常用的5中redis数据结构,其实还有些不太常用的数据结构比如:HyperLogLog、GeoHash、PubSub等
redis 是当前非常流行的缓存数据库,得益于其简单的 key-value 模式的数据存储和丰富的数据类型与事件机制使得 redis 成为当前后端开发中不可或缺的利器。下面推荐一些好用的 redis 的管理工具
前段时间组内有个投票的产品,上线前考虑欠缺,导致被刷票严重。后来,通过研究,发现可以通过 redis lua 脚本实现限流,这里将 redis lua 脚本相关的知识分享出来,讲的不到位的地方还望斧正。
Redis在Php项目中的实际应用场景:商品维度计数、用户维度计数、存储社交关系、用作缓存代替memcached、反spam系统、用户Timeline/Feeds、最新列表&排行榜、消息通知、将Redis用作消息队列
php调用redis进去读写操作,大并发下会出现:读取key1,没有内容则写入内容,但是大并发下会出现同时多个php进程写入的情况,这个时候需要加一个锁,即获取锁的php进程有权限写。
Redis配置成主从模式,主库(Master)只负责写数据,从库(Slave)只负责读数据。一个主库可以拥有多个从库,但一个从库只能隶属于一个主库。
连接操作命令,持久化,远程服务控制,对value操作的命令,String,List,Set,Hash,Redis 发布订阅命令,Redis 事务命令,查看keys个数,清空数据库
目前有很多成熟的缓存产品,包括Redis,memcached等。这里以Redis为例来分析下使用缓存实现分布式锁的方案。主要的实现方式是使用Jedis.setNX方法来实现。以上实现方式同样存在几个问题:
说到分布式缓存,可能大多数人脑海浮现的就是redis了,为什么redis能够在竞争激烈的缓存大战中脱颖而出呢?原因无非有一下几点:性能好,丰富的特性跟数据结构,api操作简单。但是用的人多了,就会出现很多不规范或者疏忽的地方,严重的时候甚至会导致生产事故
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!