創(chuàng)新互聯(lián)自2013年創(chuàng)立以來，先為普陀等服務(wù)建站，普陀等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為普陀企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
我們使用 redis 時，會接觸 Redis 的 5 種對象類型（字符串、哈希、列表、集合、有序集合），豐富的類型是 Redis 相對于 Memcached 等的一大優(yōu)勢。
在了解 Redis 的 5 種對象類型的用法和特點的基礎(chǔ)上，進一步了解 Redis 的內(nèi)存模型，對 Redis 的使用有很大幫助。
在客戶端通過 redis-cli 連接服務(wù)器后（后面如無特殊說明，客戶端一律使用redis-cli），通過 info 命令可以查看內(nèi)存使用情況：info memory。
其中，info 命令可以顯示 Redis 服務(wù)器的許多信息，包括服務(wù)器基本信息、CPU、內(nèi)存、持久化、客戶端連接信息等等；Memory 是參數(shù)，表示只顯示內(nèi)存相關(guān)的信息。
返回結(jié)果中比較重要的幾個說明如下：
used_memory
Redis 分配器分配的內(nèi)存總量（單位是字節(jié)），包括使用的虛擬內(nèi)存（即 swap）；Redis 分配器后面會介紹。used_memory_human 只是顯示更友好。
used_memory_rss
Redis 進程占據(jù)操作系統(tǒng)的內(nèi)存（單位是字節(jié)），與 top 及 ps 命令看到的值是一致的。
除了分配器分配的內(nèi)存之外，used_memory_rss 還包括進程運行本身需要的內(nèi)存、內(nèi)存碎片等，但是不包括虛擬內(nèi)存。
mem_fragmentation_ratio
內(nèi)存碎片比率，該值是 used_memory_rss / used_memory 的比值。
mem_fragmentation_ratio 一般大于 1，且該值越大，內(nèi)存碎片比例越大；mem_fragmentation_ratio<1，說明 Redis 使用了虛擬內(nèi)存，由于虛擬內(nèi)存的媒介是磁盤，比內(nèi)存速度要慢很多。
Redis 作為內(nèi)存數(shù)據(jù)庫，在內(nèi)存中存儲的內(nèi)容主要是數(shù)據(jù)（鍵值對）；也有其他部分會占用內(nèi)存。
Redis 的內(nèi)存占用主要可以劃分為以下幾個部分：
數(shù)據(jù)
作為數(shù)據(jù)庫，數(shù)據(jù)是最主要的部分；這部分占用的內(nèi)存會統(tǒng)計在 used_memory 中。
Redis 使用鍵值對存儲數(shù)據(jù)，其中的值（對象）包括 5 種類型，即字符串、哈希、列表、集合、有序集合。
進程本身運行需要的內(nèi)存
Redis 主進程本身運行肯定需要占用內(nèi)存，如代碼、常量池等等；這部分內(nèi)存大約幾兆，在大多數(shù)生產(chǎn)環(huán)境中與 Redis 數(shù)據(jù)占用的內(nèi)存相比可以忽略。
緩沖內(nèi)存
緩沖內(nèi)存包括客戶端緩沖區(qū)、復(fù)制積壓緩沖區(qū)、AOF 緩沖區(qū)等；其中，客戶端緩沖區(qū)存儲客戶端連接的輸入輸出緩沖；復(fù)制積壓緩沖區(qū)用于部分復(fù)制功能；AOF 緩沖區(qū)用于在進行 AOF 重寫時，保存最近的寫入命令。
內(nèi)存碎片
內(nèi)存碎片是 Redis 在分配、回收物理內(nèi)存過程中產(chǎn)生的。例如，如果對數(shù)據(jù)的更改頻繁，而且數(shù)據(jù)之間的大小相差很大，可能導(dǎo)致 Redis 釋放的空間在物理內(nèi)存中并沒有釋放。
但 Redis 又無法有效利用，這就形成了內(nèi)存碎片，內(nèi)存碎片不會統(tǒng)計在 used_memory 中。
關(guān)于 Redis 數(shù)據(jù)存儲的細節(jié)，涉及到以下幾個概念。
dictEntry：Redis 是 Key-Value 數(shù)據(jù)庫，因此對每個鍵值對都會有一個 dictEntry，里面存儲了指向 Key 和 Value 的指針；next 指向下一個 dictEntry，與本 Key-Value 無關(guān)。
Key：圖中右上角可見，Key（”hello”）并不是直接以字符串存儲，而是存儲在 SDS 結(jié)構(gòu)中。
下面來分別介紹 jemalloc、RedisObject、SDS、對象類型及內(nèi)部編碼。
jemalloc
jemalloc 在 64 位系統(tǒng)中，將內(nèi)存空間劃分為小、大、巨大三個范圍；當(dāng) Redis 存儲數(shù)據(jù)時，會選擇大小最合適的內(nèi)存塊進行存儲。
jemalloc 劃分的內(nèi)存單元如下圖所示：
例如，如果需要存儲大小為 130 字節(jié)的對象，jemalloc 會將其放入 160 字節(jié)的內(nèi)存單元中。
RedisObject
前面說到，Redis 對象有 5 種類型；無論是哪種類型，Redis 都不會直接存儲，而是通過 RedisObject 對象進行存儲。
SDS
Redis 沒有直接使用 C 字符串(即以空字符’’結(jié)尾的字符數(shù)組)作為默認的字符串表示，而是使用了 SDS。SDS 是簡單動態(tài)字符串(Simple Dynamic String)的縮寫。
SDS 結(jié)構(gòu)
其中，buf 表示字節(jié)數(shù)組，用來存儲字符串；len 表示 buf 已使用的長度；free 表示 buf 未使用的長度。
舉個例子：
通過 SDS 的結(jié)構(gòu)可以看出，buf 數(shù)組的長度=free+len+1（其中 1 表示字符串結(jié)尾的空字符）。
所以，一個 SDS 結(jié)構(gòu)占據(jù)的空間為：free 所占長度+len 所占長度+ buf 數(shù)組的長度=4+4+free+len+1=free+len+9。
004
Redis的對象類型與內(nèi)部編碼
Redis 支持 5 種對象類型，而每種結(jié)構(gòu)都有至少兩種編碼。
這樣做的好處在于：一方面接口與實現(xiàn)分離，當(dāng)需要增加或改變內(nèi)部編碼時，用戶使用不受影響，另一方面可以根據(jù)不同的應(yīng)用場景切換內(nèi)部編碼，提高效率。
Redis 各種對象類型支持的內(nèi)部編碼如下圖所示(圖中版本是 Redis3.0)：
關(guān)于 Redis 內(nèi)部編碼的轉(zhuǎn)換，都符合以下規(guī)律：編碼轉(zhuǎn)換在 Redis 寫入數(shù)據(jù)時完成，且轉(zhuǎn)換過程不可逆，只能從小內(nèi)存編碼向大內(nèi)存編碼轉(zhuǎn)換。
字符串
字符串是最基礎(chǔ)的類型，因為所有的鍵都是字符串類型，且字符串之外的其他幾種復(fù)雜類型的元素也是字符串，字符串長度不能超過 512MB。
內(nèi)部編碼
字符串類型的內(nèi)部編碼有 3 種，它們的應(yīng)用場景如下：
int：8 個字節(jié)的長整型。字符串值是整型時，這個值使用 long 整型表示。
embstr：<=39 字節(jié)的字符串。embstr 與 raw 都使用 RedisObject 和 sds 保存數(shù)據(jù)。
區(qū)別在于：embstr 的使用只分配一次內(nèi)存空間（因此 RedisObject 和 sds 是連續(xù)的），而 raw 需要分配兩次內(nèi)存空間（分別為 RedisObject 和 sds 分配空間）。
raw：大于 39 個字節(jié)的字符串。
示例如下圖所示：
embstr 和 raw 進行區(qū)分的長度，是 39；是因為 RedisObject 的長度是 16 字節(jié)，sds 的長度是 9+ 字符串長度。
因此當(dāng)字符串長度是 39 時，embstr 的長度正好是 16+9+39=64，jemalloc 正好可以分配 64 字節(jié)的內(nèi)存單元。
編碼轉(zhuǎn)換
當(dāng) int 數(shù)據(jù)不再是整數(shù)，或大小超過了 long 的范圍時，自動轉(zhuǎn)化為 raw。而對于 embstr，由于其實現(xiàn)是只讀的，因此在對 embstr 對象進行修改時，都會先轉(zhuǎn)化為 raw 再進行修改。
因此，只要是修改 embstr 對象，修改后的對象一定是 raw 的，無論是否達到了 39 個字節(jié)。
示例如下圖所示：
列表
列表（list）用來存儲多個有序的字符串，每個字符串稱為元素；一個列表可以存儲 2^32-1 個元素。
Redis 中的列表支持兩端插入和彈出，并可以獲得指定位置（或范圍）的元素，可以充當(dāng)數(shù)組、隊列、棧等。
內(nèi)部編碼
列表的內(nèi)部編碼可以是壓縮列表（ziplist）或雙端鏈表（linkedlist）。
雙端鏈表：由一個 list 結(jié)構(gòu)和多個 listNode 結(jié)構(gòu)組成；典型結(jié)構(gòu)如下圖所示：
通過圖中可以看出，雙端鏈表同時保存了表頭指針和表尾指針，并且每個節(jié)點都有指向前和指向后的指針。
壓縮列表：壓縮列表是 Redis 為了節(jié)約內(nèi)存而開發(fā)的，是由一系列特殊編碼的連續(xù)內(nèi)存塊(而不是像雙端鏈表一樣每個節(jié)點是指針)組成的順序型數(shù)據(jù)結(jié)構(gòu)，具體結(jié)構(gòu)相對比較復(fù)雜。
當(dāng)節(jié)點數(shù)量較少時，可以使用壓縮列表；壓縮列表不僅用于實現(xiàn)列表，也用于實現(xiàn)哈希、有序列表；使用非常廣泛。
編碼轉(zhuǎn)換
只有同時滿足下面兩個條件時，才會使用壓縮列表：列表中元素數(shù)量小于 512 個；列表中所有字符串對象都不足 64 字節(jié)。
如果有一個條件不滿足，則使用雙端列表；且編碼只可能由壓縮列表轉(zhuǎn)化為雙端鏈表，反方向則不可能。
下圖展示了列表編碼轉(zhuǎn)換的特點：
其中，單個字符串不能超過 64 字節(jié)，是為了便于統(tǒng)一分配每個節(jié)點的長度。
哈希
哈希（作為一種數(shù)據(jù)結(jié)構(gòu)），不僅是 Redis 對外提供的 5 種對象類型的一種（與字符串、列表、集合、有序結(jié)合并列），也是 Redis 作為 Key-Value 數(shù)據(jù)庫所使用的數(shù)據(jù)結(jié)構(gòu)。
內(nèi)部編碼
內(nèi)層的哈希使用的內(nèi)部編碼可以是壓縮列表（ziplist）和哈希表（hashtable）2 種；Redis 的外層的哈希則只使用了 hashtable。
hashtable：一個 hashtable 由 1 個 dict 結(jié)構(gòu)、2 個 dictht 結(jié)構(gòu)、1 個 dictEntry 指針數(shù)組（稱為 bucket）和多個 dictEntry 結(jié)構(gòu)組成。
正常情況下（即 hashtable 沒有進行 rehash 時），各部分關(guān)系如下圖所示：
下面從底層向上依次介紹各個部分：
dictEntry：dictEntry 結(jié)構(gòu)用于保存鍵值對，結(jié)構(gòu)定義如下。
其中，各個屬性的功能如下：
key：鍵值對中的鍵。
val：鍵值對中的值，使用 union(即共用體)實現(xiàn)，存儲的內(nèi)容既可能是一個指向值的指針，也可能是 64 位整型，或無符號 64 位整型。
next：指向下一個 dictEntry，用于解決哈希沖突問題。
在 64 位系統(tǒng)中，一個 dictEntry 對象占 24 字節(jié)（key/val/next 各占 8 字節(jié)）。
bucket：bucket 是一個數(shù)組，數(shù)組的每個元素都是指向 dictEntry 結(jié)構(gòu)的指針。Redis 中 bucket 數(shù)組的大小計算規(guī)則如下：大于 dictEntry 的、最小的 2^n。
例如，如果有 1000 個 dictEntry，那么 bucket 大小為 1024；如果有 1500 個 dictEntry，則 bucket 大小為 2048。
編碼轉(zhuǎn)換
下圖展示了 Redis 內(nèi)層的哈希編碼轉(zhuǎn)換的特點：
集合
集合中的元素是無序的，因此不能通過索引來操作元素；集合中的元素不能有重復(fù)。一個集合中最多可以存儲 2^32-1 個元素。
內(nèi)部編碼
集合的內(nèi)部編碼可以是整數(shù)集合（intset）或哈希表（hashtable）。
整數(shù)集合的結(jié)構(gòu)定義如下：
其中，encoding 代表 contents 中存儲內(nèi)容的類型，雖然 contents（存儲集合中的元素）是 int8_t 類型。
但實際上其存儲的值是 int16_t、int32_t 或 int64_t，具體的類型便是由 encoding 決定的，length 表示元素個數(shù)。
編碼轉(zhuǎn)換
下圖展示了集合編碼轉(zhuǎn)換的特點：
有序集合
有序集合與集合一樣，元素都不能重復(fù)；但與集合不同的是，有序集合中的元素是有順序的。有序集合為每個元素設(shè)置一個分數(shù)（score）作為排序依據(jù)。
內(nèi)部編碼
跳躍表是一種有序數(shù)據(jù)結(jié)構(gòu)，通過在每個節(jié)點中維持多個指向其他節(jié)點的指針，從而達到快速訪問節(jié)點的目的。
Redis 的跳躍表實現(xiàn)由 zskiplist 和 zskiplistNode 兩個結(jié)構(gòu)組成：前者用于保存跳躍表信息（如頭結(jié)點、尾節(jié)點、長度等），后者用于表示跳躍表節(jié)點，具體結(jié)構(gòu)相對比較復(fù)雜。
編碼轉(zhuǎn)換
只有同時滿足下面兩個條件時，才會使用壓縮列表：有序集合中元素數(shù)量小于 128 個；有序集合中所有成員長度都不足 64 字節(jié)。
如果有一個條件不滿足，則使用跳躍表；且編碼只可能由壓縮列表轉(zhuǎn)化為跳躍表，反方向則不可能。
下圖展示了有序集合編碼轉(zhuǎn)換的特點：
Redis在國內(nèi)外各大公司都能看到其身影，比如我們熟悉的新浪，阿里，騰訊，百度，搜狐，優(yōu)酷，美團，小米等等。
零基礎(chǔ)學(xué)習(xí)Redis，這幾方面尤其重要：Redis 客戶端、Redis 高級功能、Redis 持久化和開發(fā)運維常用問題探討、Redis 復(fù)制的原理和優(yōu)化策略、Redis 分布式解決方案等。
重慶分公司
重慶分公司
