# 前言 ```properties 本文GitHub已收錄：https://zhouwenxing.github.io/ ``` 正常情況下我們選擇使用 `Redis` 就是為了提升查詢速度，然而讓人意外的是，`Redis` 當中卻有一種比較有意思的資料結構，這種資料結構通過犧牲部分讀寫速度來達到節省記憶體的目的，這就是 `ziplist`（壓縮列表），`Redis` 為什麼要這麼做呢？難道真的是覺得自己的速度太快了，犧牲一點速度也不影響嗎？ # 什麼是壓縮列表 `ziplist` 是為了節省記憶體而設計出來的一種資料結構。`ziplist` 是由一系列特殊編碼組成的連續記憶體塊的順序型資料結構，一個 `ziplist` 可以包含任意多個 `entry`，而每一個 `entry` 又可以儲存一個位元組陣列或者一個整數值。 `ziplist` 作為一種列表，其和普通的雙端列表，如 `linkedlist` 的最大區別就是 `ziplist` 並不儲存前後節點的指標，而 `linkedlist` 一般每個節點都會維護一個指向前置節點和一個指向後置節點的指標。那麼 `ziplist` 不維護前後節點的指標，它又是如何尋找前後節點的呢？ `ziplist` 雖然不維護前後節點的指標，但是它卻維護了上一個節點的長度和當前節點的長度，然後每次通過長度來計算出前後節點的位置。既然涉及到了計算，那麼相對於直接儲存指標的方式肯定有效能上的損耗，這就是一種典型的用**時間來換取空間**的做法。因為每次讀取前後節點都需要經過計算才能得到前後節點的位置，所以會消耗更多的時間，而在 `Redis` 中，一個指標是佔了 `8` 個位元組，但是大部分情況下，如果直接儲存長度是達不到 `8` 個位元組的，所以採用儲存長度的設計方式在大部分場景下是可以節省記憶體空間的。 # ziplist 的儲存結構 `ziplist` 的組成結構為： ```pro