一文帶你深刻理解 Redis 內存模型！

Redis 是目前最火爆的內存數據庫之一，經過在內存中讀寫數據，大大提升了讀寫速度，能夠說 Redis 是實現網站高併發不可或缺的一部分。

咱們使用 Redis 時，會接觸 Redis 的 5 種對象類型（字符串、哈希、列表、集合、有序集合），豐富的類型是 Redis 相對於 Memcached 等的一大優點。 

在瞭解 Redis 的 5 種對象類型的用法和特色的基礎上，進一步瞭解 Redis 的內存模型，對 Redis 的使用有很大幫助，例如：

• 估算 Redis 內存使用量。目前爲止，內存的使用成本仍然相對較高，使用內存不能無所顧忌；根據需求合理的評估 Redis 的內存使用量，選擇合適的機器配置，能夠在知足需求的狀況下節約成本。

• 優化內存佔用。瞭解 Redis 內存模型能夠選擇更合適的數據類型和編碼，更好的利用 Redis 內存。

• 分析解決問題。當 Redis 出現阻塞、內存佔用等問題時，儘快發現致使問題的緣由，便於分析解決問題。

這篇文章主要介紹 Redis 的內存模型（以 3.0 爲例），包括 Redis 佔用內存的狀況及如何查詢、不一樣的對象類型在內存中的編碼方式、內存分配器(jemalloc)、簡單動態字符串(SDS)、RedisObject 等；而後在此基礎上介紹幾個 Redis 內存模型的應用。

Redis 內存統計

工欲善其事必先利其器，在說明 Redis 內存以前首先說明如何統計 Redis 使用內存的狀況。

在客戶端經過 redis-cli 鏈接服務器後（後面如無特殊說明，客戶端一概使用redis-cli），經過 info 命令能夠查看內存使用狀況：info memory。

其中，info 命令能夠顯示 Redis 服務器的許多信息，包括服務器基本信息、CPU、內存、持久化、客戶端鏈接信息等等；Memory 是參數，表示只顯示內存相關的信息。

返回結果中比較重要的幾個說明以下：

used_memory

Redis 分配器分配的內存總量（單位是字節），包括使用的虛擬內存（即 swap）；Redis 分配器後面會介紹。used_memory_human 只是顯示更友好。

used_memory_rss

Redis 進程佔據操做系統的內存（單位是字節），與 top 及 ps 命令看到的值是一致的。

除了分配器分配的內存以外，used_memory_rss 還包括進程運行自己須要的內存、內存碎片等，可是不包括虛擬內存。

所以，used_memory 和 used_memory_rss，前者是從 Redis 角度獲得的量，後者是從操做系統角度獲得的量。

兩者之因此有所不一樣，一方面是由於內存碎片和 Redis 進程運行須要佔用內存，使得前者可能比後者小，另外一方面虛擬內存的存在，使得前者可能比後者大。

因爲在實際應用中，Redis 的數據量會比較大，此時進程運行佔用的內存與 Redis 數據量和內存碎片相比，都會小得多。

所以 used_memory_rss 和 used_memory 的比例，便成了衡量 Redis 內存碎片率的參數；這個參數就是 mem_fragmentation_ratio。

mem_fragmentation_ratio

內存碎片比率，該值是 used_memory_rss / used_memory 的比值。

mem_fragmentation_ratio 通常大於 1，且該值越大，內存碎片比例越大；mem_fragmentation_ratio<1，說明 Redis 使用了虛擬內存，因爲虛擬內存的媒介是磁盤，比內存速度要慢不少。

當這種狀況出現時，應該及時排查，若是內存不足應該及時處理，如增長 Redis 節點、增長 Redis 服務器的內存、優化應用等。

通常來講，mem_fragmentation_ratio 在 1.03 左右是比較健康的狀態（對於 jemalloc 來講）。

上面截圖中的 mem_fragmentation_ratio 值很大，是由於尚未向 Redis 中存入數據，Redis 進程自己運行的內存使得 used_memory_rss 比 used_memory 大得多。

mem_allocator

Redis 使用的內存分配器，在編譯時指定；能夠是 libc 、jemalloc 或者 tcmalloc，默認是 jemalloc；截圖中使用的即是默認的 jemalloc。

Redis 內存劃分

Redis 做爲內存數據庫，在內存中存儲的內容主要是數據（鍵值對）；經過前面的敘述能夠知道，除了數據之外，Redis 的其餘部分也會佔用內存。

Redis 的內存佔用主要能夠劃分爲如下幾個部分：

數據

做爲數據庫，數據是最主要的部分；這部分佔用的內存會統計在 used_memory 中。

Redis 使用鍵值對存儲數據，其中的值（對象）包括 5 種類型，即字符串、哈希、列表、集合、有序集合。

這 5 種類型是 Redis 對外提供的，實際上，在 Redis 內部，每種類型可能有 2 種或更多的內部編碼實現。

此外，Redis 在存儲對象時，並非直接將數據扔進內存，而是會對對象進行各類包裝：如 RedisObject、SDS 等；這篇文章後面將重點介紹 Redis 中數據存儲的細節。

進程自己運行須要的內存

Redis 主進程自己運行確定須要佔用內存，如代碼、常量池等等；這部份內存大約幾兆，在大多數生產環境中與 Redis 數據佔用的內存相比能夠忽略。

這部份內存不是由 jemalloc 分配，所以不會統計在 used_memory 中。

補充說明：除了主進程外，Redis 建立的子進程運行也會佔用內存，如 Redis 執行 AOF、RDB 重寫時建立的子進程。

固然，這部份內存不屬於 Redis 進程，也不會統計在 used_memory 和 used_memory_rss 中。

緩衝內存

緩衝內存包括客戶端緩衝區、複製積壓緩衝區、AOF 緩衝區等；其中，客戶端緩衝區存儲客戶端鏈接的輸入輸出緩衝；複製積壓緩衝區用於部分複製功能；AOF 緩衝區用於在進行 AOF 重寫時，保存最近的寫入命令。

在瞭解相應功能以前，不須要知道這些緩衝的細節；這部份內存由 jemalloc 分配，所以會統計在 used_memory 中。

內存碎片

內存碎片是 Redis 在分配、回收物理內存過程當中產生的。例如，若是對數據的更改頻繁，並且數據之間的大小相差很大，可能致使 Redis 釋放的空間在物理內存中並無釋放。

但 Redis 又沒法有效利用，這就造成了內存碎片，內存碎片不會統計在 used_memory 中。

內存碎片的產生與對數據進行的操做、數據的特色等都有關；此外，與使用的內存分配器也有關係：若是內存分配器設計合理，能夠儘量的減小內存碎片的產生。後面將要說到的 jemalloc 便在控制內存碎片方面作的很好。

若是 Redis 服務器中的內存碎片已經很大，能夠經過安全重啓的方式減少內存碎片：由於重啓以後，Redis 從新從備份文件中讀取數據，在內存中進行重排，爲每一個數據從新選擇合適的內存單元，減少內存碎片。

Redis 數據存儲的細節

關於 Redis 數據存儲的細節，涉及到內存分配器（如 jemalloc）、簡單動態字符串（SDS）、5 種對象類型及內部編碼、RedisObject。在講述具體內容以前，先說明一下這幾個概念之間的關係。

下圖是執行 set hello world 時，所涉及到的數據模型：

 

dictEntry：Redis 是 Key-Value 數據庫，所以對每一個鍵值對都會有一個 dictEntry，裏面存儲了指向 Key 和 Value 的指針；next 指向下一個 dictEntry，與本 Key-Value 無關。

Key：圖中右上角可見，Key（」hello」）並非直接以字符串存儲，而是存儲在 SDS 結構中。

RedisObject：Value(「world」)既不是直接以字符串存儲，也不是像 Key 同樣直接存儲在 SDS 中，而是存儲在 RedisObject 中。

實際上，不論 Value 是 5 種類型的哪種，都是經過 RedisObject 來存儲的；而 RedisObject 中的 type 字段指明瞭 Value 對象的類型，ptr 字段則指向對象所在的地址。

不過能夠看出，字符串對象雖然通過了 RedisObject 的包裝，但仍然須要經過 SDS 存儲。

實際上，RedisObject 除了 type 和 ptr 字段之外，還有其餘字段圖中沒有給出，如用於指定對象內部編碼的字段。

jemalloc：不管是 DictEntry 對象，仍是 RedisObject、SDS 對象，都須要內存分配器（如 jemalloc）分配內存進行存儲。

以 DictEntry 對象爲例，有 3 個指針組成，在 64 位機器下佔 24 個字節，jemalloc 會爲它分配 32 字節大小的內存單元。

下面來分別介紹 jemalloc、RedisObject、SDS、對象類型及內部編碼。

jemalloc

Redis 在編譯時便會指定內存分配器；內存分配器能夠是 libc 、jemalloc 或者 tcmalloc，默認是 jemalloc。

jemalloc 做爲 Redis 的默認內存分配器，在減少內存碎片方面作的相對比較好。

jemalloc 在 64 位系統中，將內存空間劃分爲小、大、巨大三個範圍；每一個範圍內又劃分了許多小的內存塊單位；當 Redis 存儲數據時，會選擇大小最合適的內存塊進行存儲。

jemalloc 劃分的內存單元以下圖所示：

 

例如，若是須要存儲大小爲 130 字節的對象，jemalloc 會將其放入 160 字節的內存單元中。

RedisObject

前面說到，Redis 對象有 5 種類型；不管是哪一種類型，Redis 都不會直接存儲，而是經過 RedisObject 對象進行存儲。

RedisObject 對象很是重要，Redis 對象的類型、內部編碼、內存回收、共享對象等功能，都須要 RedisObject 支持，下面將經過 RedisObject 的結構來講明它是如何起做用的。

RedisObject 的定義以下（不一樣版本的 Redis 可能稍稍有所不一樣）：

RedisObject 的每一個字段的含義和做用以下：

 

type

type 字段表示對象的類型，佔 4 個比特；目前包括 REDIS_STRING(字符串)、REDIS_LIST (列表)、REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。

當咱們執行 type 命令時，即是經過讀取 RedisObject 的 type 字段得到對象的類型；以下圖所示：

encoding

encoding 表示對象的內部編碼，佔 4 個比特。對於 Redis 支持的每種類型，都有至少兩種內部編碼，例如對於字符串，有 int、embstr、raw 三種編碼。

經過 encoding 屬性，Redis 能夠根據不一樣的使用場景來爲對象設置不一樣的編碼，大大提升了 Redis 的靈活性和效率。

以列表對象爲例，有壓縮列表和雙端鏈表兩種編碼方式；若是列表中的元素較少，Redis 傾向於使用壓縮列表進行存儲，由於壓縮列表佔用內存更少，並且比雙端鏈表能夠更快載入。

當列表對象元素較多時，壓縮列表就會轉化爲更適合存儲大量元素的雙端鏈表。

經過 object encoding 命令，能夠查看對象採用的編碼方式，以下圖所示：

5 種對象類型對應的編碼方式以及使用條件，將在後面介紹。

lru

lru 記錄的是對象最後一次被命令程序訪問的時間，佔據的比特數不一樣的版本有所不一樣（如 4.0 版本佔 24 比特，2.6 版本佔 22 比特）。

經過對比 lru 時間與當前時間，能夠計算某個對象的空轉時間；object idletime 命令能夠顯示該空轉時間（單位是秒）。object idletime 命令的一個特殊之處在於它不改變對象的 lru 值。

lru 值除了經過 object idletime 命令打印以外，還與 Redis 的內存回收有關係。

若是 Redis 打開了 maxmemory 選項，且內存回收算法選擇的是 volatile-lru 或 allkeys—lru，那麼當 Redis 內存佔用超過 maxmemory 指定的值時，Redis 會優先選擇空轉時間最長的對象進行釋放。

refcount

refcount 與共享對象：refcount 記錄的是該對象被引用的次數，類型爲整型。refcount 的做用，主要在於對象的引用計數和內存回收。

當建立新對象時，refcount 初始化爲 1；當有新程序使用該對象時，refcount 加 1；當對象再也不被一個新程序使用時，refcount 減 1；當 refcount 變爲 0 時，對象佔用的內存會被釋放。

Redis 中被屢次使用的對象(refcount>1)，稱爲共享對象。Redis 爲了節省內存，當有一些對象重複出現時，新的程序不會建立新的對象，而是仍然使用原來的對象。

這個被重複使用的對象，就是共享對象。目前共享對象僅支持整數值的字符串對象。

共享對象的具體實現：Redis 的共享對象目前只支持整數值的字符串對象。之因此如此，其實是對內存和 CPU（時間）的平衡：共享對象雖然會下降內存消耗，可是判斷兩個對象是否相等卻須要消耗額外的時間。

對於整數值，判斷操做複雜度爲 O(1)；對於普通字符串，判斷複雜度爲 O(n)；而對於哈希、列表、集合和有序集合，判斷的複雜度爲 O(n^2)。

雖然共享對象只能是整數值的字符串對象，可是5種類型均可能使用共享對象（如哈希、列表等的元素可使用）。

就目前的實現來講，Redis 服務器在初始化時，會建立 10000 個字符串對象，值分別是 0~9999 的整數值；當 Redis 須要使用值爲 0~9999 的字符串對象時，能夠直接使用這些共享對象。

10000 這個數字能夠經過調整參數 REDIS_SHARED_INTEGERS（4.0 中是 OBJ_SHARED_INTEGERS）的值進行改變。

共享對象的引用次數能夠經過 object refcount 命令查看，以下圖所示。命令執行的結果頁佐證了只有 0~9999 之間的整數會做爲共享對象。

ptr

ptr 指針指向具體的數據，如前面的例子中，set hello world，ptr 指向包含字符串 world 的 SDS。

綜上所述，RedisObject 的結構與對象類型、編碼、內存回收、共享對象都有關係。

一個 RedisObject 對象的大小爲 16 字節：4bit+4bit+24bit+4Byte+8Byte=16Byte。

 

SDS

Redis 沒有直接使用 C 字符串(即以空字符’\0’結尾的字符數組)做爲默認的字符串表示，而是使用了 SDS。SDS 是簡單動態字符串(Simple Dynamic String)的縮寫。

SDS 結構

SDS 的結構以下：

其中，buf 表示字節數組，用來存儲字符串；len 表示 buf 已使用的長度；free 表示 buf 未使用的長度。

下面是兩個例子：

經過 SDS 的結構能夠看出，buf 數組的長度=free+len+1（其中 1 表示字符串結尾的空字符）。

因此，一個 SDS 結構佔據的空間爲：free 所佔長度+len 所佔長度+ buf 數組的長度=4+4+free+len+1=free+len+9。

 

SDS 與 C 字符串的比較

SDS 在 C 字符串的基礎上加入了 free 和 len 字段，帶來了不少好處：

獲取字符串長度：SDS 是 O(1)，C 字符串是 O(n)。

緩衝區溢出：使用 C 字符串的 API 時，若是字符串長度增長（如 strcat 操做）而忘記從新分配內存，很容易形成緩衝區的溢出。

而 SDS 因爲記錄了長度，相應的 API 在可能形成緩衝區溢出時會自動從新分配內存，杜絕了緩衝區溢出。

修改字符串時內存的重分配：對於 C 字符串，若是要修改字符串，必需要從新分配內存（先釋放再申請），由於若是沒有從新分配，字符串長度增大時會形成內存緩衝區溢出，字符串長度減少時會形成內存泄露。

而對於 SDS，因爲能夠記錄 len 和 free，所以解除了字符串長度和空間數組長度之間的關聯，能夠在此基礎上進行優化。

空間預分配策略（即分配內存時比實際須要的多）使得字符串長度增大時從新分配內存的機率大大減少；惰性空間釋放策略使得字符串長度減少時從新分配內存的機率大大減少。

存取二進制數據：SDS 能夠，C 字符串不能夠。由於 C 字符串以空字符做爲字符串結束的標識，而對於一些二進制文件（如圖片等）。

內容可能包括空字符串，所以 C 字符串沒法正確存取；而 SDS 以字符串長度 len 來做爲字符串結束標識，所以沒有這個問題。

此外，因爲 SDS 中的 buf 仍然使用了 C 字符串（即以’\0’結尾），所以 SDS 可使用 C 字符串庫中的部分函數。

可是須要注意的是，只有當 SDS 用來存儲文本數據時才能夠這樣使用，在存儲二進制數據時則不行（’\0’不必定是結尾）。

 

SDS 與 C 字符串的應用

Redis 在存儲對象時，一概使用 SDS 代替 C 字符串。例如 set hello world 命令，hello 和 world 都是以 SDS 的形式存儲的。

而 sadd myset member1 member2 member3 命令，不管是鍵（「myset」），仍是集合中的元素（「member1」、 「member2」和「member3」），都是以 SDS 的形式存儲。

除了存儲對象，SDS 還用於存儲各類緩衝區。只有在字符串不會改變的狀況下，如打印日誌時，纔會使用 C 字符串

Redis 的對象類型與內部編碼

前面已經說過，Redis 支持 5 種對象類型，而每種結構都有至少兩種編碼。

這樣作的好處在於：一方面接口與實現分離，當須要增長或改變內部編碼時，用戶使用不受影響，另外一方面能夠根據不一樣的應用場景切換內部編碼，提升效率。

Redis 各類對象類型支持的內部編碼以下圖所示(圖中版本是 Redis3.0，Redis 後面版本中又增長了內部編碼，略過不提；本章所介紹的內部編碼都是基於 3.0 的)：

關於 Redis 內部編碼的轉換，都符合如下規律：編碼轉換在 Redis 寫入數據時完成，且轉換過程不可逆，只能從小內存編碼向大內存編碼轉換。

字符串

字符串是最基礎的類型，由於全部的鍵都是字符串類型，且字符串以外的其餘幾種複雜類型的元素也是字符串，字符串長度不能超過 512MB。

內部編碼

字符串類型的內部編碼有 3 種，它們的應用場景以下：

int：8 個字節的長整型。字符串值是整型時，這個值使用 long 整型表示。

embstr：<=39 字節的字符串。embstr 與 raw 都使用 RedisObject 和 sds 保存數據。

區別在於：embstr 的使用只分配一次內存空間（所以 RedisObject 和 sds 是連續的），而 raw 須要分配兩次內存空間（分別爲 RedisObject 和 sds 分配空間）。

所以與 raw 相比，embstr 的好處在於建立時少分配一次空間，刪除時少釋放一次空間，以及對象的全部數據連在一塊兒，尋找方便。

而 embstr 的壞處也很明顯，若是字符串的長度增長鬚要從新分配內存時，整個 RedisObject 和 sds 都須要從新分配空間，所以 Redis 中的 embstr 實現爲只讀。

raw：大於 39 個字節的字符串。

示例以下圖所示：

embstr 和 raw 進行區分的長度，是 39；是由於 RedisObject 的長度是 16 字節，sds 的長度是 9+ 字符串長度。

所以當字符串長度是 39 時，embstr 的長度正好是 16+9+39=64，jemalloc 正好能夠分配 64 字節的內存單元。

編碼轉換

當 int 數據再也不是整數，或大小超過了 long 的範圍時，自動轉化爲 raw。

而對於 embstr，因爲其實現是隻讀的，所以在對 embstr 對象進行修改時，都會先轉化爲 raw 再進行修改。

所以，只要是修改 embstr 對象，修改後的對象必定是 raw 的，不管是否達到了 39 個字節。

示例以下圖所示：

列表

列表（list）用來存儲多個有序的字符串，每一個字符串稱爲元素；一個列表能夠存儲 2^32-1 個元素。

Redis 中的列表支持兩端插入和彈出，並能夠得到指定位置（或範圍）的元素，能夠充當數組、隊列、棧等。

內部編碼

列表的內部編碼能夠是壓縮列表（ziplist）或雙端鏈表（linkedlist）。

雙端鏈表：由一個 list 結構和多個 listNode 結構組成；典型結構以下圖所示：

經過圖中能夠看出，雙端鏈表同時保存了表頭指針和表尾指針，而且每一個節點都有指向前和指向後的指針。

鏈表中保存了列表的長度；dup、free 和 match 爲節點值設置類型特定函數。

因此鏈表能夠用於保存各類不一樣類型的值，而鏈表中每一個節點指向的是type爲字符串的 RedisObject。

壓縮列表：壓縮列表是 Redis 爲了節約內存而開發的，是由一系列特殊編碼的連續內存塊(而不是像雙端鏈表同樣每一個節點是指針)組成的順序型數據結構，具體結構相對比較複雜。

與雙端鏈表相比，壓縮列表能夠節省內存空間，可是進行修改或增刪操做時，複雜度較高。

所以當節點數量較少時，可使用壓縮列表；可是節點數量多時，仍是使用雙端鏈表划算。

壓縮列表不只用於實現列表，也用於實現哈希、有序列表；使用很是普遍。

編碼轉換

只有同時知足下面兩個條件時，纔會使用壓縮列表：列表中元素數量小於 512 個；列表中全部字符串對象都不足 64 字節。

若是有一個條件不知足，則使用雙端列表；且編碼只可能由壓縮列表轉化爲雙端鏈表，反方向則不可能。

下圖展現了列表編碼轉換的特色：

其中，單個字符串不能超過 64 字節，是爲了便於統一分配每一個節點的長度。

這裏的 64 字節是指字符串的長度，不包括 SDS 結構，由於壓縮列表使用連續、定長內存塊存儲字符串，不須要 SDS 結構指明長度。

後面提到壓縮列表，也會強調長度不超過 64 字節，原理與這裏相似。

哈希

哈希（做爲一種數據結構），不只是 Redis 對外提供的 5 種對象類型的一種（與字符串、列表、集合、有序結合並列），也是 Redis 做爲 Key-Value 數據庫所使用的數據結構。

爲了說明的方便，在本文後面當使用「內層的哈希」時，表明的是 Redis 對外提供的 5 種對象類型的一種；使用「外層的哈希」代指 Redis 做爲 Key-Value 數據庫所使用的數據結構。

內部編碼

內層的哈希使用的內部編碼能夠是壓縮列表（ziplist）和哈希表（hashtable）2 種；Redis 的外層的哈希則只使用了 hashtable。

壓縮列表前面已介紹，與哈希表相比，壓縮列表用於元素個數少、元素長度小的場景；其優點在於集中存儲，節省空間。

同時，雖然對於元素的操做複雜度也由 O(n)變爲了 O(1)，但因爲哈希中元素數量較少，所以操做的時間並無明顯劣勢。

hashtable：一個 hashtable 由 1 個 dict 結構、2 個 dictht 結構、1 個 dictEntry 指針數組（稱爲 bucket）和多個 dictEntry 結構組成。

正常狀況下（即 hashtable 沒有進行 rehash 時），各部分關係以下圖所示：

下面從底層向上依次介紹各個部分：

dictEntry：dictEntry 結構用於保存鍵值對，結構定義以下。

其中，各個屬性的功能以下：

• key：鍵值對中的鍵。

• val：鍵值對中的值，使用 union(即共用體)實現，存儲的內容既多是一個指向值的指針，也多是 64 位整型，或無符號 64 位整型。

• next：指向下一個 dictEntry，用於解決哈希衝突問題。

在 64 位系統中，一個 dictEntry 對象佔 24 字節（key/val/next 各佔 8 字節）。

bucket：bucket 是一個數組，數組的每一個元素都是指向 dictEntry 結構的指針。

Redis 中 bucket 數組的大小計算規則以下：大於 dictEntry 的、最小的 2^n。

例如，若是有 1000 個 dictEntry，那麼 bucket 大小爲 1024；若是有 1500 個 dictEntry，則 bucket 大小爲 2048。

dictht：dictht 結構以下。

其中，各個屬性的功能說明以下：

• table 屬性是一個指針，指向 bucket。

• size 屬性記錄了哈希表的大小，即 bucket 的大小。

• used 記錄了已使用的 dictEntry 的數量。

• sizemask 屬性的值老是爲 size-1，這個屬性和哈希值一塊兒決定一個鍵在 table 中存儲的位置。

dict：通常來講，經過使用 dictht 和 dictEntry 結構，即可以實現普通哈希表的功能。

可是 Redis 的實現中，在 dictht 結構的上層，還有一個 dict 結構。下面說明 dict 結構的定義及做用。

dict 結構以下：

其中，type 屬性和 privdata 屬性是爲了適應不一樣類型的鍵值對，用於建立多態字典。

ht 屬性和 trehashidx 屬性則用於 rehash，即當哈希表須要擴展或收縮時使用。

ht 是一個包含兩個項的數組，每項都指向一個 dictht 結構，這也是 Redis 的哈希會有 1 個 dict、2 個 dictht 結構的緣由。

一般狀況下，全部的數據都是存在放 dict 的 ht[0] 中，ht[1] 只在 rehash 的時候使用。

dict 進行 rehash 操做的時候，將 ht[0] 中的全部數據 rehash 到 ht[1] 中。而後將 ht[1] 賦值給 ht[0]，並清空 ht[1]。

所以，Redis 中的哈希之因此在 dictht 和 dictEntry 結構以外還有一個 dict 結構，一方面是爲了適應不一樣類型的鍵值對，另外一方面是爲了 rehash。

編碼轉換

如前所述，Redis 中內層的哈希既可能使用哈希表，也可能使用壓縮列表。

只有同時知足下面兩個條件時，纔會使用壓縮列表：哈希中元素數量小於 512 個；哈希中全部鍵值對的鍵和值字符串長度都小於 64 字節。

若是有一個條件不知足，則使用哈希表；且編碼只可能由壓縮列表轉化爲哈希表，反方向則不可能。

下圖展現了 Redis 內層的哈希編碼轉換的特色：

集合

集合（set）與列表相似，都是用來保存多個字符串，但集合與列表有兩點不一樣：集合中的元素是無序的，所以不能經過索引來操做元素；集合中的元素不能有重複。

一個集合中最多能夠存儲 2^32-1 個元素；除了支持常規的增刪改查，Redis 還支持多個集合取交集、並集、差集。

內部編碼

集合的內部編碼能夠是整數集合（intset）或哈希表（hashtable）。

哈希表前面已經講過，這裏略過不提；須要注意的是，集合在使用哈希表時，值所有被置爲 null。

整數集合的結構定義以下：

其中，encoding 表明 contents 中存儲內容的類型，雖然 contents（存儲集合中的元素）是 int8_t 類型。

但實際上其存儲的值是 int16_t、int32_t 或 int64_t，具體的類型即是由 encoding 決定的，length 表示元素個數。

整數集合適用於集合全部元素都是整數且集合元素數量較小的時候，與哈希表相比，整數集合的優點在於集中存儲，節省空間。

同時，雖然對於元素的操做複雜度也由 O(n) 變爲了 O(1)，但因爲集合數量較少，所以操做的時間並無明顯劣勢。

編碼轉換

只有同時知足下面兩個條件時，集合纔會使用整數集合：集合中元素數量小於 512 個，集合中全部元素都是整數值。

若是有一個條件不知足，則使用哈希表；且編碼只可能由整數集合轉化爲哈希表，反方向則不可能。

下圖展現了集合編碼轉換的特色：

有序集合

有序集合與集合同樣，元素都不能重複；但與集合不一樣的是，有序集合中的元素是有順序的。

與列表使用索引下標做爲排序依據不一樣，有序集合爲每一個元素設置一個分數（score）做爲排序依據。

內部編碼

有序集合的內部編碼能夠是壓縮列表（ziplist）或跳躍表（skiplist）。ziplist 在列表和哈希中都有使用，前面已經講過，這裏略過不提。

跳躍表是一種有序數據結構，經過在每一個節點中維持多個指向其餘節點的指針，從而達到快速訪問節點的目的。

除了跳躍表，實現有序數據結構的另外一種典型實現是平衡樹；大多數狀況下，跳躍表的效率能夠和平衡樹媲美，且跳躍表實現比平衡樹簡單不少，所以 Redis 中選用跳躍表代替平衡樹。

跳躍表支持平均 O(logN)、最壞 O(N) 的複雜點進行節點查找，並支持順序操做。

Redis 的跳躍表實現由 zskiplist 和 zskiplistNode 兩個結構組成：前者用於保存跳躍表信息（如頭結點、尾節點、長度等），後者用於表示跳躍表節點，具體結構相對比較複雜。

編碼轉換

只有同時知足下面兩個條件時，纔會使用壓縮列表：有序集合中元素數量小於 128 個；有序集合中全部成員長度都不足 64 字節。

若是有一個條件不知足，則使用跳躍表；且編碼只可能由壓縮列表轉化爲跳躍表，反方向則不可能。

下圖展現了有序集合編碼轉換的特色：

應用舉例

瞭解 Redis 的內存模型以後，下面經過幾個例子說明它的應用。

估算 Redis 內存使用量

要估算 Redis 中的數據佔據的內存大小，須要對 Redis 的內存模型有比較全面的瞭解，包括前面介紹的 hashtable、sds、redisobject、各類對象類型的編碼方式等。

下面以最簡單的字符串類型來進行說明。

假設有 90000 個鍵值對，每一個 key 的長度是 7 個字節，每一個 value 的長度也是 7 個字節（且 key 和 value 都不是整數），下面來估算這 90000 個鍵值對所佔用的空間。

在估算佔據空間以前，首先能夠斷定字符串類型使用的編碼方式：embstr。

90000 個鍵值對佔據的內存空間主要能夠分爲兩部分：

• 90000 個 dictEntry 佔據的空間。

• 鍵值對所須要的 bucket 空間。

每一個 dictEntry 佔據的空間包括：

• 一個 dictEntry，24 字節，jemalloc 會分配 32 字節的內存塊。

• 一個 key，7 字節，因此 SDS(key)須要 7+9=16 個字節，jemalloc 會分配 16 字節的內存塊。

• 一個 RedisObject，16 字節，jemalloc 會分配 16 字節的內存塊。

• 一個 value，7 字節，因此 SDS(value)須要 7+9=16 個字節，jemalloc 會分配 16 字節的內存塊。

• 綜上，一個 dictEntry 須要 32+16+16+16=80 個字節。

bucket 空間：bucket 數組的大小爲大於 90000 的最小的 2^n，是 131072；每一個 bucket 元素爲 8 字節（由於 64 位系統中指針大小爲 8 字節）。

所以，能夠估算出這 90000 個鍵值對佔據的內存大小爲：90000*80 + 131072*8 = 8248576。

下面寫個程序在 Redis 中驗證一下：

運行結果：8247552

理論值與結果值偏差在萬分之 1.2，對於計算須要多少內存來講，這個精度已經足夠了。

之因此會存在偏差，是由於在咱們插入 90000 條數據以前 Redis 已分配了必定的 bucket 空間，而這些 bucket 空間還沒有使用。

做爲對比將 key 和 value 的長度由 7 字節增長到 8 字節，則對應的 SDS 變爲 17 個字節，jemalloc 會分配 32 個字節，所以每一個 dictEntry 佔用的字節數也由 80 字節變爲 112 字節。

此時估算這 90000 個鍵值對佔據內存大小爲：90000*112 + 131072*8 = 11128576。

在Redis 中驗證代碼以下（只修改插入數據的代碼）：

運行結果：11128576，估算準確。

對於字符串類型以外的其餘類型，對內存佔用的估算方法是相似的，須要結合具體類型的編碼方式來肯定。

優化內存佔用

瞭解 Redis 的內存模型，對優化 Redis 內存佔用有很大幫助。下面介紹幾種優化場景。

利用 jemalloc 特性進行優化

上一小節所講述的 90000 個鍵值即是一個例子。因爲 jemalloc 分配內存時數值是不連續的，所以 key/value 字符串變化一個字節，可能會引發佔用內存很大的變更，在設計時能夠利用這一點。

例如，若是 key 的長度是 8 個字節，則 SDS 爲 17 字節，jemalloc 分配 32 字節。

此時將 key 長度縮減爲 7 個字節，則 SDS 爲 16 字節，jemalloc 分配 16 字節；則每一個 key 所佔用的空間均可以縮小一半。

使用整型/長整型

若是是整型/長整型，Redis 會使用 int 類型（8 字節）存儲來代替字符串，能夠節省更多空間。

所以在可使用長整型/整型代替字符串的場景下，儘可能使用長整型/整型。

共享對象

利用共享對象，能夠減小對象的建立（同時減小了 RedisObject 的建立），節省內存空間。

目前 Redis 中的共享對象只包括 10000 個整數（0-9999）；能夠經過調整 REDIS_SHARED_INTEGERS 參數提升共享對象的個數。

例如將 REDIS_SHARED_INTEGERS 調整到 20000，則 0-19999 之間的對象均可以共享。

考慮這樣一種場景：論壇網站在 Redis 中存儲了每一個帖子的瀏覽數，而這些瀏覽數絕大多數分佈在 0-20000 之間。

這時候經過適當增大 REDIS_SHARED_INTEGERS 參數，即可以利用共享對象節省內存空間。

避免過分設計

然而須要注意的是，不管是哪一種優化場景，都要考慮內存空間與設計複雜度的權衡；而設計複雜度會影響到代碼的複雜度、可維護性。

若是數據量較小，那麼爲了節省內存而使得代碼的開發、維護變得更加困難並不划算；仍是之前面講到的 90000 個鍵值對爲例，實際上節省的內存空間只有幾 MB。

可是若是數據量有幾千萬甚至上億，考慮內存的優化就比較必要了。

關注內存碎片率

內存碎片率是一個重要的參數，對 Redis 內存的優化有重要意義。

若是內存碎片率太高（jemalloc 在 1.03 左右比較正常），說明內存碎片多，內存浪費嚴重。

這時即可以考慮重啓 Redis 服務，在內存中對數據進行重排，減小內存碎片。

若是內存碎片率小於 1，說明 Redis 內存不足，部分數據使用了虛擬內存（即 swap）。

因爲虛擬內存的存取速度比物理內存差不少（2-3 個數量級），此時 Redis 的訪問速度可能會變得很慢。

所以必須設法增大物理內存（能夠增長服務器節點數量，或提升單機內存），或減小 Redis 中的數據。

要減小 Redis 中的數據，除了選用合適的數據類型、利用共享對象等，還有一點是要設置合理的數據回收策略（maxmemory-policy），當內存達到必定量後，根據不一樣的優先級對內存進行回收。

End