這篇文章主要介紹Redis的記憶體模型(以3.0為例),包括Redis占用記憶體的情況及如何查詢、不同的對象類型在記憶體中的編碼方式、記憶體配置設定器(jemalloc)、簡單動态字元串(SDS)、RedisObject等;然後在此基礎上介紹幾個Redis記憶體模型的應用。
一、Redis記憶體統計
二、Redis記憶體劃分
三、Redis資料存儲的細節
四、Redis的對象類型與内部編碼
五、應用舉例
工欲善其事必先利其器,在說明Redis記憶體之前首先說明如何統計Redis使用記憶體的情況。
在用戶端通過redis-cli連接配接伺服器後(後面如無特殊說明,用戶端一律使用redis-cli),通過info指令可以檢視記憶體使用情況:
info 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。
Redis作為記憶體資料庫,在記憶體中存儲的内容主要是資料(鍵值對);通過前面的叙述可以知道,除了資料以外,Redis的其他部分也會占用記憶體。
Redis的記憶體占用主要可以劃分為以下幾個部分:
1、資料
作為資料庫,資料是最主要的部分;這部分占用的記憶體會統計在used_memory中。
Redis使用鍵值對存儲資料,其中的值(對象)包括5種類型,即字元串、哈希、清單、集合、有序集合。這5種類型是Redis對外提供的,實際上,在Redis内部,每種類型可能有2種或更多的内部編碼實作;此外,Redis在存儲對象時,并不是直接将資料扔進記憶體,而是會對對象進行各種包裝:如redisObject、SDS等;這篇文章後面将重點介紹Redis中資料存儲的細節。
2、程序本身運作需要的記憶體
Redis主程序本身運作肯定需要占用記憶體,如代碼、常量池等等;這部分記憶體大約幾兆,在大多數生産環境中與Redis資料占用的記憶體相比可以忽略。這部分記憶體不是由jemalloc配置設定,是以不會統計在used_memory中。
補充說明:除了主程序外,Redis建立的子程序運作也會占用記憶體,如Redis執行AOF、RDB重寫時建立的子程序。當然,這部分記憶體不屬于Redis程序,也不會統計在used_memory和used_memory_rss中。
3、緩沖記憶體
緩沖記憶體包括用戶端緩沖區、複制積壓緩沖區、AOF緩沖區等;其中,用戶端緩沖存儲用戶端連接配接的輸入輸出緩沖;複制積壓緩沖用于部分複制功能;AOF緩沖區用于在進行AOF重寫時,儲存最近的寫入指令。在了解相應功能之前,不需要知道這些緩沖的細節;這部分記憶體由jemalloc配置設定,是以會統計在used_memory中。
4、記憶體碎片
記憶體碎片是Redis在配置設定、回收實體記憶體過程中産生的。例如,如果對資料的更改頻繁,而且資料之間的大小相差很大,可能導緻redis釋放的空間在實體記憶體中并沒有釋放,但redis又無法有效利用,這就形成了記憶體碎片。記憶體碎片不會統計在used_memory中。
記憶體碎片的産生與對資料進行的操作、資料的特點等都有關;此外,與使用的記憶體配置設定器也有關系:如果記憶體配置設定器設計合理,可以盡可能的減少記憶體碎片的産生。後面将要說到的jemalloc便在控制記憶體碎片方面做的很好。
如果Redis伺服器中的記憶體碎片已經很大,可以通過安全重新開機的方式減小記憶體碎片:因為重新開機之後,Redis重新從備份檔案中讀取資料,在記憶體中進行重排,為每個資料重新選擇合适的記憶體單元,減小記憶體碎片。
1、概述
關于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、對象類型及内部編碼。
2、jemalloc
Redis在編譯時便會指定記憶體配置設定器;記憶體配置設定器可以是 libc 、jemalloc或者tcmalloc,預設是jemalloc。
jemalloc作為Redis的預設記憶體配置設定器,在減小記憶體碎片方面做的相對比較好。jemalloc在64位系統中,将記憶體空間劃分為小、大、巨大三個範圍;每個範圍内又劃分了許多小的記憶體塊機關;當Redis存儲資料時,會選擇大小最合适的記憶體塊進行存儲。
jemalloc劃分的記憶體單元如下圖所示:
例如,如果需要存儲大小為130位元組的對象,jemalloc會将其放入160位元組的記憶體單元中。
3、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。
4、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字元串。
前面已經說過,Redis支援5種對象類型,而每種結構都有至少兩種編碼;這樣做的好處在于:一方面接口與實作分離,當需要增加或改變内部編碼時,使用者使用不受影響,另一方面可以根據不同的應用場景切換内部編碼,提高效率。
Redis各種對象類型支援的内部編碼如下圖所示(圖中版本是Redis3.0,Redis後面版本中又增加了内部編碼,略過不提;本章所介紹的内部編碼都是基于3.0的):
關于Redis内部編碼的轉換,都符合以下規律:編碼轉換在Redis寫入資料時完成,且轉換過程不可逆,隻能從小記憶體編碼向大記憶體編碼轉換。
1、字元串
(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個位元組。示例如下圖所示:
2、清單
清單(list)用來存儲多個有序的字元串,每個字元串稱為元素;一個清單可以存儲2^32-1個元素。Redis中的清單支援兩端插入和彈出,并可以獲得指定位置(或範圍)的元素,可以充當數組、隊列、棧等。
清單的内部編碼可以是壓縮清單(ziplist)或雙端連結清單(linkedlist)。
雙端連結清單:由一個list結構和多個listNode結構組成;典型結構如下圖所示:
通過圖中可以看出,雙端連結清單同時儲存了表頭指針和表尾指針,并且每個節點都有指向前和指向後的指針;連結清單中儲存了清單的長度;dup、free和match為節點值設定類型特定函數,是以連結清單可以用于儲存各種不同類型的值。而連結清單中每個節點指向的是type為字元串的redisObject。
壓縮清單:壓縮清單是Redis為了節約記憶體而開發的,是由一系列特殊編碼的連續記憶體塊(而不是像雙端連結清單一樣每個節點是指針)組成的順序型資料結構;具體結構相對比較複雜,略。與雙端連結清單相比,壓縮清單可以節省記憶體空間,但是進行修改或增删操作時,複雜度較高;是以當節點數量較少時,可以使用壓縮清單;但是節點數量多時,還是使用雙端連結清單劃算。
壓縮清單不僅用于實作清單,也用于實作哈希、有序清單;使用非常廣泛。
隻有同時滿足下面兩個條件時,才會使用壓縮清單:清單中元素數量小于512個;清單中所有字元串對象都不足64位元組。如果有一個條件不滿足,則使用雙端清單;且編碼隻可能由壓縮清單轉化為雙端連結清單,反方向則不可能。
下圖展示了清單編碼轉換的特點:
其中,單個字元串不能超過64位元組,是為了便于統一配置設定每個節點的長度;這裡的64位元組是指字元串的長度,不包括SDS結構,因為壓縮清單使用連續、定長記憶體塊存儲字元串,不需要SDS結構指明長度。後面提到壓縮清單,也會強調長度不超過64位元組,原理與這裡類似。
3、哈希
哈希(作為一種資料結構),不僅是redis對外提供的5種對象類型的一種(與字元串、清單、集合、有序結合并列),也是Redis作為Key-Value資料庫所使用的資料結構。為了說明的友善,在本文後面當使用“内層的哈希”時,代表的是redis對外提供的5種對象類型的一種;使用“外層的哈希”代指Redis作為Key-Value資料庫所使用的資料結構。
内層的哈希使用的内部編碼可以是壓縮清單(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。
如前所述,Redis中内層的哈希既可能使用哈希表,也可能使用壓縮清單。
隻有同時滿足下面兩個條件時,才會使用壓縮清單:哈希中元素數量小于512個;哈希中所有鍵值對的鍵和值字元串長度都小于64位元組。如果有一個條件不滿足,則使用哈希表;且編碼隻可能由壓縮清單轉化為哈希表,反方向則不可能。
下圖展示了Redis内層的哈希編碼轉換的特點:
4、集合
集合(set)與清單類似,都是用來儲存多個字元串,但集合與清單有兩點不同:集合中的元素是無序的,是以不能通過索引來操作元素;集合中的元素不能有重複。
一個集合中最多可以存儲2^32-1個元素;除了支援正常的增删改查,Redis還支援多個集合取交集、并集、差集。
集合的内部編碼可以是整數集合(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),但由于集合數量較少,是以操作的時間并沒有明顯劣勢。
隻有同時滿足下面兩個條件時,集合才會使用整數集合:集合中元素數量小于512個;集合中所有元素都是整數值。如果有一個條件不滿足,則使用哈希表;且編碼隻可能由整數集合轉化為哈希表,反方向則不可能。
下圖展示了集合編碼轉換的特點:
5、有序集合
有序集合與集合一樣,元素都不能重複;但與集合不同的是,有序集合中的元素是有順序的。與清單使用索引下标作為排序依據不同,有序集合為每個元素設定一個分數(score)作為排序依據。
有序集合的内部編碼可以是壓縮清單(ziplist)或跳躍表(skiplist)。ziplist在清單和哈希中都有使用,前面已經講過,這裡略過不提。
跳躍表是一種有序資料結構,通過在每個節點中維持多個指向其他節點的指針,進而達到快速通路節點的目的。除了跳躍表,實作有序資料結構的另一種典型實作是平衡樹;大多數情況下,跳躍表的效率可以和平衡樹媲美,且跳躍表實作比平衡樹簡單很多,是以redis中選用跳躍表代替平衡樹。跳躍表支援平均O(logN)、最壞O(N)的複雜點進行節點查找,并支援順序操作。Redis的跳躍表實作由zskiplist和zskiplistNode兩個結構組成:前者用于儲存跳躍表資訊(如頭結點、尾節點、長度等),後者用于表示跳躍表節點。具體結構相對比較複雜,略。
隻有同時滿足下面兩個條件時,才會使用壓縮清單:有序集合中元素數量小于128個;有序集合中所有成員長度都不足64位元組。如果有一個條件不滿足,則使用跳躍表;且編碼隻可能由壓縮清單轉化為跳躍表,反方向則不可能。
下圖展示了有序集合編碼轉換的特點:
了解Redis的記憶體模型之後,下面通過幾個例子說明其應用。
1、估算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;估算準确。
對于字元串類型之外的其他類型,對記憶體占用的估算方法是類似的,需要結合具體類型的編碼方式來确定。
2、優化記憶體占用
了解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。但是如果資料量有幾千萬甚至上億,考慮記憶體的優化就比較必要了。
3、關注記憶體碎片率
記憶體碎片率是一個重要的參數,對redis 記憶體的優化有重要意義。
如果記憶體碎片率過高(jemalloc在1.03左右比較正常),說明記憶體碎片多,記憶體浪費嚴重;這時便可以考慮重新開機redis服務,在記憶體中對資料進行重排,減少記憶體碎片。