詳解redis數據結構之壓縮列表

redis使用壓縮列表作為列表鍵和哈希鍵的底層實現之一。當一個列表鍵只包含少量的列表項，并且每個列表項都是由小整數值或者是短字符串組成，那么redis就會使用壓縮列表存儲列表項；同理，當一個哈希表包含的鍵值對都是由小整數值或者是短字符串組成，并且存儲的鍵值對數目不多時，redis也會使用壓縮列表來存儲哈希表。以下是壓縮列表存儲結構：

• zlbytes長度為4個字節，記錄了整個壓縮列表所占用的字節數
• zltail長度為4個字節，記錄了壓縮列表起始位置到壓縮列表尾節點的偏移量
• zllen長度為2個字節，記錄了當前壓縮列表中所擁有的entry的數量
• entryX存儲了實際的對象，其長度根據具體的實體而定
• zlend長度為1個字節，保存了十進制的255，用于標記壓縮列表的末端

      通過上面的結構可以看出，壓縮列表存儲數據的為一整個數組，在這個數組中前12個字節固定保存了zlbytes、zltail和zllen三個表征整個壓縮列表屬性的數據，而后續的數組則保存了entry的數組，最后通過一個字節長度的屬性zlend來記錄當前壓縮列表已經結束。

      在上述結構中，我們并沒有看到任何屬性用以表征每個entry的長度及其存儲的數據類型，如字符串或者是整型值，而壓縮列表整體其實是一個數組，因而如果不對這兩個類型的數據進行記錄那么將無法對每一個entry進行區分。實際上，每個entry是由三部分組成：previous_entry_length、encoding和content。

1.previous_entry_length為一個整型值，記錄了前一個節點整體占用字節的長度，當前一個節點的長度小于254時，該屬性占用一個字節，當前一個節點長度大于等于254時，該屬性則占用5個字節，其第一個字節會保存十進制的0xFE，即十進制的254，后四個字節則保存了前一節點的長度；

2.encoding屬性長度不定，其主要保存了當前節點的編碼格式和節點的長度。當encoding屬性的最高兩位為00、01或10時，表示其存儲的是字節數組。其為00時，encoding占用1個字節，其后6位保存了content屬性的長度；為01時，encoding占用2個字節，其后14位保存了content屬性的長度；為10時，則其后38位保存了content屬性的長度。當encoding屬性的最高兩位為11時，表示其存儲的是一個整型值，并且此時encoding屬性的長度為1個字節。當11后兩位，也即第三位和第四位為00時，表示存儲的是int16_t類型的整數，當其為01時，表示存儲的是int32_t類型的整數，當其為10時，表示存儲的是int64_t類型的整數，當其為11時，表示存儲的是24位有符號整數。（這四種情況后續位上的值都為0）當11后五位為1，并且最后一位為0時，表示存儲的是8位有符號整數。當11后兩位為11時，那么該節點就沒有content屬性，該節點的屬性值保存在encoding屬性的后四個位上，并且其值要介于0~12之間。

3.content屬性保存了該節點的實際的字符串或整型數據。

感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！