Redis 中，字典是基礎結構。Redis 資料庫資料、過期時間、雜湊型別都是把字典作為底層結構。 # 字典的結構 ## 雜湊表 雜湊表的實現程式碼在：`dict.h/dictht `，Redis 的字典用雜湊表的方式實現。 ```c 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` 就是一個鍵值對 ```c 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` 。 ```c 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** ```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，也沒有迭代器的狀態)： # 雜湊演算法 當字典中需要新增新的鍵值對時，需要先對鍵進行雜湊，算出雜湊值，然後在根據字典的長度，算出索引值。 ```c // 使用雜湊字典裡面的雜湊演算法，算出雜湊值 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 設計與實現》圖片集](http://1e-gallery.redisbook.com/4-dict.html) )          ![](https://img-blog.csdnimg.cn/20201225222029648.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2lkZXNpcmVjY3g=,size_16,color_FFFFF