Redis資料結構—連結串列與字典
大家好，我是白澤。今天我們來聊一聊Redis中的連結串列與字典
連結串列
關於連結串列的基礎概念其實你在學習Redis之前一定積累了不少，所以本文將預設你已經掌握了連結串列相關的基礎知識，而Redis的連結串列其實也就是普通的連結串列~
因為Redis是使用C語言編寫的，因此Redis的資料結構的定義都是使用C語法定義的，你不需要完全理解下方C語言宣告結構體的語法，但我認為依靠大家的Java知識也能理解這就像是在Java中定義了一個連結串列物件
Redis連結串列節點的結構
typedef struct listNode {
struct listNode *prev; //指向前一個連結串列節點
struct listNode *next; //指向後一個連結串列節點
void *value; //當前節點的值(可以按需設定不同資料型別的value)
} listNode;
很明顯，當每一個節點內記錄了前後兩個節點位置之後，連結串列節點之間就能夠彼此前後相連，組成雙向通行車道（可以雙向遍歷）
Redis連結串列的表示
上面講解了Redis的連結串列的節點表示，並由此引申了一下可以藉此構建Redis雙端連結串列，而事實上，對於每一個存在的雙端連結串列，Redis使用一個list結構來表示
typedef struct list {
listNode *head; //表頭節點
listNode *tail; //表尾節點
unsigned long len; //連結串列所包含的節點的數量
void *(*dup)(void *ptr); //節點複製函式
void (*free)(void *ptr); //節點釋放函式
void (*match)(void *ptr, void *key);//節點值對比函式
} list;
很明顯，你看到三個好像是返回值為void的函式，但是看不懂C語法，沒關係，傳統後端功夫，自然是點到為止
Redis連結串列用在哪
我不想現在就告訴你，連結串列被廣泛用於實現Redis的各種功能，比如列表鍵、釋出於訂閱、慢查詢、監視器等（這太空洞了，除了讓你聽一遍這幾個詞彙，對你沒有任何幫助），等我們後面講到這幾部分的時候，白澤再結合連結串列和你細說~
字典
和連結串列一樣，Redis所使用的C語言並沒有內建字典這種資料結構，因此Redis構建了自己的字典實現。如果你學過資料結構，你會發現Redis的字典事實上就是資料結構中的鄰接表，即使沒學過，往下看就好啦~
Redis字典結構總覽
陣列 + 連結串列 ==> 鄰接表，實錘
Redis字典結構分解
還記得嗎，上面我們說Redis連結串列可以用list描述，但是連結串列儲存的資料本質上，是由一系列listNode節點通過前後指標相連儲存的；類似的，Redis字典可以用如下dict描述，但是字典儲存的資料本質上，是由陣列 + 若干連結串列組合得到的資料結構儲存的，字典dict結構如下：
typedef struct dict {
dictType *type; //型別特定函式
void *privdata; //私有資料
dictht ht[2]; //雜湊表陣列
int trehashidx; //rehash索引，當rehash不在進行時，值為-1
} dict;
現在你只需要關注其中的雜湊表陣列ht[2]，它的資料型別為dictht，因此也是一種複合的資料結構，如下：
typedef struct dictht {
dictEntry **table; //雜湊表陣列
unsigned long size; //雜湊表大小
unsigned long sizemax; //雜湊表大小掩碼，用於計算索引值，等於size - 1
unsigned long used; //該雜湊表已有節點的數量
} dictht;
雜湊表dictht是Redis字典的核心，dictht的四個屬性中，size、sizemax、used都是用於描述table屬性整體狀態。看到這你就明白了，dictht的核心是dictEntry型別的table屬性（再次提醒，如果沒有C語言的基礎，本文中一切你看不懂的語法，包括資料型別，你只需要一眼帶過即可，我們的目的是學習Redis的設計思想）
table屬性是一個陣列，陣列中的每個元素都是一個指向dictEntry結構的指標，每個dictEntry結構儲存一個鍵值對，並含有一個指向下一個dictEntry的指標，結構如下：
typedef struct dictEntry {
void *key; //鍵
union { //值（可以是一個指標，可以是一個uint64_t型別的整數，也可以是一個int64_t型別的整數）
void *val;
uint64_t u64;
int64_t s64;
} v;
struct dictEntry *next;//指向下個雜湊表節點，形成連結串列
} dictEntry;
雜湊演算法
我們知道，字典是用來儲存資料的，並且是以鍵值對的形式儲存的，那麼我每次存入一個鍵值對放在字典的哪裡？這就是雜湊演算法為你解決的事情：程式需要先根據鍵值對的鍵計算出雜湊值和索引值，然後再根據索引值，將包含新鍵值對的雜湊表節點放到雜湊表陣列的指定索引上面
比如我已經有下面這個字典，然後要插入一個鍵值對資料：k1 : v1，則程式有如下計算過程：（使用者只是往Redis伺服器中插入了一條資料，下面都是程式內部的工作~）
hash = dict->type->hashFunction(k1); //計算k1鍵的hash值（得到某個數值）
index = hash & dict->ht[0].sizemask = 1; //計算k1鍵插入位置的索引值
解決鍵衝突
鍵衝突：當不同的key值計算得到的dictEntry索引值相同時，就稱發生鍵衝突（我要插入的位置已經被佔用了，插入使得連結串列長度由1變多，當然第一次插入不算衝突）
解決方法：
就像上面我要插入一個k1 ：v1的鍵值對，並計算得到插入位置的索引為1（但是distEntry陣列中索引為1的位置已經有k0 ：v0鍵值對存放了），因此程式會在雜湊表ht[0]的dictEntry陣列的索引為1的位置上插入一個dictEntry節點，放在原本連結串列首部的前一位置（搶佔首位），其中存放著k1 ： v1鍵值對，插入後的圖如下：
你可能疑惑新插入的鍵值對的位置在每個dictEntry連結串列的最前面，而不是尾部，原因是每個dictEntry中除了儲存鍵值對之外，只記錄了下一個dictEntry的地址（上面我已經給出了dictEntry的結構了~），程式無法直接得到dictEntry連結串列的最後一個節點，但可以直接得到第一個節點（通過dictEntry陣列索引直接定位），因此每次插入的dictEntry節點（鍵值對）都將直接插入到對應索引的連結串列的頭部（因此dictEntry陣列的內容是不斷在變的）
一句話來說：distEntry陣列幫助使用索引定位，distEntry連結串列，用於處理衝突，不斷維護所儲存的鍵值對資料
rehash
隨著操作的不斷執行（增、刪、改、查），雜湊表儲存的鍵值對會逐漸增多或者減少，為了讓雜湊表的負載因子維持在一個合理範圍內，當雜湊表儲存的鍵值對數量太多或太少時，程式會對雜湊表的大小進行相應的擴充套件或者收縮（不知道你是否記得還有一個雜湊表ht[1]的存在，這個表就是為了和ht[0]配合進行rehash而存在的）
rehash步驟：
-
為字典的ht[1]雜湊表分配空間
-
如果程式執行擴充套件操作：
ht[1].size = 第一個大於等於ht[0].used * 2（ht[0]已經使用的空間大小乘2）的2的n次方冪
-
如果程式執行收縮操作：
ht[1].size = 第一個大於等於ht[0].used（ht[0]已經使用的空間大小）的2的n次方冪
-
-
將儲存在ht[0]上的鍵值對rehash到ht[1]上，因為size不同，所以是重新hash，而不是整體複製
-
當ht[0]內鍵值對全部遷移到ht[1]中後，釋放ht[0]，然後將ht[1]和ht[0]的互換（rehash結束），此時ht[0]就是一個rehash後的雜湊表，而ht[1]依舊為空表，為下次rehash做準備
漸進式rehash
上面提到的在雜湊表ht[0]的負載因子過大或者過小會觸發rehash，但是，事實上rehash遷移的過程不是一蹴而就的（很明顯，如果資料ht[0]的資料很多，每次rehash如果都遷移全部資料，需要花費較大時間等待，使用者在rehash期間訪問Redis伺服器將會陷入無響應的狀態）
漸進式過程：
將rehash的過程分攤在後續的每次增、刪、改、查操作上，在rehash期間，每次對字典執行操作，程式除了執行指定操作外，還會順帶將ht[0]雜湊表在rehashidx索引（從0開始，-1表示rehash未開始）上的所有鍵值對rehash到ht[1]，當每次區域性rehash工作完成後，程式將rehashidx屬性的值增一
注意：每次對字典進行增、刪、改、查會在ht[0]和ht[1]上同時進行，比如查詢一個鍵，則會現在ht[0]上查詢，沒找到再去ht[1]上查詢，諸如此類，除了增加操作每次都將直接hash到ht[1]上，不會對ht[0]執行任何新增操作