本文共 1231字,閱讀大約需要 5分鐘 !
概述
在前文《Redis字串型別內部編碼剖析》之中已經剖析過 Redis最基本的 String型別的內部是怎麼編碼和儲存的,本文再來闡述 Redis中使用 最為頻繁的資料型別:雜湊(或稱雜湊),在Redis內部是怎麼存的。
- 實驗原始碼環境:Redis 4.0.10
注: 本文首發於 My Personal Blog,歡迎光臨 小站
本文內容腦圖如下:

雜湊型別內部編碼詳情
對於 Redis的常用 5 種資料型別(String、Hash、List、Set、sorted set),每種資料型別都提供了 最少兩種 內部的編碼格式,而且每個資料型別內部編碼方式的選擇 對使用者是完全透明的,Redis會根據資料量自適應地選擇較優化的內部編碼格式。
如果想檢視某個鍵的內部編碼格式,可以使用 OBJECT ENCODING keyname
指令來進行,比如:
127.0.0.1:6379>
127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379>
127.0.0.1:6379> object encoding foo // 檢視某個Redis鍵值的編碼
"embstr"
127.0.0.1:6379>
127.0.0.1:6379>
複製程式碼
對於使用最為頻繁的 Hash型別,其內部編碼方式可能有兩種:
- OBJ_ENCODING_ZIPLIST(壓縮列表)
- OBJ_ENCODING_HT(雜湊表)
Redis 會根據資料量的情況來自適應地選擇這兩種編碼方式中 較優 的一種,而這一切對使用者完全透明。
在 資料條目較少,資料值較小 的時候 Redis會採用 壓縮列表(OBJ_ENCODING_ZIPLIST)編碼方式進行儲存。這裡成員"較少",成員值"較小"的標準可以通過如下配置項進行配置:
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
複製程式碼
Redis 預設給出了預設值,當然使用者可根據實際情況自行配置。
當 Hash型別鍵的欄位個數 < hash-max-ziplist-entries
並且 每個欄位名和欄位值的長度 < hash-max-ziplist-value
時,Redis 會使用 OBJ_ENCODING_ZIPLIST來儲存該鍵,反之則會轉換為 OBJ_ENCODING_HT的編碼方式。
口說無憑,我們不妨先來做個實驗感受一下吧:

很明顯該實驗驗證了當 欄位值長度大於64時,編碼格式會由 ZIPLIST方式切換為 Hashtable方式。
原始碼之前,了無祕密,我們再來看一下Redis關於這部分切換的原始碼實現,那就理解得更加清楚了:


下面詳解 OBJ_ENCODING_ZIPLIST
和 OBJ_ENCODING_HT
這兩種編碼格式的內部儲存模型,知道了其各自特點和優缺點,自然也就明白了Redis內部使用它們的意圖。
OBJ_ENCODING_ZIPLIST 編碼
Ziplist 壓縮列表是一種緊湊編碼格式,總體思想是時間換空間,即以部分讀寫效能為代價,來換取極高的記憶體空間利用率,因此只會用於 欄位個數少,且欄位值也較小 的場景。
壓縮列表記憶體利用率極高的原因與其連續記憶體的特性是分不開的,其典型的記憶體結構可以用下圖形象地展示出來:

所以如果用 Ziplist來儲存 Redis的雜湊型別的話,元素的排列方式就變成了如下圖所示的形象示意圖:即key和value都是邏輯連續記憶體:

OBJ_ENCODING_HT 編碼
OBJ_ENCODING_HT 這種編碼方式內部才是真正的雜湊表結構,或稱為字典結構,其可以實現O(1)複雜度的讀寫操作,因此效率很高。
在 Redis內部,從 OBJ_ENCODING_HT型別到底層真正的雜湊表資料結構是一層層巢狀下去的,關係如下:

這一關係我們可以從 Redis雜湊表定義部分的原始碼來看出:

下面來詳解一下各個部分:
- 關於雜湊節點(dictEntry)

- 關於雜湊表(dictht)和字典(dict)

- 關於dictType

- Redis如何計算Hash值
Redis計算Hash的原始碼如下:

這是一個 C語言巨集定義,其實幕後真正承擔 Hash值計算的是上面介紹的 dictType
結構體中的函式指標 hashFunction
。
而該 hashFunction
函式指標在初始化時會對應被賦值為一個個真實的計算 Hash值的實際函式,就像下面這樣:

- Redis如何計算存取索引Index值
Index值的計算依賴於上面計算得出的 Hash值,程式碼如下:

到此,還有一個一直非常值得關注的細節:即字典 dict裡總是儲存有兩個 Hash表結構 ht[2],以及與其高度相關的 rehash操作,這在下一篇文章裡詳解。
後 記
由於能力有限,若有錯誤或者不當之處,還請大家批評指正,一起學習交流!
可 長按 或 掃描 下面的 小心心 來訂閱作者公眾號 CodeSheep,獲取更多 務實、能看懂、可復現的 原創文 ↓↓↓
