想在生产搞事情?那试试这些 Redis 命令
本文转载自微信公众号「Java极客技术 」,作者鸭血粉丝。转载本文请联系Java极客技术 公众号。
哎,最近阿粉又双叒叕犯事了。
事情是这样的,前一段时间阿粉公司生产交易偶发报错,一番排查下来最终原因是因为 Redis 命令执行超时。
可是令人不解的是,生产交易仅仅使用 Redis set 这个简单命令,这个命令讲道理是不可能会执行这么慢。
那到底是什么导致这个问题那?
为了找出这个问题,我们查看分析了一下 Redis 最近的慢日志,最终发现耗时比较多命令为 keys XX*
看到这个命令操作的键的前缀,阿粉才发现这是自己负责的应用。可是阿粉排查一下,虽然自己的代码并没有主动去使用 keys命令,但是底层使用框架却在间接使用,于是就有了今天这个问题。
问题原因
阿粉负责的应用是一个管理后台应用,权限管理使用 Shiro 框架,由于存在多个节点,需要使用分布式 Session,于是这里使用 Redis 存储 Session 信息。
由于 Shiro 并没有直接提供 Redis 存储 Session 组件,阿粉不得不使用 Github 一个开源组件 shiro-redis。
由于 Shiro 框架需要定期验证 Session 是否有效,于是 Shiro 底层将会调用 SessionDAO#getActiveSessions 获取所有的 Session 信息。
而 shiro-redis 正好继承 SessionDAO 这个接口,底层使用用keys 命令查找 Redis 所有存储的 Session key。
- public Set<byte[]> keys(byte[] pattern){
- checkAndInit();
- Set<byte[]> keys = null;
- Jedis jedis = jedisPool.getResource();
- try{
- keys = jedis.keys(pattern);
- }finally{
- jedis.close();
- }
- return keys;
- }
找到问题原因,解决办法就比较简单了,github 上查找到解决方案,升级一下 shiro-redis 到最新版本。
在这个版本,shiro-redis 采用 scan命令代替 keys,从而修复这个问题。
- public Set<byte[]> keys(byte[] pattern) {
- Set<byte[]> keys = null;
- Jedis jedis = jedisPool.getResource();
- try{
- keys = new HashSet<byte[]>();
- ScanParams params = new ScanParams();
- params.count(count);
- params.match(pattern);
- byte[] cursor = ScanParams.SCAN_POINTER_START_BINARY;
- ScanResult<byte[]> scanResult;
- do{
- scanResult = jedis.scan(cursor,params);
- keys.addAll(scanResult.getResult());
- cursor = scanResult.getCursorAsBytes();
- }while(scanResult.getStringCursor().compareTo(ScanParams.SCAN_POINTER_START) > 0);
- }finally{
- jedis.close();
- }
- return keys;
- }
虽然问题成功解决了,但是阿粉心里还是有点不解。
为什么keys 指令会导致其他命令执行变慢?
为什么Keys 指令查询会这么慢?
为什么Scan 指令就没有问题?
Redis 执行命令的原理
首先我们来看第一个问题,为什么keys 指令会导致其他命令执行变慢?
回答这个问题,我们首先看下 Redis 客户端执行一条命令的情况:
站在客户端的视角,执行一条命令分为三步:
- 发送命令
- 执行命令
- 返回结果
但是这仅仅客户端自己以为的过程,但是实际上同一时刻,可能存在很多客户端发送命令给 Redis,而 Redis 我们都知道它采用的是单线程模型。
为了处理同一时刻所有的客户端的请求命令,Redis 内部采用了队列的方式,排队执行。
于是客户端执行一条命令实际需要四步:
- 发送命令
- 命令排队
- 执行命令
- 返回结果
由于 Redis 单线程执行命令,只能顺序从队列取出任务开始执行。
只要 3 这个过程执行命令速度过慢,队列其他任务不得不进行等待,这对外部客户端看来,Redis 好像就被阻塞一样,一直得不到响应。
所以使用 Redis 过程切勿执行需要长时间运行的指令,这样可能导致 Redis 阻塞,影响执行其他指令。
KEYS 原理
接下来开始回答第二个问题,为什么Keys 指令查询会这么慢?
回答这个问题之前,请大家回想一下 Redis 底层存储结构。
这里阿粉复制之前文章内容,Redis 底层使用字典这种结构,这个结构与 Java HashMap 底层比较类似。
keys命令需要返回所有的符合给定模式 pattern 的 Redis 中键,为了实现这个目的,Redis 不得不遍历字典中 ht[0]哈希表底层数组,这个时间复杂度为 「O(N)」(N 为 Redis 中 key 所有的数量)。
如果 Redis 中 key 的数量很少,那么这个执行速度还是也会很快。等到 Redis key 的数量慢慢更加,上升到百万、千万、甚至上亿级别,那这个执行速度就会很慢很慢。
下面是阿粉本地做的一次实验,使用 lua 脚本往 Redis 中增加 10W 个 key,然后使用 keys 查询所有键,这个查询大概会阻塞十几秒的时间。
- eval "for i=1,100000 do redis.call('set',i,i+1) end" 0
这里阿粉使用 Docker 部署 Redis,性能可能会稍差。
SCAN 原理
最后我们来看下第三个问题,为什么scan 指令就没有问题?
这是因为 scan命令采用一种黑科技-「基于游标的迭代器」。
每次调用 scan 命令,Redis 都会向用户返回一个新的游标以及一定数量的 key。下次再想继续获取剩余的 key,需要将这个游标传入 scan 命令, 以此来延续之前的迭代过程。
简单来讲,scan 命令使用分页查询 redis 。
下面是一个 scan 命令的迭代过程示例:
scan 命令使用游标这种方式,巧妙将一次全量查询拆分成多次,降低查询复杂度。
虽然 scan 命令时间复杂度与 keys一样,都是 「O(N)」,但是由于 scan 命令只需要返回少量的 key,所以执行速度会很快。
最后,虽然scan 命令解决 keys不足,但是同时也引入其他一些缺陷:
- 同一个元素可能会被返回多次,这就需要我们应用程序增加处理重复元素功能。
- 如果一个元素在迭代过程增加到 redis,或者说在迭代过程被删除,那个这个元素会被返回,也可能不会。
以上这些缺陷,在我们开发中需要考虑这种情况。
除了 scan以外,redis 还有其他几个用于增量迭代命令:
- sscan:用于迭代当前数据库中的数据库键,用于解决 smembers 可能产生阻塞问题
- hscan命令用于迭代哈希键中的键值对,用于解决 hgetall 可能产生阻塞问题。
- zscan:命令用于迭代有序集合中的元素(包括元素成员和元素分值),用于产生 zrange 可能产生阻塞问题。
总结
Redis 使用单线程执行操作命令,所有客户端发送过来命令,Redis 都会现放入队列,然后从队列中顺序取出执行相应的命令。
如果任一任务执行过慢,就会影响队列中其他任务的,这样在外部客户端看来,迟迟拿不到 Redis 的响应,看起来就很阻塞了一样。
所以不要在生产执行 keys、smembers、hgetall、zrange这类可能造成阻塞的指令,如果真需要执行,可以使用相应的scan 命令渐进式遍历,可以有效防止阻塞问题。
相关文章
- 数据分享|R语言用主成分PCA、 逻辑回归、决策树、随机森林分析心脏病数据并高维可视化|附代码数据
- R语言广义线性模型(GLM)、全子集回归模型选择、检验分析全国风向气候数据|附代码数据
- GIS空间数据模型: 注记文本模型
- 地理空间索引实现:z 曲线、希尔伯特曲线、四叉树, 最邻近几何特征查询、范围查询
- flask + pyecharts 搭建新冠肺炎疫情数据可视化交互分析平台:包含疫情数据获取、态势感知、预测分析、舆情监测等任务
- ArcEngine + DevPress GIS二次开发:湖北疫情交互式数据分析、地图输出、专题可视化系统 具体实现
- 编译过程中的并行性优化(二):基本块与全局代码调度算法
- 地理空间数据库复习笔记:概论、关系模型与关系代数
- (本地无法连接MySQL服务器)ERROR 2003 (HY000): Can‘t connect to MySQL server on ‘localhost‘ (10061)
- MySQL数据库时区错误,设置时区
- Redis实战11-实现优惠券秒杀下单
- itol.toolkit中文文档|PRUNE选择分枝
- 转录组实战01: 从数据下载到定量fastp+STAR
- 【ES三周年】一份初学者的Elasticsearch入门笔记
- 二、数据类型
- 详解Redisson分布式限流的实现原理
- 数学建模常用模型03:层次分析法
- 数学建模常用模型04:灰色关联分析法
- 数学建模常用模型06 :组内相关系数法
- 2023年,无代码、低代码8大技术趋势