Redis命令使用实例分析
问题原因
小编负责的应用是一个管理后台应用,权限管理使用 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 单线程执行命令,只能顺序从队列取出任务开始执行。
只要 3 这个过程执行命令速度过慢,队列其他任务不得不进行等待,这对外部客户端看来,Redis 好像就被阻塞一样,一直得不到响应。
所以使用 Redis 过程切勿执行需要长时间运行的指令,这样可能导致 Redis 阻塞,影响执行其他指令。
KEYS 原理
接下来开始回答第二个问题,为什么Keys
指令查询会这么慢?
回答这个问题之前,请大家回想一下 Redis 底层存储结构。
不太清楚朋友的也没关系,大家可以回看一下之前的文章「阿里面试官:HashMap 熟悉吧?好的,那就来聊聊 Redis 字典吧!」。
keys
命令需要返回所有的符合给定模式 pattern
的 Redis 中键,为了实现这个目的,Redis 不得不遍历字典中 ht[0]
哈希表底层数组,这个时间复杂度为 「O(N)」(N 为 Redis 中 key 所有的数量)。
即使 Redis 中的键数量很少,它仍然会有很快的执行速度。当Redis键的数量逐渐增多,达到百万、千万,甚至上亿级别时,它的执行速度会变得非常缓慢。
下面是阿粉本地做的一次实验,使用 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
可能产生阻塞问题。