在討論Redis內存壓縮的時候，我們需要了解一下幾個Redis的相關知識。

壓縮列表 ziplist

---

Redis的ziplist是用一段連續的內存來存儲列表數據的一個數據結構，它的結構示例如下圖

壓縮列表組成示例--截圖來自《Redis設計與實現》

zlbytes: 記錄整個壓縮列表使用的內存大小

zltail: 記錄壓縮列表表尾距離起始位置有多少字節

zllen: 記錄壓縮列表節點數量，值得注意的一點是，因為它只占了2個字節，所以最大值只能到65535，這意味著壓縮列表長度大于65535的時候，就只能通過遍歷整個列表來計算長度了

zleng: 壓縮列表末端標志位，固定值為OxFF

entry1-N: 壓縮列表節點, 具體結構如下圖

壓縮列表節點組成示例--截圖來自《Redis設計與實現》

其中

previous_entry_length: 上一個節點的長度

encoding: content的編碼以及長度

content: 節點數據

當我們查找一個節點的時候，主要進行一下操作:

根據zltail獲取最后一個節點的位置

判斷當前節點是否是目標節點

如果是，則返回數據

如果不是，則根據previous_entry_length計算上一個節點的起始位置，然后重新進行步驟2判斷

通過上述的描述，我們可以知道，ziplist每次數據更新的復雜度大約是O(N)，因為它需要對N個節點進行內存重分配，查找一個數據的時候，復雜度是O(N)，最壞情況下需要遍歷整個列表。

?

什么情況下會使用到ziplist呢？

---

Redis會使用到ziplist的數據結構是Hash與List。

Hash結構使用ziplist作為底層存儲的兩個條件是:

所有的鍵與值的字符串長度都小于64字節的時候

鍵與值對數據小于512個

只要上述條件任何一個不滿足，Redis就會自動將這個Hash對象從ziplist轉換成hashtable。但這兩個閾值可以通過修改配置文件中的hash-max-ziplist-value與hash-max-ziplist-entries來變更。

List結構使用ziplist的條件與Hash結構一樣，當條件不滿足的時候，會從ziplist轉換成linkedlist，同樣我們可以修改list-max-ziplist-value與hash-max-ziplist-entries來使用不同的閾值。

為什么Hash與List會使用ziplist來存儲數據呢？

因為

ziplist會比hashtable與ziplist節省跟多的內存

內存中以連續塊方式保存的數據比起hashtable與linkedlist使用的鏈表可以更快的載入緩存中

當ziplist的長度比較小的時候，從ziplist讀寫數據的效率比hashtable或者linkedlist的差異并不大。

本質上，使用ziplist就是以時間換空間的一種優化，但是他的時間損壞小到幾乎可以忽略不計，但卻能帶來可觀的內存減少，所以滿足條件時，Redis會使用ziplist作為Hash與List的存儲結構。

?

實戰

---

我們先拋出問題，在廣告程序化交易的過程中，我們經常需要為一個廣告投放計劃定制人群包，其存儲的形式如下:

人群包ID?=>?[設備ID_1,?設備ID_2?...?設備ID_N]

其中，人群包ID是Long型整數，設備ID是經過MD5處理，長度為32。
在業務場景中，我們需要判斷一個設備ID是否在一個人群包中，來決定是否投放廣告。

在傳統的使用Redis的場景, 我們可以使用標準的KV結構來存儲定向包數據，則存儲方式如下:

{人群包ID}_{設備ID_1}?=>?true {人群包ID}_{設備ID_2}?=>?true

如果我們想使用ziplist來繼續內存壓縮的話，我們必須保證Hash對象的長度小于512，并且鍵值的長度小于64字節。 我們可以將KV結構的數據，存儲到預先分配好的bucket中。

我們先預估下，整個Redis集群預計容納的數據條數為10億，那么Bucket的數量的計算公式如下:

bucket_count?=?10億?/?512?=?195W

那么我們大概需要200W個Bucket(預估Bucket數量需要多預估一點，以防觸發臨界值問題）
我們先以下公式計算BucketID:

bucket_id?=?CRC32(人群包ID?+?"_"?+?設備ID)?%?200W

那么數據在Redis的存儲結構就變成

bucket_id?=>?{{人群包ID}_{設備ID_1}?=>?true{人群包ID}_{設備ID_2}?=>?true }

這樣我們保證每個bucket中的數據項都小于512，并且長度均小于64字節。

我們以2000W數據進行測試，前后兩者的內存使用情況如下:

數據集大小存儲模式Bucket數量所用內存碎片率Redis占用的內存

2000W	壓縮列表	200W	928M	1.38	1.25G
2000W	壓縮列表	5W	785M	1.48	1.14G
2000W	直接存儲	-	1.44G	1.03	1.48G

在這里需要額外引入一個概念 – 內存碎片率。

內存碎片率?=?操作系統給Redis分配的內存?/?Redis存儲對象占用的內存

因為壓縮列表在更新節點的時候，經常需要進行內存重分配，所以導致比較高的內存碎片率。我們在做技術方案比較的時候，內存碎片率也是非常需要關注的指標之一。

但有很多手段可以減少內存碎片率，比如內存對其，甚至更極端的直接重做整個Redis內存（利用快照或者從節點來重做內存）都能有效的減低內存碎片率。

我們在本次實驗中，因為存儲的數值比較大（單個KEY約34個字節），所以實際節省內存不是很多，但依然能節約35%-50%的內存使用。

在實際的生產環境中，我們根據應用場景合理的設計壓縮存儲結構，部分業務甚至能達到節約70%的內存使用的效果。

?

壓縮列表能節省多少內存？

---

我們現在知道壓縮列表是通過將節點緊湊的排列在內存中，從而節省掉內存的。但他究竟節省了哪些內存從而能達到驚人的壓縮率呢？

首先為了明白這個細節，我們需要知道普通Key-Value結構在Redis中是如何存儲的。

typedef?struct?redisObject?{unsigned?type:4;????????//?對象的類型unsigned?encoding:4;????//?對象的編碼unsigned?lru:LRU_BITS;??//?LRU類型int?refcount;???????????//?引用計數void?*ptr;??????????????//?指向底層數據結構的指針 }?robj;

Redis所有的對象都是通過上述結構來存儲, 假設我存儲Hello=>World這樣一個健值對到Redis中，除了存儲本身鍵值的數據外，還需要額外的24個字節來存儲redisObject對象。

而Redis存儲字符串使用的SDS數據結構

struct?sdshdr8?{uint8_t?len;????????//?所保存字符串的長度uint8_t?alloc;??????//?分配的內存數量unsigned?char?flags;//?標志位，用于判斷sdshdr類型char?buf[];?????????//?字節數組，用戶保存字符串 };

假如字符串的長度無法用unsigned int8來表示的話，Redis會使用能表達更大長度的sdshdr16結構來存儲字符串。

并且，為了減少修改字符串帶來的內存重分類問題，Redis會進行內存預分配，所以可能你僅僅為了保存五個字符，但Redis會為你預分配10 bytes的內存。

這意味著當我們存儲Hello這個字符串的時候，你需要額外的3個以上的字節。

Oh~~~，我只想保存Hello=>World這十個字符的數據，竟然需要的30~40個字節的數據來存儲額外的信息，比存儲數據本身的大小還多一些。這還沒包括Redis維護字典表所需要的額外的內存空間。

那么假設我們用ziplist來存儲這個數據，我們僅僅需要額外的2個字節用于存儲previous_entry_length與encoding。具體的計算方式可以參考Redis源碼或者《Redis設計與實現》第一部分第7章壓縮列表。

?

總結

---

從以上對比，我們可以看出，在存儲越小的數據的時候，使用ziplist來進行數據壓縮能得到更好的壓縮率。
但副作用也很明顯，ziplist的更新效率遠遠低于普通K-V模式，并且會造成額外的內存碎片率。

在Redis中存儲大量數據的實踐過程中，我們經常會做一些小技巧來盡可能壓榨Redis的存儲能力。接下來準備寫一篇Redis內存壓縮的小技巧。

總結

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

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