問題原因

阿粉負(fù)責(zé)的應(yīng)用是一個(gè)管理后臺應(yīng)用，權(quán)限管理使用 Shiro 框架，由于存在多個(gè)節(jié)點(diǎn)，需要使用分布式 Session，于是這里使用 Redis 存儲 Session 信息。

由于 Shiro 并沒有直接提供 Redis 存儲 Session 組件，阿粉不得不使用 Github 一個(gè)開源組件 shiro-redis。

由于 Shiro 框架需要定期驗(yàn)證 Session 是否有效，于是 Shiro 底層將會調(diào)用  SessionDAO#getActiveSessions 獲取所有的 Session 信息。

而 shiro-redis 正好繼承 SessionDAO 這個(gè)接口，底層使用用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 到最新版本。

在這個(gè)版本，shiro-redis 采用 scan命令代替 keys,從而修復(fù)這個(gè)問題。

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;

}

雖然問題成功解決了，但是阿粉心里還是有點(diǎn)不解。

為什么keys 指令會導(dǎo)致其他命令執(zhí)行變慢？

為什么Keys 指令查詢會這么慢？

為什么Scan 指令就沒有問題？

Redis 執(zhí)行命令的原理

首先我們來看第一個(gè)問題，為什么keys 指令會導(dǎo)致其他命令執(zhí)行變慢？

回答這個(gè)問題，我們首先看下 Redis 客戶端執(zhí)行一條命令的情況：

   

站在客戶端的視角，執(zhí)行一條命令分為三步：

但是這僅僅客戶端自己以為的過程，但是實(shí)際上同一時(shí)刻，可能存在很多客戶端發(fā)送命令給 Redis，而 Redis 我們都知道它采用的是單線程模型。

為了處理同一時(shí)刻所有的客戶端的請求命令，Redis 內(nèi)部采用了隊(duì)列的方式，排隊(duì)執(zhí)行。

   

于是客戶端執(zhí)行一條命令實(shí)際需要四步：

由于 Redis 單線程執(zhí)行命令，只能順序從隊(duì)列取出任務(wù)開始執(zhí)行。

只要 3 這個(gè)過程執(zhí)行命令速度過慢，隊(duì)列其他任務(wù)不得不進(jìn)行等待，這對外部客戶端看來，Redis 好像就被阻塞一樣，一直得不到響應(yīng)。

所以使用 Redis 過程切勿執(zhí)行需要長時(shí)間運(yùn)行的指令，這樣可能導(dǎo)致 Redis 阻塞，影響執(zhí)行其他指令。

KEYS 原理

接下來開始回答第二個(gè)問題，為什么Keys 指令查詢會這么慢？

回答這個(gè)問題之前，請大家回想一下 Redis 底層存儲結(jié)構(gòu)。

不太清楚朋友的也沒關(guān)系，大家可以回看一下阿粉之前的文章「阿里面試官：HashMap 熟悉吧？好的，那就來聊聊 Redis 字典吧！」。

這里阿粉復(fù)制之前文章內(nèi)容，Redis 底層使用字典這種結(jié)構(gòu)，這個(gè)結(jié)構(gòu)與 Java HashMap 底層比較類似。

   

keys命令需要返回所有的符合給定模式 pattern 的  Redis 中鍵，為了實(shí)現(xiàn)這個(gè)目的，Redis 不得不遍歷字典中 ht[0]哈希表底層數(shù)組，這個(gè)時(shí)間復(fù)雜度為 「O(N)」（N 為 Redis 中 key 所有的數(shù)量）。

如果 Redis 中 key 的數(shù)量很少，那么這個(gè)執(zhí)行速度還是也會很快。等到 Redis key 的數(shù)量慢慢更加，上升到百萬、千萬、甚至上億級別，那這個(gè)執(zhí)行速度就會很慢很慢。

下面是阿粉本地做的一次實(shí)驗(yàn)，使用 lua 腳本往 Redis 中增加 10W 個(gè) key，然后使用 keys 查詢所有鍵,這個(gè)查詢大概會阻塞十幾秒的時(shí)間。

eval "for i=1,100000  do redis.call('set',i,i+1) end" 0

SCAN 原理

最后我們來看下第三個(gè)問題，為什么scan 指令就沒有問題？

這是因?yàn)?scan命令采用一種黑科技-「基于游標(biāo)的迭代器」。

每次調(diào)用 scan 命令，Redis 都會向用戶返回一個(gè)新的游標(biāo)以及一定數(shù)量的 key。下次再想繼續(xù)獲取剩余的 key，需要將這個(gè)游標(biāo)傳入 scan 命令， 以此來延續(xù)之前的迭代過程。

簡單來講，scan 命令使用分頁查詢 redis 。

下面是一個(gè) scan 命令的迭代過程示例：

scan 命令使用游標(biāo)這種方式，巧妙將一次全量查詢拆分成多次，降低查詢復(fù)雜度。

雖然  scan 命令時(shí)間復(fù)雜度與 keys一樣，都是 「O(N)」，但是由于 scan 命令只需要返回少量的 key，所以執(zhí)行速度會很快。

最后，雖然scan 命令解決 keys不足，但是同時(shí)也引入其他一些缺陷：

以上這些缺陷，在我們開發(fā)中需要考慮這種情況。

除了 scan以外，redis 還有其他幾個(gè)用于增量迭代命令：