根据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 keys(byte[] pattern){
    checkAndInit();
    Set 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 keys(byte[] pattern) {
    Set keys = null;
    Jedis jedis = jedisPool.getResource();


    try{
        keys = new HashSet();
        ScanParams params = new ScanParams();
        params.count(count);
        params.match(pattern);
        byte[] cursor = ScanParams.SCAN_POINTER_START_BINARY;
        ScanResult 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 指令会导致其他命令执行变慢？

站在客户端的视角，执行一条命令分为三步：

1. 发送命令

2. 执行命令

3. 返回结果

但是这仅仅客户端自己以为的过程，但是实际上同一时刻，可能存在很多客户端发送命令给 Redis ，而 Redis 我们都知道它采用的是单线程模型。

为了处理同一时刻所有的客户端的请求命令，Redis 内部采用了队列的方式，排队执行。

于是客户端执行一条命令实际需要四步：

1. 发送命令

2. 命令排队

3. 执行命令

4. 返回结果

由于 Redis 单线程执行命令，只能顺序从队列取出任务开始执行。

只要 3 这个过程执行命令速度过慢，队列其他任务不得不进行等待，这对外部客户端看来，Redis 好像就被阻塞一样，一直得不到响应。

所以使用 Redis 过程切勿执行需要长时间运行的指令，这样可能导致 Redis 阻塞，影响执行其他指令。

KEYS 原理

接下来开始回答第二个问题，为什么Keys 指令查询会这么慢？

回答这个问题之前，请大家回想一下 Redis 底层存储结构。

不太清楚朋友的也没关系，大家可以回看一下之前的文章「阿里面试官：HashMap 熟悉吧？好的，那就来聊聊 Redis 字典吧！」。

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 可能产生阻塞问题。