Redis學習筆記（五） 壓縮列表

壓縮列表是列表鍵與哈希鍵的底層實現之一。當一個列表鍵只包含少許的列表項，而且每一個列表項要麼就是小整數值，要麼就是長度較短的字符串，那麼Redis就會使用壓縮列表來作列表鍵的底層實現。

壓縮列表是爲了節約內存而開發的，是由一系列特殊編碼的連續內存塊組成的順序型數據結構。一個壓縮列表能夠包含任意多的節點，每一個節點能夠保存一個字節數組或一個整數值。

壓縮表能夠包含：

一、長度小於等於63字節的字節數組

二、長度小於16383字節的字節數組

三、長度小於等於4294967295字節的字節數組

四、4位長度的無符號整數

五、1字節長度有符號整數

六、3字節長的有符號整數

七、int16類型的整數

八、int32類型的整數

九、int64類型的整數

 

每一個壓縮列表節點都由previous_entry_length、encoding、content三部分組成

說明：previous_entry_length 保存前一節點的長度，若是前一個節點長度小於254節點，那麼previous_entry_length屬性須要1字節長的空間來保存這個長度值；若是超度254則須要5個字節長的空間來保存這個長度。

 

連鎖更新

因爲是連續的內存片斷，當在中間插入一個元素時，

 

e1節點的 previous_entry_length屬性僅長1字節，當將new節點設置爲前置節點時，因爲e1的previous_entry_length 長度爲1沒法保存new節點的長度，因此須要將長度擴展到5個字節空間，所以須要對列表進行空間從新分配操做。同理，若是引起了對e二、e3.。。。的擴展，這種操做稱爲連鎖更新。

連鎖更新在最壞的狀況下須要對壓縮列表執行n次空間的重分配操做，每次空間重分配的最壞複雜度爲O(N)，因此連鎖更新最壞的的複雜度爲O(N²)。

 

-------- end --------

天天學一點，總會有收穫。

說明：尊重做者知識產權，文中內容參考《Redis設計與實現》，僅在此作學習與你們分享。