詳解redis資料結構之壓縮列表
redis使用壓縮列表作為列表鍵和雜湊鍵的底層實現之一。當乙個列表鍵只包含少量的列表項，並且每個列表項都是由小整數值或者是短字串組成，那麼redis就會使用壓縮列表儲存列表項；同理，當乙個雜湊表包含的鍵值對都是由小整數值或者是短字串組成，並且儲存的鍵值對數目不多時，redis也會使用壓縮列表來儲存雜湊表。以下是壓縮列表儲存結構：
通過上面的結構可以看出，壓縮列表儲存資料的為一整個陣列，在這個陣列中前12個位元組固定儲存了zlbytes、zltail和zllen三個表徵整個壓縮列表屬性的資料，而後續的陣列則儲存了entry的陣列，最後通過乙個位元組長度的屬性zlend來記錄當前壓縮列表已經結束。
在上述結構中，我們並沒有看到任何屬性用以表徵每個entry的長度及其儲存的資料型別，如字串或者是整型值，而壓縮列表整體其實是乙個陣列，因而如果不對這兩個型別的資料進行記錄那麼將無法對每乙個entry進行區分。實際上，每個entry是由三部分組成：previous_entry_length、encoding和content。
1.previousqhthttdz_entry_length為乙個整型值，記錄了前乙個節點整體占用位元組的長度，當前乙個節點的長度小於254時，該屬性占用乙個位元組，當前乙個節點長度大於等於254時，該屬性則占用5個位元組，其第乙個位元組會儲存十進位制的0xfe，即十進位制的254，後四個位元組則儲存了前一節點的長度；
2.encoding屬性長度不定，其主要儲存了當前節點的編碼格式和節點的長度。當encoding屬性的最高兩位為00、01或10時，表示其儲存的是位元組陣列。其為00時qhthttdz，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時qhthttdz，那麼該節點就沒有content屬性，該節點的屬性值儲存在encoding屬性的後四個位上，並且其值要介於0~12之間。
3.content屬性儲存了該節點的實際的字串或整型資料。
本文標題: 詳解redis資料結構之壓縮列表
本文位址:
Redis 資料結構之 壓縮列表
壓縮列表是一塊連續的記憶體空間，元素之間緊挨著儲存，沒有任何冗餘空隙。struct ziplist entry 塊隨著容納的元素型別不同，也會有不一樣的結構。struct entry encoding 字段儲存了元素內容的編碼型別資訊，ziplist 通過這個欄位來決定後面的 content 內容的...
Redis資料結構之壓縮列表ziplist
原始碼版本 redis 5.0.4 ziplist是乙個特殊編碼的雙鏈表，他被設計出來用以節省記憶體,它可以同時儲存字串和整整形數，其中整數被編碼為實際整數，而不是一系列字元。它可以在o 1 的時間進行頭部的插入和尾部的插入，但是他的每次插入都需要進行記憶體的分配，耗時與表中節點數目有關。zipli...
redis資料結構 壓縮列表
但凡是名稱中有 壓縮 兩個字的，都是為了節約記憶體。壓縮列表也不例外。以下是壓縮列表的結構圖 zlbytes zltail zllen entry1 entry2 entryn zlend 說明 屬性 型別長度 用途zlbytes unit32 t 4bit 記錄整個ziplist占用的記憶體位元組...