Redis為何這么快？一篇文章帶你深入了解Redis

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

在了解 Redis 的 5 種對象類型的用法和特點的基礎上，進一步了解 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 還包括進程運行本身需要的內存、內存碎片等，但是不包括虛擬內存。

mem_fragmentation_ratio

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

mem_fragmentation_ratio 一般大于 1，且該值越大，內存碎片比例越大；mem_fragmentation_ratio<1，說明 Redis 使用了虛擬內存，由于虛擬內存的媒介是磁盤，比內存速度要慢很多。

Redis內存劃分

Redis 作為內存數據庫，在內存中存儲的內容主要是數據（鍵值對）；也有其他部分會占用內存。

Redis 的內存占用主要可以劃分為以下幾個部分：

數據

作為數據庫，數據是最主要的部分；這部分占用的內存會統計在 used_memory 中。

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

進程本身運行需要的內存

Redis 主進程本身運行肯定需要占用內存，如代碼、常量池等等；這部分內存大約幾兆，在大多數生產環境中與 Redis 數據占用的內存相比可以忽略。

緩沖內存

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

內存碎片

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

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

Redis數據存儲的細節

關于 Redis 數據存儲的細節，涉及到以下幾個概念。

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

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

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

jemalloc

jemalloc 在 64 位系統中，將內存空間劃分為小、大、巨大三個范圍；當 Redis 存儲數據時，會選擇大小最合適的內存塊進行存儲。

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

例如，如果需要存儲大小為 130 字節的對象，jemalloc 會將其放入 160 字節的內存單元中。

RedisObject

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

SDS

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

SDS 結構

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

舉個例子：

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

所以，一個 SDS 結構占據的空間為：free 所占長度+len 所占長度+ buf 數組的長度=4+4+free+len+1=free+len+9。

004

Redis的對象類型與內部編碼

Redis 支持 5 種對象類型，而每種結構都有至少兩種編碼。

這樣做的好處在于：一方面接口與實現分離，當需要增加或改變內部編碼時，用戶使用不受影響，另一方面可以根據不同的應用場景切換內部編碼，提高效率。

Redis 各種對象類型支持的內部編碼如下圖所示(圖中版本是 Redis3.0)：

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

字符串

字符串是最基礎的類型，因為所有的鍵都是字符串類型，且字符串之外的其他幾種復雜類型的元素也是字符串，字符串長度不能超過 512MB。

內部編碼

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

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

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

區別在于：embstr 的使用只分配一次內存空間（因此 RedisObject 和 sds 是連續的），而 raw 需要分配兩次內存空間（分別為 RedisObject 和 sds 分配空間）。

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 結構組成；典型結構如下圖所示：

通過圖中可以看出，雙端鏈表同時保存了表頭指針和表尾指針，并且每個節點都有指向前和指向后的指針。

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

當節點數量較少時，可以使用壓縮列表；壓縮列表不僅用于實現列表，也用于實現哈希、有序列表；使用非常廣泛。

編碼轉換

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

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

下圖展示了列表編碼轉換的特點：

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

哈希

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

內部編碼

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

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。

編碼轉換

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

集合

集合中的元素是無序的，因此不能通過索引來操作元素；集合中的元素不能有重復。一個集合中最多可以存儲 2^32-1 個元素。

內部編碼

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

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

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

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

編碼轉換

下圖展示了集合編碼轉換的特點：

有序集合

有序集合與集合一樣，元素都不能重復；但與集合不同的是，有序集合中的元素是有順序的。有序集合為每個元素設置一個分數（score）作為排序依據。

內部編碼

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

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

編碼轉換

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

如果有一個條件不滿足，則使用跳躍表；且編碼只可能由壓縮列表轉化為跳躍表，反方向則不可能。

下圖展示了有序集合編碼轉換的特點：

Redis在國內外各大公司都能看到其身影，比如我們熟悉的新浪，阿里，騰訊，百度，搜狐，優酷，美團，小米等等。

零基礎學習Redis，這幾方面尤其重要：Redis 客戶端、Redis 高級功能、Redis 持久化和開發運維常用問題探討、Redis 復制的原理和優化策略、Redis 分布式解決方案等。