redis--內部結構--ziplist

壓縮列表是列表鍵和雜湊鍵的底層實現之一。
壓縮列表是Redis為了節約記憶體而開發的，是由一系列特殊編碼的連續記憶體塊組成的順序型資料結構。
1、壓縮列表的構成


2、壓縮列表節點的構成

<1>previous_entry_length
以位元組為單位，記錄了壓縮列表中前一個節點的長度。可以是1位元組或者5位元組；前一個節點小於254Byte就可以用1位元組儲存，前一個位元組大於等於254Byte就可以用5位元組儲存它的長度。利用這個長度，可以將壓縮列表從頭遍曆到尾，或者從給定指標遍曆到頭或者尾；
<2>encoding
記錄了節點的content屬性所儲存資料的類型以及長度；一位元組、兩位元組、五位元組長；值的最高位為00、01、10表示的是位元組數組編碼；除了最高位記錄的類型，剩下的位記錄的是位元組數組的長度；一位元組，值的最高位以11開頭，表示整數編碼；
<3>content
儲存節點的值；

3、連鎖更新
為了滿足前一節點，擴增當前節點，最後導致整個列表的每個節點都得更新節點的大小，這就是連鎖更新；新增或者刪除節點都有可能引起連鎖更新。
導致連鎖更新的原因：
<1>首先，壓縮列表裡要恰好有多個連續的、長度介於250位元組至253位元組之間的節點，連鎖更新才有可能發生，在實際中，這種情況並不多見；
<2>其次，即使出現連鎖更新，但只要被更新的節點的數量不多，就不會對效能造成任何影響；

引用《Redis設計與實現》