上一篇我們講解了Redis中SDS的組成以及優(yōu)勢，這一篇我們討論下Redis中的Hash數(shù)據(jù)類型是怎么構(gòu)成的呢？

? ?Java中存在HashMap和HashTable的數(shù)據(jù)類型。而Hash的數(shù)據(jù)結(jié)構(gòu)可以近似于HashTable，依據(jù)數(shù)組+鏈表的形式構(gòu)成。

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

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

壓縮鏈表的內(nèi)部結(jié)構(gòu)圖：

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

??

然后讓我們看一下entry的內(nèi)部結(jié)構(gòu)：

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

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

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

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

?? 于是存儲過多的元素或者大元素的時候，hash也就自動轉(zhuǎn)化為字典的方式進行存儲。字典的方式可以根據(jù)hashtable的結(jié)構(gòu)進行理解，數(shù)組+鏈表。數(shù)組存放的是鏈表的第一個元素的指針。

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

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

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。