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），當內存達到一定量后，根據不同的優先級對內存進行回收。