Redis中雜湊分佈不均勻該怎麼辦

雙子孤狼發表於2021-01-20
Redis

前言

Redis 是一個鍵值對資料庫，其鍵是通過雜湊進行儲存的。整個 Redis 可以認為是一個外層雜湊，之所以稱為外層雜湊，是因為 Redis 內部也提供了一種雜湊型別，這個可以稱之為內部雜湊。當我們採用雜湊物件進行資料儲存時，對整個 Redis 而言，就經過了兩層雜湊儲存。

雜湊物件

雜湊物件本身也是一個 key-value 儲存結構，底層的儲存結構也可以分為兩種：ziplist（壓縮列表） 和 hashtable（雜湊表）。這兩種儲存結構也是通過編碼來進行區分：

編碼屬性 描述 object encoding命令返回值
OBJ_ENCODING_ZIPLIST 使用壓縮列表實現雜湊物件 ziplist
OBJ_ENCODING_HT 使用字典實現雜湊物件 hashtable

hashtable

Redis 中的 key-value 是通過 dictEntry 物件進行包裝的，而雜湊表就是將 dictEntry 物件又進行了再一次的包裝得到的，這就是雜湊表物件 dictht：

typedef struct dictht {
    dictEntry **table;//雜湊表陣列
    unsigned long size;//雜湊表大小
    unsigned long sizemask;//掩碼大小，用於計算索引值，總是等於size-1
    unsigned long used;//雜湊表中的已有節點數
} dictht;

注意：上面結構定義中的 table 是一個陣列，其每個元素都是一個 dictEntry 物件。

字典

字典，又稱為符號表（symbol table），關聯陣列（associative array）或者對映（map），字典的內部巢狀了雜湊表 dictht 物件，下面就是一個字典 ht 的定義：

typedef struct dict {
    dictType *type;//字典型別的一些特定函式
    void *privdata;//私有資料，type中的特定函式可能需要用到
    dictht ht[2];//雜湊表(注意這裡有2個雜湊表)
    long rehashidx; //rehash索引，不在rehash時，值為-1
    unsigned long iterators; //正在使用的迭代器數量
} dict;

其中 dictType 內部定義了一些常用函式，其資料結構定義如下：

typedef struct dictType {
    uint64_t (*hashFunction)(const void *key);//計算雜湊值函式
    void *(*keyDup)(void *privdata, const void *key);//複製鍵函式
    void *(*valDup)(void *privdata, const void *obj);//複製值函式
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);//對比鍵函式
    void (*keyDestructor)(void *privdata, void *key);//銷燬鍵函式
    void (*valDestructor)(void *privdata, void *obj);//銷燬值函式
} dictType;

當我們建立一個雜湊物件時，可以得到如下簡圖（部分屬性被省略）：

rehash 操作

dict 中定義了一個陣列 ht[2]，ht[2] 中定義了兩個雜湊表：ht[0] 和 ht[1]。而 Redis 在預設情況下只會使用 ht[0]，並不會使用 ht[1]，也不會為 ht[1] 初始化分配空間。

當設定一個雜湊物件時，具體會落到雜湊陣列（上圖中的 dictEntry[3]）中的哪個下標，是通過計算雜湊值來確定的。如果發生雜湊碰撞（計算得到的雜湊值一致），那麼同一個下標就會有多個 dictEntry，從而形成一個連結串列（上圖中最右邊指向 NULL 的位置），不過需要注意的是最後插入元素的總是落在連結串列的最前面（即發生雜湊衝突時，總是將節點往連結串列的頭部放）。

當讀取資料的時候遇到一個節點有多個元素，就需要遍歷連結串列，故連結串列越長，效能越差。為了保證雜湊表的效能，需要在滿足以下兩個條件中的一個時，對雜湊表進行 rehash（重新雜湊）操作：

  • 負載因子大於等於 1 且 dict_can_resize 為 1 時。
  • 負載因子大於等於安全閾值（dict_force_resize_ratio=5）時。

PS：負載因子 = 雜湊表已使用節點數 / 雜湊表大小（即：h[0].used/h[0].size）。

rehash 步驟

擴充套件雜湊和收縮雜湊都是通過執行 rehash 來完成，這其中就涉及到了空間的分配和釋放，主要經過以下五步：

  1. 為字典 dict 的 ht[1] 雜湊表分配空間，其大小取決於當前雜湊表已儲存節點數（即：ht[0].used）：

    • 如果是擴充套件操作則 ht[1] 的大小為 2 的 n次方中第一個大於等於ht[0].used * 2屬性的值（比如used=3，此時ht[0].used * 2=6，故 2的3次方為8就是第一個大於used * 2 的值（2 的 2 次方 < 6 且 2 的 3 次方 > 6））。
    • 如果是收縮操作則 ht[1] 大小為 2 的 n 次方中第一個大於等於 ht[0].used 的值。

  2. 將字典中的屬性 rehashix 的值設定為 0，表示正在執行 rehash 操作。

  3. 將 ht[0] 中所有的鍵值對依次重新計算雜湊值，並放到 ht[1] 陣列對應位置，每完成一個鍵值對的 rehash之後 rehashix 的值需要自增 1。

  4. 當 ht[0] 中所有的鍵值對都遷移到 ht[1] 之後，釋放 ht[0] ，並將 ht[1] 修改為 ht[0]，然後再建立一個新的 ht[1] 陣列，為下一次 rehash 做準備。

  5. 將字典中的屬性 rehashix 設定為 -1，表示此次 rehash 操作結束，等待下一次 rehash。

漸進式 rehash

Redis 中的這種重新雜湊的操作因為不是一次性全部 rehash，而是分多次來慢慢的將 ht[0] 中的鍵值對 rehash 到 ht[1]，故而這種操作也稱之為漸進式 rehash。漸進式 rehash 可以避免集中式 rehash 帶來的龐大計算量，是一種分而治之的思想。

在漸進式 rehash 過程中，因為還可能會有新的鍵值對存進來，此時** Redis 的做法是新新增的鍵值對統一放入 ht[1] 中，這樣就確保了 ht[0] 鍵值對的數量只會減少**。

當正在執行 rehash操作時，如果伺服器收到來自客戶端的命令請求操作，則會先查詢 ht[0]，查詢不到結果再到ht[1] 中查詢。

ziplist

關於 ziplist 的一些特性，之前的文章中有單獨進行過分析，想要詳細瞭解的，可以點選這裡。但是需要注意的是雜湊物件中的 ziplist 和列表物件中 ziplist 的有一點不同就是雜湊物件是一個 key-value 形式，所以其 ziplist 中也表現為 key-value，key 和 value 緊挨在一起：

ziplist 和 hashtable 的編碼轉換

當一個雜湊物件可以滿足以下兩個條件中的任意一個，雜湊物件會選擇使用 ziplist 編碼來進行儲存：

  • 雜湊物件中的所有鍵值對總長度（包括鍵和值）小於等於 64位元組（這個閾值可以通過引數 hash-max-ziplist-value 來進行控制）。
  • 雜湊物件中的鍵值對數量小於等於 512 個（這個閾值可以通過引數 hash-max-ziplist-entries 來進行控制）。

一旦不滿足這兩個條件中的任意一個，雜湊物件就會選擇使用 hashtable 編碼進行儲存。

雜湊物件常用命令

  • hset key field value：設定單個 field（雜湊物件的 key 值）。
  • hmset key field1 value1 field2 value2 ：設定多個 field（雜湊物件的 key 值）。
  • hsetnx key field value：將雜湊表 key 中域 field 的值設定為 value，如果 field 已存在，則不執行任何操作。
  • hget key field：獲取雜湊表 key 中的域 field 對應的 value。
  • hmget key field1 field2：獲取雜湊表 key 中的多個域 field 對應的 value。
  • hdel key field1 field2：刪除雜湊表 key 中的一個或者多個 field。
  • hlen key：返回雜湊表key中域的數量。
  • hincrby key field increment：為雜湊表 key 中的域 field 的值加上增量 increment ，increment 可以為負數，如果 field 不是數字則會報錯。
  • hincrbyfloat key field increment：為雜湊表 key 中的域 field 的值加上增量 increment，increment 可以為負數，如果 field 不是 float 型別則會報錯。
  • hkeys key：獲取雜湊表 key 中的所有域。
  • hvals key：獲取雜湊表中所有域的值。

瞭解了操作雜湊物件的常用命令，我們就可以來驗證下前面提到的雜湊物件的型別和編碼了，在測試之前為了防止其他 key 值的干擾，我們先執行 flushall 命令清空 Redis 資料庫。

然後依次執行如下命令：

hset address country china
type address
object encoding address

得到如下效果：

可以看到當我們的雜湊物件中只有一個鍵值對的時候，底層編碼是 ziplist。

現在我們將 hash-max-ziplist-entries 引數改成 2，然後重啟 Redis，最後再輸入如下命令進行測試：

hmset key field1 value1 field2 value2 field3 value3
object encoding key

輸出之後得到如下結果：

可以看到，編碼已經變成了 hashtable。

總結

本文主要介紹了 Redis 中 5 種常用資料型別中的雜湊型別底層的儲存結構 hashtable 的使用，以及當 hash 分佈不均勻時候 Redis 是如何進行重新雜湊的問題，最後瞭解了雜湊物件的一些常用命令，並通過一些例子驗證了本文的結論。

相關文章