Redis中一個String類型引發(fā)的慘案

​ 曾經(jīng)看到這么一個案例，有一個團(tuán)隊需要開發(fā)一個圖片存儲系統(tǒng)，要求這個系統(tǒng)能快速記錄圖片ID和圖片存儲對象ID，同時還需要能夠根據(jù)圖片的ID快速找到圖片存儲對象ID。我們假設(shè)用10位數(shù)來表示圖片ID和圖片存儲對象ID，例如圖片的ID為1101021043，它所對應(yīng)的圖片存儲對象的ID為2301010051，可以看到圖片ID和圖片存儲ID正好是一一對應(yīng)的，是典型的key-value形式，所以首先會想到直接使用String類型來保存數(shù)據(jù)。把圖片ID和圖片存儲ID分別作為鍵值對的key和value來保存。但是隨著存儲的數(shù)據(jù)量越來越大，Redis的內(nèi)存的使用量也快速上升，結(jié)果遇到了大內(nèi)存Redis實例因為生成RDB而響應(yīng)變慢的問題。很顯然String類型并不是一種好的選擇，

那有什么辦法可以降低內(nèi)存消耗嗎？

String類型的數(shù)據(jù)結(jié)構(gòu)

首先我們得先了解為什么String保存數(shù)據(jù)時所消耗的內(nèi)存空間較大。在剛才的案例中，由于圖片ID和圖片存儲對象ID都是10位數(shù)，我們可以用兩個8字節(jié)的Long類型來表示這兩個ID。所以一組圖片ID及其存儲對象ID的記錄，實際只需要16字節(jié)就可以了。但是通過對Redis內(nèi)存分析，一組圖片ID及其存儲對象ID卻占用了64字節(jié)，那為什么String類型會用64字節(jié)呢。其實，除了要記錄實際的數(shù)據(jù)，String類型還需要額外的內(nèi)存空間來記錄數(shù)據(jù)的長度、空間使用信息等，這些信息也叫做元數(shù)據(jù)。當(dāng)實際保存的數(shù)據(jù)較小時，元數(shù)據(jù)的空間開銷就顯的比較大了。我們先來看一下String類型是如何保存數(shù)據(jù)的。當(dāng)你保存64位有符號的整數(shù)時，String類型會把它保存為一個8字節(jié)的Long類型整數(shù)，這種保存方式通常也叫作int編碼方式。但是，當(dāng)你保存的數(shù)據(jù)中包含字符時，String類型就會用簡單動態(tài)字符串結(jié)構(gòu)體(SDS)來保存。如下圖所示：

• len：4個字節(jié)，表示buf的已用長度。
• alloc：4個字節(jié)，表示buf分配的長度，一般大于len。
• buf：字節(jié)數(shù)組，保存實際數(shù)據(jù)。為了表示數(shù)組的結(jié)尾，Redis會自動在數(shù)組最后添加一個”\0"。

可以看到，在SDS結(jié)構(gòu)體中，除了有保存實際數(shù)據(jù)的buf，還有l(wèi)en和alloc的額外元數(shù)據(jù)的開銷。另外對于String類型來說，除了SDS的額外開銷外，還有一個叫做RedisObject結(jié)構(gòu)體的開銷。因為Redis的數(shù)據(jù)類型有很多，不同的數(shù)據(jù)類型都有相同的元數(shù)據(jù)要記錄（例如最后一次訪問時間），所以Redis會采用一個叫做RedisObject結(jié)構(gòu)體來統(tǒng)一記錄這些元數(shù)據(jù)。一個RedisObject包含了一個8字節(jié)的元數(shù)據(jù)和一個8字節(jié)的指針，這個指針指向具體數(shù)據(jù)所在，例如String類型的SDS結(jié)構(gòu)體所在的內(nèi)存地址。如下圖所示：

為了節(jié)省內(nèi)存空間，Redis對Long類型整數(shù)和SDS的內(nèi)存布局做了專門的設(shè)計。一方面，當(dāng)保存的是 Long 類型整數(shù)時，RedisObject 中的指針就直接賦值為整數(shù)數(shù)據(jù)了，這樣就不用額外的指針再指向整數(shù)了，節(jié)省了指針的空間開銷。另一方面，當(dāng)保存的是字符串?dāng)?shù)據(jù)，并且字符串小于等于 44 字節(jié)時，RedisObject 中的元數(shù)據(jù)、指針和 SDS 是一塊連續(xù)的內(nèi)存區(qū)域，這樣就可以避免內(nèi)存碎片。這種布局方式也被稱為 embstr 編碼方式。當(dāng)字符串大于44字節(jié)時，SDS的數(shù)據(jù)量就開始變多了，Redis 就不再把SDS 和

RedisObject 布局在一起了，而是會給 SDS 分配獨(dú)立的空間，并用指針指向 SDS 結(jié)構(gòu)。這種布局方式被稱為 raw 編碼模式。如下圖所示：

現(xiàn)在我們來計算一下一對圖片ID和圖片存儲對象ID的內(nèi)存的使用量。由于10位數(shù)的圖片ID和圖片存儲對象ID是Long類型整數(shù)，所以可以直接用int編碼的RedisObject保存。相對應(yīng)的RedisObject元數(shù)據(jù)部分占8字節(jié)，指針部分被直接賦值為8字節(jié)的整數(shù)了。此時，每個ID會使用16字節(jié)，加起來一共是32字節(jié)。但是，另外的 32 字節(jié)去哪兒了呢？

由于Redis是使用全局哈希表來保存所有的鍵值對，哈希表的每一項是一個dictEntity的結(jié)構(gòu)體來指向一個鍵值對。dictEntity由三個8字節(jié)的指針組成，分別來指向key、value以及下一個dictEntity。如下圖所示。

由于Redis使用的內(nèi)存分配庫為jemalloc，jemalloc在分配內(nèi)存時，會根據(jù)申請的字節(jié)數(shù)N，找一個比N大的，最接近N的2的冪次數(shù)作為分配的空間。

所以申請一個24字節(jié)的dictEntity，實際會分配32個字節(jié)。

到目前位置，你應(yīng)該明白了為什么String類型來保存圖片ID和圖片存儲對象ID會占用64個字節(jié)了。一個有效信息只有16個字節(jié)，在使用String類型保存時，卻要占用64個字節(jié)內(nèi)存空間，有48個字節(jié)用來保存元數(shù)據(jù)信息了，這是不是極大的浪費(fèi)了內(nèi)存空間。那么有沒有更加節(jié)省內(nèi)存的方法呢？

用壓縮列表節(jié)省內(nèi)存

Redis里有一種叫做壓縮列表的結(jié)構(gòu)，非常節(jié)省內(nèi)存。我們先回顧一下壓縮列表的構(gòu)成。表頭有三個字段zlbytes、zllen和zltail，分別表示列表的長度、列表尾的偏移量以及列表中entry的個數(shù)。壓縮列表表尾有一個zlend，表示列表結(jié)束。如下圖所示。

由于壓縮列表采用一系列的entry保存數(shù)據(jù)，這些entry會挨個兒放置在內(nèi)存中，不需要再用額外的指針進(jìn)行連接，這樣就可以節(jié)省指針?biāo)加玫目臻g。每個entry由以下幾部分組成。

• pre_len：表示前一個entry的長度。prev_len有兩種取值情況：1 字節(jié)或 5 字節(jié)。當(dāng)上一個 entry 長度小于 254 字節(jié)時，prev_len 取值為 1 字節(jié)，否則，就取值為 5 字節(jié)。
• len：表示自身的長度，占4個字節(jié)。
• encoding：表示編碼方式，占1個字節(jié)。
• content：保存實際數(shù)據(jù)。

假設(shè)我們使用entry來保存圖片存儲對象ID(占8個字節(jié))，此時，每個entry的prev_len占用1個字節(jié)就行，因為每一個entry的前一個entry的長度小于264字節(jié)。這樣一來，一個圖片對象ID所占用的內(nèi)存大小是14（1+4+1+8）個字節(jié)，實際上會分配16個字節(jié)。

Redis里基于壓縮列表實現(xiàn)了List、Hash和Sorted Set集合類型，這樣做的最大好處就是節(jié)省了dictEntity的內(nèi)存開銷。對于String類型來說，一個鍵值對就有一個dictEntity，占用32個字節(jié)。對于集合類型來說，一個key對應(yīng)了很多數(shù)據(jù)，卻只是占用了一個dictEntity，這樣就節(jié)省了內(nèi)存空間。

如何用集合類型存儲單值的鍵值對的數(shù)據(jù)

在保存單值鍵值對的數(shù)據(jù)時，我們可以使用基于Hash類型的二級編碼方式。這里所說的二級編碼，是指把單值的數(shù)據(jù)拆成兩部分，前一部分作為Hash的key，后一部分作為Hash的value。 以圖片的ID為1101021043，它所對應(yīng)的圖片存儲對象的ID為2301010051為例，我們將圖片的ID的前7位（1101021）作為Hash類型的鍵，后3位（043）和圖片存儲對象ID為2301010051作為Hash類型的key和value。我們按照這種設(shè)計，在Redis中插入一條記錄，只占用了16字節(jié)，所以和使用String類型占用64字節(jié)對比，節(jié)省了很多空間。 最后，我們再思考一個問題，為什么要把圖片ID的前7位作為Hash類型的鍵，后3位作為Hash類型的key呢。我們在Redis存儲結(jié)構(gòu)里介紹過Redis的Hash類型的兩種底層實現(xiàn)結(jié)構(gòu)，分別是壓縮列表和哈希表。Hash 類型設(shè)置了用壓縮列表保存數(shù)據(jù)時的兩個閾值，一旦超過了閾值，Hash 類型就會用哈希表來保存數(shù)據(jù)了。這兩個閾值分別對應(yīng)以下兩個配置項：

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

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

到此這篇關(guān)于Redis中一個String類型引發(fā)的慘案的文章就介紹到這了,更多相關(guān)Redis String類型內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！