Redis 設計與實現 4：字典

小新是也發表於2020-12-25
Redis

Redis 中，字典是基礎結構。Redis 資料庫資料、過期時間、雜湊型別都是把字典作為底層結構。

字典的結構

雜湊表

雜湊表的實現程式碼在：dict.h/dictht ，Redis 的字典用雜湊表的方式實現。

typedef struct dictht {
	// 雜湊表陣列，俗稱的雜湊桶(bucket)
    dictEntry **table;
    // 雜湊表的長度
    unsigned long size;
    // 雜湊表的長度掩碼，用來計算索引值，保證不越界。總是 size - 1
    // h = dictHashKey(ht, he->key) & n.sizemask;
    unsigned long sizemask;
    // 雜湊表已經使用的節點數
    unsigned long used;
} dictht;
  • table 是一個雜湊表陣列，每個節點的實現在 dict.h/dictEntry，每個 dictEntry 儲存一個鍵值對。
  • size 屬性記錄了向系統申請的雜湊表的長度，不一定都用完，有預留空間的。
  • sizemask 屬性主要是用來計算 索引值 = 雜湊值 & sizemask，這個索引值決定了鍵值對放在 table 的哪個位置。它的值總是 size - 1，其實我有點不明白為啥計算的時候不直接用 size - 1，知道的大佬請明示。
  • used 屬性用來記錄已經使用的節點數，size - use 就是未使用的節點啦。

下圖展示了一個大小為 4 的空雜湊表結構，沒有任何鍵值對
一個空雜湊表

雜湊節點

雜湊表 dictht 的 table 的元素由雜湊節點 dictEntry 組成，每一個 dictEntry 就是一個鍵值對

typedef struct dictEntry {
	// 鍵
    void *key;
    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    // 下一個雜湊節點，用於雜湊衝突時拉鍊表用的
    struct dictEntry *next;
} dictEntry;

next 指標是用於當雜湊衝突的時候，可以形成連結串列用的。後續會將

字典

Redis 的字典實現在： dict.h/dict 。

typedef struct dict {
	// 雜湊演算法
    dictType *type;
    // 私有資料，用於不同型別的雜湊演算法的引數
    void *privdata;
    // 兩個雜湊表，用兩個的原因是 rehash 擴容縮容用的
    dictht ht[2];
    // rehash 進行到的索引值，當沒有在 rehash 的時候，為 -1
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    // 正在跑的迭代器
    unsigned long iterators; /* number of iterators currently running */
} dict;

// dictType 實際上就是雜湊演算法，不知道為啥名字叫 dictType
typedef struct dictType {
	// hash方法，根據 key 計算雜湊值
    uint64_t (*hashFunction)(const void *key);
    // 複製 key
    void *(*keyDup)(void *privdata, const void *key);
    // 複製 value
    void *(*valDup)(void *privdata, const void *obj);
    // key 比較
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
    // 銷燬 key
    void (*keyDestructor)(void *privdata, void *key);
    // 銷燬 value
    void (*valDestructor)(void *privdata, void *obj);
} dictType;

dictType 屬性表示字典型別，實際上這個字典型別就是一組操作鍵值對演算法，裡面規定了很多函式。
privdata 則是為不同型別的 dictType 提供的可選引數。
如果有需要，在建立字典的時候，可以傳入dictType 和 privdata。

dict.c

// 建立字典，這裡有 type 和 privdata 可以傳
dict *dictCreate(dictType *type, void *privDataPtr) {
    dict *d = zmalloc(sizeof(*d));
    _dictInit(d,type,privDataPtr);
    return d;
}

// 初始化字典
int _dictInit(dict *d, dictType *type, void *privDataPtr) {
    _dictReset(&d->ht[0]);
    _dictReset(&d->ht[1]);
    d->type = type;
    d->privdata = privDataPtr;
    d->rehashidx = -1;
    d->iterators = 0;
    return DICT_OK;
}

下圖是比較完整的普通狀態下的 dict 的結構(沒有進行 rehash，也沒有迭代器的狀態)：
dict 結構圖# 雜湊演算法
當字典中需要新增新的鍵值對時，需要先對鍵進行雜湊，算出雜湊值，然後在根據字典的長度，算出索引值。

// 使用雜湊字典裡面的雜湊演算法，算出雜湊值
hash = dict->type->hashFunction(key)
// 使用 sizemask 和 雜湊值算出索引值
idx = hash & d->ht[table].sizemask;
// 通過索引值，定位雜湊節點
he = d->ht[table].table[idx];

雜湊衝突

雜湊衝突指的是多個不同的 key，算出的索引值一樣。

Redis 解決雜湊衝突的方法是：拉鍊法。就是每個雜湊節點後面有個 next 指標，當發現計算出的索引值對應的位置有其他節點，那麼直接加在前面節點後即可，這樣就形成了一個連結串列。

下圖展示了 {k1, v1} 和 {k2, v2} 雜湊衝突的結構。
假設 k1 和 k2 算出的索引值都是 3，當 k2 發現 table[3] 已經有 dictEntry{k1,v1}，那就 dictEntry{k1,v1}.next = dictEntry{k2,v2}。
雜湊衝突拉鍊表的示意圖

rehash

隨著操作的不斷進行，雜湊表的長度會不斷增減。雜湊表的長度太長會造成空間浪費，太短雜湊衝突明顯導致效能下降，雜湊表需要通過擴容或縮容，讓雜湊表的長度保持在一個合理的範圍內。
Redis 通過 ht[0] 和 ht[1] 來完成 rehash 的操作，步驟如下：

  1. 為 ht[1] 分配空間，分配的空間長度有兩種情況：
    • 擴容：第一個大於等於 ht[0].used * 2 的 \(2^n\) 的數，例如 ht[0].used = 3，那麼分配的是距離 6 最近的 \(2^3=8\)
    • 縮容：第一個大於等於 ht[0].used / 2 的 \(2^n\) 的數，例如 ht[0].used = 6，那麼分配的是距離 3 最近的 \(2^2=4\)
  2. 將 h[0] 上的鍵值對都遷移到 h[1]，遷移的時候都是重新計算索引值的。由於 h[1] 的長度較長，之前在 h[0] 拉鍊的元素大概率會被分到不同的位置。
  3. ht[0] 所有的鍵值對遷移完之後，h[0] 釋放，然後 h[0] = h[1]，並把 h[1] 清空，為下次 rehash 準備

漸進式 rehash

上面說的 rehash 中的第二步，遷移的過程不是一次完成的。如果雜湊表的長度比較小，一次完成很快。但是如果雜湊表很長，例如百萬千萬，那這個遷移的過程就沒有那麼快了，會造成命令阻塞！
下面來說說，redis 是如何漸進式地將 h[0] 中的鍵值對遷移到 h[1] 中的：

  1. 為 h[1] 開闢空間，字典同時持有 h[0] 和 h[1]
  2. 字典中的 rehashidx 維護了 rehash 的進度，設定為 0 的時候，開始 rehash
  3. 字典每次增刪改查的時候，除了完成指定操作之外，還會順帶把 rehashidx 上的整條連結串列遷移到 h[1] 中。遷移完之後 rehashidx + 1
  4. 隨著字典的不斷讀取、操作，最終 h[0] 上的所有鍵值對都會遷移到 h[1] 中。全部遷移完成之後 rehashidx = -1

這種漸進式 rehash 的方式的好處在於，將龐大的遷移工作，分攤到每次的增刪改查中，避免了一次性操作帶來的效能的巨大損耗。
缺點就是遷移過程中 h[0] 和 h[1] 同時存在的時間比較長，空間利用率較低。

下面一系列的圖，演示了字典是如何漸進式地 rehash ( 圖片來自 《Redis 設計與實現》圖片集 )








相關文章