曾經看到這麼一個案例，有一個團隊需要開發一個圖片儲存系統，要求這個系統能快速記錄圖片ID和圖片儲存物件ID，同時還需要能夠根據圖片的ID快速找到圖片儲存物件ID。我們假設用10位數來表示圖片ID和圖片儲存物件ID，例如圖片的ID為1101021043，它所對應的圖片儲存物件的ID為2301010051，可以看到圖片ID和圖片儲存ID正好是一一對應的，是典型的key-value形式，所以首先會想到直接使用String型別來儲存資料。把圖片ID和圖片儲存ID分別作為鍵值對的key和value來儲存。但是隨著儲存的資料量越來越大，Redis的記憶體的使用量也快速上升，結果遇到了大記憶體Redis例項因為生成RDB而響應變慢的問題。很顯然String型別並不是一種好的選擇，
那有什麼辦法可以降低記憶體消耗嗎？
String型別的資料結構
首先我們得先了解為什麼String儲存資料時所消耗的記憶體空間較大。在剛才的案例中，由於圖片ID和圖片儲存物件ID都是10位數，我們可以用兩個8位元組的Long型別來表示這兩個ID。所以一組圖片ID及其儲存物件ID的記錄，實際只需要16位元組就可以了。但是通過對Redis記憶體分析，一組圖片ID及其儲存物件ID卻佔用了64位元組，那為什麼String型別會用64位元組呢。其實，除了要記錄實際的資料，String型別還需要額外的記憶體空間來記錄資料的長度、空間使用資訊等，這些資訊也叫做後設資料。當實際儲存的資料較小時，後設資料的空間開銷就顯的比較大了。我們先來看一下String型別是如何儲存資料的。當你儲存64位有符號的整數時，String型別會把它儲存為一個8位元組的Long型別整數，這種儲存方式通常也叫作int編碼方式。但是，當你儲存的資料中包含字元時，String型別就會用簡單動態字串結構體(SDS)來儲存。如下圖所示：
-
len：4個位元組，表示buf的已用長度。
-
alloc：4個位元組，表示buf分配的長度，一般大於len。
-
buf：位元組陣列，儲存實際資料。為了表示陣列的結尾，Redis會自動在陣列最後新增一個”\0"。
可以看到，在SDS結構體中，除了有儲存實際資料的buf，還有len和alloc的額外後設資料的開銷。另外對於String型別來說，除了SDS的額外開銷外，還有一個叫做RedisObject結構體的開銷。因為Redis的資料型別有很多，不同的資料型別都有相同的後設資料要記錄（例如最後一次訪問時間），所以Redis會採用一個叫做RedisObject結構體來統一記錄這些後設資料。一個RedisObject包含了一個8位元組的後設資料和一個8位元組的指標，這個指標指向具體資料所在，例如String型別的SDS結構體所在的記憶體地址。如下圖所示：
為了節省記憶體空間，Redis對Long型別整數和SDS的記憶體佈局做了專門的設計。一方面，當儲存的是 Long 型別整數時，RedisObject 中的指標就直接賦值為整數資料了，這樣就不用額外的指標再指向整數了，節省了指標的空間開銷。另一方面，當儲存的是字串資料，並且字串小於等於 44 位元組時，RedisObject 中的後設資料、指標和 SDS 是一塊連續的記憶體區域，這樣就可以避免記憶體碎片。這種佈局方式也被稱為 embstr 編碼方式。當字串大於44位元組時，SDS的資料量就開始變多了，Redis 就不再把SDS 和
RedisObject 佈局在一起了，而是會給 SDS 分配獨立的空間，並用指標指向 SDS 結構。這種佈局方式被稱為 raw 編碼模式。如下圖所示：
現在我們來計算一下一對圖片ID和圖片儲存物件ID的記憶體的使用量。由於10位數的圖片ID和圖片儲存物件ID是Long型別整數，所以可以直接用int編碼的RedisObject儲存。相對應的RedisObject後設資料部分佔8位元組，指標部分被直接賦值為8位元組的整數了。此時，每個ID會使用16位元組，加起來一共是32位元組。但是，另外的 32 位元組去哪兒了呢？
由於Redis是使用全域性雜湊表來儲存所有的鍵值對，雜湊表的每一項是一個dictEntity的結構體來指向一個鍵值對。dictEntity由三個8位元組的指標組成，分別來指向key、value以及下一個dictEntity。如下圖所示。
由於Redis使用的記憶體分配庫為jemalloc，jemalloc在分配記憶體時，會根據申請的位元組數N，找一個比N大的，最接近N的2的冪次數作為分配的空間。
所以申請一個24位元組的dictEntity，實際會分配32個位元組。
到目前位置，你應該明白了為什麼String型別來儲存圖片ID和圖片儲存物件ID會佔用64個位元組了。一個有效資訊只有16個位元組，在使用String型別儲存時，卻要佔用64個位元組記憶體空間，有48個位元組用來儲存後設資料資訊了，這是不是極大的浪費了記憶體空間。那麼有沒有更加節省記憶體的方法呢？
用壓縮列表節省記憶體
Redis裡有一種叫做壓縮列表的結構，非常節省記憶體。我們先回顧一下壓縮列表的構成。表頭有三個欄位zlbytes、zllen和zltail，分別表示列表的長度、列表尾的偏移量以及列表中entry的個數。壓縮列表表尾有一個zlend，表示列表結束。如下圖所示。
由於壓縮列表採用一系列的entry儲存資料，這些entry會挨個兒放置在記憶體中，不需要再用額外的指標進行連線，這樣就可以節省指標所佔用的空間。每個entry由以下幾部分組成。
-
pre_len：表示前一個entry的長度。prev_len有兩種取值情況：1 位元組或 5 位元組。當上一個 entry 長度小於 254 位元組時，prev_len 取值為 1 位元組，否則，就取值為 5 位元組。
-
len：表示自身的長度，佔4個位元組。
-
encoding：表示編碼方式，佔1個位元組。
-
content：儲存實際資料。
假設我們使用entry來儲存圖片儲存物件ID(佔8個位元組)，此時，每個entry的prev_len佔用1個位元組就行，因為每一個entry的前一個entry的長度小於264位元組。這樣一來，一個圖片物件ID所佔用的記憶體大小是14（1+4+1+8）個位元組，實際上會分配16個位元組。
Redis裡基於壓縮列表實現了List、Hash和Sorted Set集合型別，這樣做的最大好處就是節省了dictEntity的記憶體開銷。對於String型別來說，一個鍵值對就有一個dictEntity，佔用32個位元組。對於集合型別來說，一個key對應了很多資料，卻只是佔用了一個dictEntity，這樣就節省了記憶體空間。
如何用集合型別儲存單值的鍵值對的資料
在儲存單值鍵值對的資料時，我們可以使用基於Hash型別的二級編碼方式。這裡所說的二級編碼，是指把單值的資料拆成兩部分，前一部分作為Hash的key，後一部分作為Hash的value。 以圖片的ID為1101021043，它所對應的圖片儲存物件的ID為2301010051為例，我們將圖片的ID的前7位（1101021）作為Hash型別的鍵，後3位（043）和圖片儲存物件ID為2301010051作為Hash型別的key和value。我們按照這種設計，在Redis中插入一條記錄，只佔用了16位元組，所以和使用String型別佔用64位元組對比，節省了很多空間。 最後，我們再思考一個問題，為什麼要把圖片ID的前7位作為Hash型別的鍵，後3位作為Hash型別的key呢。我們在Redis儲存結構裡介紹過Redis的Hash型別的兩種底層實現結構，分別是壓縮列表和雜湊表。Hash 型別設定了用壓縮列表儲存資料時的兩個閾值，一旦超過了閾值，Hash 型別就會用雜湊表來儲存資料了。這兩個閾值分別對應以下兩個配置項：
-
hash-max-ziplist-entries：表示用壓縮列表儲存時雜湊集合中的最大元素個數。
-
hash-max-ziplist-value：表示用壓縮列表儲存時雜湊集合中單個元素的最大長度。
在記憶體節省空間方面，雜湊表就沒有壓縮列表那麼高效。我們只用後3位作為Hash型別的key，也就保證雜湊集合中元素的個數不會超過1000，同時我們通過設定hash-max-ziplist-entries=1000，來確保Hash型別底層使用的是壓縮列表這種資料結構。
好了，今天的介紹就到這裡。更多硬核知識，請關注公序員學長 。
