[[412795]]

曾經看到這么一個案例，有一個團隊需要開發一個圖片存儲系統，要求這個系統能快速記錄圖片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-max-ziplist-entries：表示用壓縮列表保存時哈希集合中的最大元素個數。

• hash-max-ziplist-value：表示用壓縮列表保存時哈希集合中單個元素的最大長度。

在內存節省空間方面，哈希表就沒有壓縮列表那么高效。我們只用后3位作為Hash類型的key，也就保證哈希集合中元素的個數不會超過1000，同時我們通過設置hash-max-ziplist-entries=1000，來確保Hash類型底層使用的是壓縮列表這種數據結構。