概述
在前文《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操作，這在下一篇文章裡詳解。
閱讀更多 IT技術之家 的文章
