深入理解Redis的scan命令

面向Google程式設計發表於2018-10-09
Redis

熟悉Redis的人都知道，它是單執行緒的。因此在使用一些時間複雜度為O(N)的命令時要非常謹慎。可能一不小心就會阻塞程式，導致Redis出現卡頓。

有時，我們需要針對符合條件的一部分命令進行操作，比如刪除以test_開頭的key。那麼怎麼獲取到這些key呢？在Redis2.8版本之前，我們可以使用keys命令按照正則匹配得到我們需要的key。但是這個命令有兩個缺點：

  1. 沒有limit，我們只能一次性獲取所有符合條件的key，如果結果有上百萬條，那麼等待你的就是“無窮無盡”的字串輸出。
  2. keys命令是遍歷演算法，時間複雜度是O(N)。如我們剛才所說，這個命令非常容易導致Redis服務卡頓。因此，我們要儘量避免在生產環境使用該命令。

在滿足需求和存在造成Redis卡頓之間究竟要如何選擇呢？面對這個兩難的抉擇，Redis在2.8版本給我們提供瞭解決辦法——scan命令。

相比於keys命令，scan命令有兩個比較明顯的優勢：

  1. scan命令的時間複雜度雖然也是O(N)，但它是分次進行的，不會阻塞執行緒。
  2. scan命令提供了limit引數，可以控制每次返回結果的最大條數。

這兩個優勢就幫助我們解決了上面的難題，不過scan命令也並不是完美的，它返回的結果有可能重複，因此需要客戶端去重。至於為什麼會重複，相信你看完本文之後就會有答案了。

關於scan命令的基本用法，可以參看Redis命令詳解：Keys一文中關於SCAN命令的介紹。

今天我們主要從底層的結構和原始碼的角度來討論scan是如何工作的。

Redis的結構

Redis使用了Hash表作為底層實現，原因不外乎高效且實現簡單。說到Hash表，很多Java程式設計師第一反應就是HashMap。沒錯，Redis底層key的儲存結構就是類似於HashMap那樣陣列+連結串列的結構。其中第一維的陣列大小為2n(n>=0)。每次擴容陣列長度擴大一倍。

scan命令就是對這個一維陣列進行遍歷。每次返回的遊標值也都是這個陣列的索引。limit參數列示遍歷多少個陣列的元素，將這些元素下掛接的符合條件的結果都返回。因為每個元素下掛接的連結串列大小不同，所以每次返回的結果數量也就不同。

SCAN的遍歷順序

關於scan命令的遍歷順序，我們可以用一個小栗子來具體看一下。

127.0.0.1:6379> keys *
1) "db_number"
2) "key1"
3) "myKey"
127.0.0.1:6379> scan 0 MATCH * COUNT 1
1) "2"
2) 1) "db_number"
127.0.0.1:6379> scan 2 MATCH * COUNT 1
1) "1"
2) 1) "myKey"
127.0.0.1:6379> scan 1 MATCH * COUNT 1
1) "3"
2) 1) "key1"
127.0.0.1:6379> scan 3 MATCH * COUNT 1
1) "0"
2) (empty list or set)
複製程式碼

我們的Redis中有3個key，我們每次只遍歷一個一維陣列中的元素。如上所示，SCAN命令的遍歷順序是

0->2->1->3

這個順序看起來有些奇怪。我們把它轉換成二進位制就好理解一些了。

00->10->01->11

我們發現每次這個序列是高位加1的。普通二進位制的加法，是從右往左相加、進位。而這個序列是從左往右相加、進位的。這一點我們在redis的原始碼中也得到印證。

在dict.c檔案的dictScan函式中對遊標進行了如下處理

v = rev(v);
v++;
v = rev(v);
複製程式碼

意思是，將遊標倒置，加一後，再倒置，也就是我們所說的“高位加1”的操作。

這裡大家可能會有疑問了，為什麼要使用這樣的順序進行遍歷，而不是用正常的0、1、2……這樣的順序呢，這是因為需要考慮遍歷時發生字典擴容與縮容的情況（不得不佩服開發者考慮問題的全面性）。

我們來看一下在SCAN遍歷過程中，發生擴容時，遍歷會如何進行。加入我們原始的陣列有4個元素，也就是索引有兩位，這時需要把它擴充成3位，並進行rehash。

rehash

原來掛接在xx下的所有元素被分配到0xx和1xx下。在上圖中，當我們即將遍歷10時，dict進行了rehash，這時，scan命令會從010開始遍歷，而000和100（原00下掛接的元素）不會再被重複遍歷。

再來看看縮容的情況。假設dict從3位縮容到2位，當即將遍歷110時，dict發生了縮容，這時scan會遍歷10。這時010下掛接的元素會被重複遍歷，但010之前的元素都不會被重複遍歷了。所以，縮容時還是可能會有些重複元素出現的。

Redis的rehash

rehash是一個比較複雜的過程，為了不阻塞Redis的程式，它採用了一種漸進式的rehash的機制。

/* 字典 */
typedef struct dict {
    // 型別特定函式
    dictType *type;
    // 私有資料
    void *privdata;
    // 雜湊表
    dictht ht[2];
    // rehash 索引
    // 當 rehash 不在進行時，值為 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */
    // 目前正在執行的安全迭代器的數量
    int iterators; /* number of iterators currently running */
} dict;
複製程式碼

在Redis的字典結構中，有兩個hash表，一個新表，一箇舊表。在rehash的過程中，redis將舊錶中的元素逐步遷移到新表中，接下來我們看一下dict的rehash操作的原始碼。

/* Performs N steps of incremental rehashing. Returns 1 if there are still
 * keys to move from the old to the new hash table, otherwise 0 is returned.
 *
 * Note that a rehashing step consists in moving a bucket (that may have more
 * than one key as we use chaining) from the old to the new hash table, however
 * since part of the hash table may be composed of empty spaces, it is not
 * guaranteed that this function will rehash even a single bucket, since it
 * will visit at max N*10 empty buckets in total, otherwise the amount of
 * work it does would be unbound and the function may block for a long time. */
int dictRehash(dict *d, int n) {
    int empty_visits = n*10; /* Max number of empty buckets to visit. */
    if (!dictIsRehashing(d)) return 0;

    while(n-- && d->ht[0].used != 0) {
        dictEntry *de, *nextde;

        /* Note that rehashidx can't overflow as we are sure there are more
         * elements because ht[0].used != 0 */
        assert(d->ht[0].size > (unsigned long)d->rehashidx);
        while(d->ht[0].table[d->rehashidx] == NULL) {
            d->rehashidx++;
            if (--empty_visits == 0) return 1;
        }
        de = d->ht[0].table[d->rehashidx];
        /* Move all the keys in this bucket from the old to the new hash HT */
        while(de) {
            uint64_t h;

            nextde = de->next;
            /* Get the index in the new hash table */
            h = dictHashKey(d, de->key) & d->ht[1].sizemask;
            de->next = d->ht[1].table[h];
            d->ht[1].table[h] = de;
            d->ht[0].used--;
            d->ht[1].used++;
            de = nextde;
        }
        d->ht[0].table[d->rehashidx] = NULL;
        d->rehashidx++;
    }

    /* Check if we already rehashed the whole table... */
    if (d->ht[0].used == 0) {
        zfree(d->ht[0].table);
        d->ht[0] = d->ht[1];
        _dictReset(&d->ht[1]);
        d->rehashidx = -1;
        return 0;
    }

    /* More to rehash... */
    return 1;
}
複製程式碼

通過註釋我們就能瞭解到，rehash的過程是以bucket為基本單位進行遷移的。所謂的bucket其實就是我們前面所提到的一維陣列的元素。每次遷移一個列表。下面來解釋一下這段程式碼。

  • 首先判斷一下是否在進行rehash，如果是，則繼續進行；否則直接返回。
  • 接著就是分n步開始進行漸進式rehash。同時還判斷是否還有剩餘元素，以保證安全性。
  • 在進行rehash之前，首先判斷要遷移的bucket是否越界。
  • 然後跳過空的bucket，這裡有一個empty_visits變數，表示最大可訪問的空bucket的數量，這一變數主要是為了保證不過多的阻塞Redis。
  • 接下來就是元素的遷移，將當前bucket的全部元素進行rehash，並且更新兩張表中元素的數量。
  • 每次遷移完一個bucket，需要將舊錶中的bucket指向NULL。
  • 最後判斷一下是否全部遷移完成，如果是，則收回空間，重置rehash索引，否則告訴呼叫方，仍有資料未遷移。

由於Redis使用的是漸進式rehash機制，因此，scan命令在需要同時掃描新表和舊錶，將結果返回客戶端。

相關文章