我們使用 Redis 時，會接觸 Redis 的 5 種對象類型（字符串、哈希、列表、集合、有序集合），豐富的類型是 Redis 相對於 Memcached 等的一大優勢。
在瞭解 Redis 的 5 種對象類型的用法和特點的基礎上，進一步瞭解 Redis 的內存模型，對 Redis 的使用有很大幫助。
001 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 使用了虛擬內存，由於虛擬內存的媒介是磁盤，比內存速度要慢很多。
002 Redis內存劃分
Redis 作爲內存數據庫，在內存中存儲的內容主要是數據（鍵值對）；也有其他部分會佔用內存。
Redis 的內存佔用主要可以劃分爲以下幾個部分：
數據
作爲數據庫，數據是最主要的部分；這部分佔用的內存會統計在 used_memory 中。
Redis 使用鍵值對存儲數據，其中的值（對象）包括 5 種類型，即字符串、哈希、列表、集合、有序集合。
進程本身運行需要的內存
Redis 主進程本身運行肯定需要佔用內存，如代碼、常量池等等；這部分內存大約幾兆，在大多數生產環境中與 Redis 數據佔用的內存相比可以忽略。
緩衝內存
緩衝內存包括客戶端緩衝區、複製積壓緩衝區、AOF 緩衝區等；其中，客戶端緩衝區存儲客戶端連接的輸入輸出緩衝；複製積壓緩衝區用於部分複製功能；AOF 緩衝區用於在進行 AOF 重寫時，保存最近的寫入命令。
內存碎片
內存碎片是 Redis 在分配、回收物理內存過程中產生的。例如，如果對數據的更改頻繁，而且數據之間的大小相差很大，可能導致 Redis 釋放的空間在物理內存中並沒有釋放。
但 Redis 又無法有效利用，這就形成了內存碎片，內存碎片不會統計在 used_memory 中。
003 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 字符串(即以空字符’\0’結尾的字符數組)作爲默認的字符串表示，而是使用了 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 的項目均具有龐大的數據量和訪問量，這就要求我們不僅需要有良好的代碼意識，還需要在未來大數據時代中對項目有更好的擴展能力。