上一篇我們講解了Redis中SDS的組成以及優勢，這一篇我們討論下Redis中的Hash數據類型是怎么構成的呢？

? ?Java中存在HashMap和HashTable的數據類型。而Hash的數據結構可以近似于HashTable，依據數組+鏈表的形式構成。

??? 在Redis中，Hash在元素對象個數較少的時候采用的是壓縮鏈表的形式

(ziplist)，壓縮鏈表是一塊連續的內存空間，元素之間緊緊的挨著，不存在任何的冗余空間。

壓縮鏈表的內部結構圖：

struct?ziplist{????int32?zlbytes;??//壓縮列表占用的字節數????int32?zltail_offset;?//壓縮列表最后一個元素到起始位置的偏移量????int16 zllength; //元素的個數????T[]?entries;???//元素列表????int8?zlend;???//壓縮列表的末尾???常設置為0xFF}?;

??

然后讓我們看一下entry的內部結構：

struct entry{???int<var>?prevlen; //前一個entry字節長度???int<var>?encoding;??//元素編碼類型???optional byte[] content; //元素內容}

??prelen存放的是上一個entry的字節長度，壓縮列表倒著遍歷的時候，需要這個字段快速的定位下一個元素的位置。其是一個變長的整數，小于254的時候用一個字節存放，大于254的時候用的是5個字節存放。

? encoding 代表的是壓縮表的編碼類型，其是根據encoding的前綴位進行區分的。(有興趣的同事可以看一下redis的深度歷險)

? ?當插入元素的時候，ziplist每次都需要進行內存的重新分配，所以不適合存儲大元素或者過多的元素。

?? 于是存儲過多的元素或者大元素的時候，hash也就自動轉化為字典的方式進行存儲。字典的方式可以根據hashtable的結構進行理解，數組+鏈表。數組存放的是鏈表的第一個元素的指針。

? 提到hash，就不得不提漸進式rehash。

??當hashtable需要擴容的時候怎么辦呢？Redis維護了兩個Hashtable。需要擴容的時候就會將舊的字典所有的鏈表元素掛到新的鏈表下面。但是不是一次性立馬轉移完成，畢竟redis是單線程的，需要保證性能。

??漸進式 rehash式一個數組內容一個數組內容進行元素的轉移。當查詢觸及到當前鏈表的時候，查詢完成后會將鏈表的元素轉移到新的字典鏈表下。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的redis深度历险_Redis的数据结构（内存具体怎么优化的）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。