ziplist

• • 什么是ziplist?
  • ziplist結構
  • entry節點的結構
  • 添加或者刪除引起的連鎖更新

什么是ziplist?

顧名思義ziplist就是壓縮鏈表, 壓縮鏈表就是為節省內存而生的
因為Redis是基于內存的數據庫, 所以讀取或者寫入的速度很快, 但由于內存資源有限, 所以我們要盡可能的節約內存, 于是Redis官方就創建出了ziplist這一節省內存的結構

ziplist結構

下面我們來看一下ziplist的結構

• zlbytes: ziplist的長度（單位: 字節)，是一個32位無符號整數
• zltail: ziplist最后一個節點的偏移量，反向遍歷ziplist或者pop尾部節點的時候有用。
• zllen: ziplist的節點（entry）個數
• entry : ziplist中間儲存的節點
• zlend : 標記ziplist結尾

entry節點的結構

• previous-entry_length : 用來存儲上一個節點的長度, 當前以節點的長度小于254字節時, 本身的長度為1字節, 當前一節點的長度大于等于254時,自身長度為5字節
• encoding : 編碼 不同類型的編碼代表這個節點存儲的內容和長度是什么
• content : 內容, 這里就是具體存儲數據的地方
  encoding按照下圖規則來可以看出來具體content存儲的是什么
  

添加或者刪除引起的連鎖更新

e1~en節點的長度均介于250 ~253之間, 當我在頭部新加了一個節點他的長度是254字節, 那么e1就要更新他的previous_entry_length屬性, 要把原來1字節更新為5字節, 這樣一更新, e2也要更新e1的長度, 這樣就引起了連鎖反應

當big節點長度大于等于254時, small節點的存儲前一節點長度的大小是5字節, 但我們將small節點刪除后, e1存儲前一個節點的長度就不夠了, 這樣就需要更新, e1一更新, e2也要更新, 這樣就又發送了連鎖反應

連鎖更新造成的影響:

在最壞情況下連鎖更新對ziplist執行了N次重新分配

每次重新分配需要O(N)的時間, 那么就消耗了O(N^2)的時間
當然連鎖更新出現的概率很低, 并且當節點較少時, 出現連鎖更新對性能影響不大

總結

以上是生活随笔為你收集整理的Redis之压缩链表ziplist的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。