深刻了解一下Redis的內存模型！

時間 2019-11-22

標籤深刻瞭解一下 redis 內存模型欄目 Redis 简体版

原文原文鏈接

一前言html

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

咱們使用Redis時，會接觸Redis的5種對象類型（字符串、哈希、列表、集合、有序集合），豐富的類型是Redis相對於Memcached等的一大優點。在瞭解Redis的5種對象類型的用法和特色的基礎上，進一步瞭解Redis的內存模型，對Redis的使用有很大幫助，例如：redis

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

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

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

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

在後面的文章中，會陸續介紹關於Redis高可用的內容，包括主從複製、哨兵、集羣等等，歡迎關注。服務器

目錄數據結構

1、Redis內存統計架構

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

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

1info memory

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

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

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

（2）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。

（3）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大得多。

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

2、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從新從備份文件中讀取數據，在內存中進行重排，爲每一個數據從新選擇合適的內存單元，減少內存碎片。

3、Redis數據存儲的細節

一、概述

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

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

圖片來源：https://searchdatabase.techtarget.com.cn/7-20218/

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

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

（3）redisObject：Value(「world」)既不是直接以字符串存儲，也不是像Key同樣直接存儲在SDS中，而是存儲在redisObject中。實際上，不論Value是5種類型的哪種，都是經過redisObject來存儲的；而redisObject中的type字段指明瞭Value對象的類型，ptr字段則指向對象所在的地址。不過能夠看出，字符串對象雖然通過了redisObject的包裝，但仍然須要經過SDS存儲。

實際上，redisObject除了type和ptr字段之外，還有其餘字段圖中沒有給出，如用於指定對象內部編碼的字段；後面會詳細介紹。

（4）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劃分的內存單元以下圖所示：

圖片來源：http://blog.csdn.net/zhengpeitao/article/details/76573053

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

三、redisObject

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

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

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

typedef struct redisObject {

　　unsigned type:4;

　　unsigned encoding:4;

unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */

　　int refcount;

　　void *ptr;

} robj;

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

（1）type

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

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

（2）encoding

encoding表示對象的內部編碼，佔4個比特。

對於Redis支持的每種類型，都有至少兩種內部編碼，例如對於字符串，有int、embstr、raw三種編碼。經過encoding屬性，Redis能夠根據不一樣的使用場景來爲對象設置不一樣的編碼，大大提升了Redis的靈活性和效率。以列表對象爲例，有壓縮列表和雙端鏈表兩種編碼方式；若是列表中的元素較少，Redis傾向於使用壓縮列表進行存儲，由於壓縮列表佔用內存更少，並且比雙端鏈表能夠更快載入；當列表對象元素較多時，壓縮列表就會轉化爲更適合存儲大量元素的雙端鏈表。

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

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

（3）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會優先選擇空轉時間最長的對象進行釋放。

（4）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之間的整數會做爲共享對象。

（5）ptr

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

（6）總結

綜上所述，redisObject的結構與對象類型、編碼、內存回收、共享對象都有關係；一個redisObject對象的大小爲16字節：

4bit+4bit+24bit+4Byte+8Byte=16Byte。

四、SDS

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

（1）SDS結構

sds的結構以下：

struct sdshdr {

int len;

int free;

char buf[];

};

其中，buf表示字節數組，用來存儲字符串；len表示buf已使用的長度，free表示buf未使用的長度。下面是兩個例子。

圖片來源：《Redis設計與實現》

經過SDS的結構能夠看出，buf數組的長度=free+len+1（其中1表示字符串結尾的空字符）；因此，一個SDS結構佔據的空間爲：free所佔長度+len所佔長度+ buf數組的長度=4+4+free+len+1=free+len+9。

（2）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’不必定是結尾）。

（3）SDS與C字符串的應用

Redis在存儲對象時，一概使用SDS代替C字符串。例如set hello world命令，hello和world都是以SDS的形式存儲的。而sadd myset member1 member2 member3命令，不管是鍵（」myset」），仍是集合中的元素（」member1」、」member2」和」member3」），都是以SDS的形式存儲。除了存儲對象，SDS還用於存儲各類緩衝區。

只有在字符串不會改變的狀況下，如打印日誌時，纔會使用C字符串。

4、Redis的對象類型與內部編碼

前面已經說過，Redis支持5種對象類型，而每種結構都有至少兩種編碼；這樣作的好處在於：一方面接口與實現分離，當須要增長或改變內部編碼時，用戶使用不受影響，另外一方面能夠根據不一樣的應用場景切換內部編碼，提升效率。

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

圖片來源：《Redis設計與實現》

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

一、字符串

（1）概況

字符串是最基礎的類型，由於全部的鍵都是字符串類型，且字符串以外的其餘幾種複雜類型的元素也是字符串。

字符串長度不能超過512MB。

（2）內部編碼

字符串類型的內部編碼有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字節的內存單元。

（3）編碼轉換

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

而對於embstr，因爲其實現是隻讀的，所以在對embstr對象進行修改時，都會先轉化爲raw再進行修改，所以，只要是修改embstr對象，修改後的對象必定是raw的，不管是否達到了39個字節。示例以下圖所示：

二、列表

（1）概況

列表（list）用來存儲多個有序的字符串，每一個字符串稱爲元素；一個列表能夠存儲2^32-1個元素。Redis中的列表支持兩端插入和彈出，並能夠得到指定位置（或範圍）的元素，能夠充當數組、隊列、棧等。

（2）內部編碼

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

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

圖片來源：《Redis設計與實現》

經過圖中能夠看出，雙端鏈表同時保存了表頭指針和表尾指針，而且每一個節點都有指向前和指向後的指針；鏈表中保存了列表的長度；dup、free和match爲節點值設置類型特定函數，因此鏈表能夠用於保存各類不一樣類型的值。而鏈表中每一個節點指向的是type爲字符串的redisObject。

壓縮列表：壓縮列表是Redis爲了節約內存而開發的，是由一系列特殊編碼的連續內存塊(而不是像雙端鏈表同樣每一個節點是指針)組成的順序型數據結構；具體結構相對比較複雜，略。與雙端鏈表相比，壓縮列表能夠節省內存空間，可是進行修改或增刪操做時，複雜度較高；所以當節點數量較少時，可使用壓縮列表；可是節點數量多時，仍是使用雙端鏈表划算。

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

（3）編碼轉換

只有同時知足下面兩個條件時，纔會使用壓縮列表：列表中元素數量小於512個；列表中全部字符串對象都不足64字節。若是有一個條件不知足，則使用雙端列表；且編碼只可能由壓縮列表轉化爲雙端鏈表，反方向則不可能。

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

其中，單個字符串不能超過64字節，是爲了便於統一分配每一個節點的長度；這裏的64字節是指字符串的長度，不包括SDS結構，由於壓縮列表使用連續、定長內存塊存儲字符串，不須要SDS結構指明長度。後面提到壓縮列表，也會強調長度不超過64字節，原理與這裏相似。

三、哈希

（1）概況

哈希（做爲一種數據結構），不只是redis對外提供的5種對象類型的一種（與字符串、列表、集合、有序結合並列），也是Redis做爲Key-Value數據庫所使用的數據結構。爲了說明的方便，在本文後面當使用「內層的哈希」時，表明的是redis對外提供的5種對象類型的一種；使用「外層的哈希」代指Redis做爲Key-Value數據庫所使用的數據結構。

（2）內部編碼

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

壓縮列表前面已介紹。與哈希表相比，壓縮列表用於元素個數少、元素長度小的場景；其優點在於集中存儲，節省空間；同時，雖然對於元素的操做複雜度也由O(n)變爲了O(1)，但因爲哈希中元素數量較少，所以操做的時間並無明顯劣勢。

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

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

圖片改編自：《Redis設計與實現》

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

dictEntry

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

typedef struct dictEntry{

void *key;

union{

void *val;

uint64_tu64;

int64_ts64;

}v;

struct dictEntry *next;

}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結構以下：

typedef struct dictht{

dictEntry **table;

unsigned long size;

unsigned long sizemask;

unsigned long used;

}dictht;

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

table屬性是一個指針，指向bucket；

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

used記錄了已使用的dictEntry的數量；

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

dict

通常來講，經過使用dictht和dictEntry結構，即可以實現普通哈希表的功能；可是Redis的實現中，在dictht結構的上層，還有一個dict結構。下面說明dict結構的定義及做用。

dict結構以下：

typedef struct dict{

dictType *type;

void *privdata;

dictht ht[2];

int trehashidx;

} 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。

（3）編碼轉換

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

只有同時知足下面兩個條件時，纔會使用壓縮列表：哈希中元素數量小於512個；哈希中全部鍵值對的鍵和值字符串長度都小於64字節。若是有一個條件不知足，則使用哈希表；且編碼只可能由壓縮列表轉化爲哈希表，反方向則不可能。

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

四、集合

（1）概況

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

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

（2）內部編碼

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

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

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

typedef struct intset{

uint32_t encoding;

uint32_t length;

int8_t contents[];

} intset;

其中，encoding表明contents中存儲內容的類型，雖然contents（存儲集合中的元素）是int8_t類型，但實際上其存儲的值是int16_t、int32_t或int64_t，具體的類型即是由encoding決定的；length表示元素個數。

整數集合適用於集合全部元素都是整數且集合元素數量較小的時候，與哈希表相比，整數集合的優點在於集中存儲，節省空間；同時，雖然對於元素的操做複雜度也由O(n)變爲了O(1)，但因爲集合數量較少，所以操做的時間並無明顯劣勢。

（3）編碼轉換

只有同時知足下面兩個條件時，集合纔會使用整數集合：集合中元素數量小於512個；集合中全部元素都是整數值。若是有一個條件不知足，則使用哈希表；且編碼只可能由整數集合轉化爲哈希表，反方向則不可能。

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

五、有序集合

（1）概況

有序集合與集合同樣，元素都不能重複；但與集合不一樣的是，有序集合中的元素是有順序的。與列表使用索引下標做爲排序依據不一樣，有序集合爲每一個元素設置一個分數（score）做爲排序依據。

（2）內部編碼

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

跳躍表是一種有序數據結構，經過在每一個節點中維持多個指向其餘節點的指針，從而達到快速訪問節點的目的。除了跳躍表，實現有序數據結構的另外一種典型實現是平衡樹；大多數狀況下，跳躍表的效率能夠和平衡樹媲美，且跳躍表實現比平衡樹簡單不少，所以redis中選用跳躍表代替平衡樹。跳躍表支持平均O(logN)、最壞O(N)的複雜點進行節點查找，並支持順序操做。Redis的跳躍表實現由zskiplist和zskiplistNode兩個結構組成：前者用於保存跳躍表信息（如頭結點、尾節點、長度等），後者用於表示跳躍表節點。具體結構相對比較複雜，略。

（3）編碼轉換

只有同時知足下面兩個條件時，纔會使用壓縮列表：有序集合中元素數量小於128個；有序集合中全部成員長度都不足64字節。若是有一個條件不知足，則使用跳躍表；且編碼只可能由壓縮列表轉化爲跳躍表，反方向則不可能。

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

5、應用舉例

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

一、估算Redis內存使用量

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

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

假設有90000個鍵值對，每一個key的長度是7個字節，每一個value的長度也是7個字節（且key和value都不是整數）；下面來估算這90000個鍵值對所佔用的空間。在估算佔據空間以前，首先能夠斷定字符串類型使用的編碼方式：embstr。

90000個鍵值對佔據的內存空間主要能夠分爲兩部分：一部分是90000個dictEntry佔據的空間；一部分是鍵值對所須要的bucket空間。

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

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

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

3) 一個redisObject，16字節，jemalloc會分配16字節的內存塊

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

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

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

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

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

public class RedisTest {

　　public static Jedis jedis = new Jedis("localhost", 6379);

　　public static void main(String[] args) throws Exception{

　　　　Long m1 = Long.valueOf(getMemory());

　　　　insertData();

　　　　Long m2 = Long.valueOf(getMemory());

　　　　System.out.println(m2 - m1);

　　}

　　public static void insertData(){

　　　　for(int i = 10000; i < 100000; i++){

　　　　　　jedis.set("aa" + i, "aa" + i); //key和value長度都是7字節，且不是整數

　　　　}

　　public static String getMemory(){

　　　　String memoryAllLine = jedis.info("memory");

　　　　String usedMemoryLine = memoryAllLine.split("\r\n")[1];

　　　　String memory = usedMemoryLine.substring(usedMemoryLine.indexOf(':') + 1);

　　　　return memory;

　　}

運行結果：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中驗證代碼以下（只修改插入數據的代碼）：

public static void insertData(){

　　for(int i = 10000; i < 100000; i++){

　　　　jedis.set("aaa" + i, "aaa" + i); //key和value長度都是8字節，且不是整數

　　}

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

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

二、優化內存佔用

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

（1）利用jemalloc特性進行優化

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

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

（2）使用整型/長整型

若是是整型/長整型，Redis會使用int類型（8字節）存儲來代替字符串，能夠節省更多空間。所以在可使用長整型/整型代替字符串的場景下，儘可能使用長整型/整型。

（3）共享對象

利用共享對象，能夠減小對象的建立（同時減小了redisObject的建立），節省內存空間。目前redis中的共享對象只包括10000個整數（0-9999）；能夠經過調整REDIS_SHARED_INTEGERS參數提升共享對象的個數；例如將REDIS_SHARED_INTEGERS調整到20000，則0-19999之間的對象均可以共享。

考慮這樣一種場景：論壇網站在redis中存儲了每一個帖子的瀏覽數，而這些瀏覽數絕大多數分佈在0-20000之間，這時候經過適當增大REDIS_SHARED_INTEGERS參數，即可以利用共享對象節省內存空間。

（4）避免過分設計

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

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

三、關注內存碎片率

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

若是內存碎片率太高（jemalloc在1.03左右比較正常），說明內存碎片多，內存浪費嚴重；這時即可以考慮重啓redis服務，在內存中對數據進行重排，減小內存碎片。

若是內存碎片率小於1，說明redis內存不足，部分數據使用了虛擬內存（即swap）；因爲虛擬內存的存取速度比物理內存差不少（2-3個數量級），此時redis的訪問速度可能會變得很慢。所以必須設法增大物理內存（能夠增長服務器節點數量，或提升單機內存），或減小redis中的數據。

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

歡迎你們加入Java架構開發：744677563

本羣提供免費的學習指導架構資料以及免費的解答

不懂得問題均可以在本羣提出來以後還會有職業生涯規劃以及面試指導

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。