壓縮列表（ziplist）是列表鍵和雜湊鍵的底層實現之一。
當列表鍵只包含少量列表項，並且每個列表項或者是小整數值，或者是長度比較短的字串，redis會使用壓縮列表作為列表鍵的底層實現。
當雜湊鍵只包含少量鍵值對，並且每個鍵值對的鍵和值，要麼是小整數值，要麼是長度比較短的字串，redis會使用壓縮列表作為雜湊鍵的底層實現。
壓縮列表結構：
下圖是對壓縮列表各個部分的介紹：
如上圖所示，壓縮列表起始位址的指標為p，zltail為0xb3(十進位制為179)，即可計算出表尾節點entry5的位址。
節點結構如下
previous_entry_length：記錄壓縮列表前乙個節點的長度。以位元組為單位，取值1位元組或者5位元組。如果前乙個位元組長度小於254，則previous_entry_length屬性的長度為1位元組；如果前乙個位元組長度大於等於254，則previous_entry_length屬性的長度為5位元組，第乙個位元組設定為0xfe（十進位制254），後四個節點記錄前乙個節點的長度。
encoding：記錄節點content屬性所儲存資料的型別和長度。
content：儲存節點的值。
一位元組、兩位元組或五位元組長，值的最高位為00、01或10的是位元組陣列編碼：該編碼表示節點的content屬性儲存著位元組陣列，陣列的長度由編碼去除最高兩位之後的其他位記錄；
一位元組長，值的最高位以11開頭的是整數編碼：該編碼表示節點的content屬性儲存著整數值，整數值的型別和長度由編碼去除最高兩位之後的其他位記錄。
特殊場景：在乙個壓縮列表中，有多個連續的、長度介於250位元組到253位元組之間的節點e1-en，如下圖所示。
現在，將乙個長度大於等於254位元組的新節點new設定為頭節點，則new節點將成為e1的前置節點，如下圖所示。
因為e1節點的previous_entry_length屬性為1位元組，無法記錄新節點new的長度，所以程式將對壓縮列表執行空間重分配操作，將previous_entry_length屬性從1位元組擴充套件到5位元組。
擴充套件之後e1的長度也大於等於254，e2節點也需要擴充套件空間，以此類推，直到en結束。
Redis底層資料結構 壓縮列表
redis 中的壓縮列表是由一系列特殊編碼的連續記憶體塊組成的順序型資料結構。列表中每個節點可以儲存乙個位元組陣列或者乙個整數值。它的存在主要是為了節約記憶體。壓縮列表在 redis 中主要作為了 list 列表和 hash 雜湊兩種資料結構的底層實現之一。在 list 列表中，要是列表中的儲存元素...
Redis底層資料結構 六 壓縮列表
壓縮列表 ziplist 是列表鍵和雜湊鍵的底層實現之一。當乙個列表鍵只包含少量列表項，並且每個列表項要麼是小整數值，要麼就是長度比較短的字串，redis就會使用壓縮列表來做列表鍵的底層實現。壓縮列表是redis為了節約記憶體而開發的，是由一系列編碼的聯絡記憶體塊組成的順序性資料結構。乙個壓縮列表可...
redis 底層資料結構 壓縮列表 ziplist
壓縮列表是列表鍵和雜湊鍵的底層實現之一。當乙個列表鍵只包含少量列表項，並且每個列表項要麼就是小整數，要麼就是長度比較短的字串，redis就會使用壓縮列表來做列表鍵的底層實現 當乙個雜湊鍵只包含少量鍵值對，並且每個鍵值對的鍵和值要麼就是小整數值，要麼就是長度比較短的字串，那麼redis就會使用壓縮列表...