溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
本篇內(nèi)容介紹了“Redis內(nèi)存對(duì)像模型分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
Redis內(nèi)存統(tǒng)計(jì)
語(yǔ)句：info memory
輸出說(shuō)明：
used_memory: Total number of bytes allocated by Redis using its allocator
(Redis分配器分配的內(nèi)存總量，單位是字節(jié)，包括使用的虛擬內(nèi)存)
used_memory_human: Human readable representation of previous value
(只是為了友好顯示used_memory，方便閱讀)
used_memory_rss: Number of bytes that Redis allocated as seen by the operating system (a.k.a resident set size). This is the number reported by tools such as top(1) and ps(1)
(Redis進(jìn)程占據(jù)操作系統(tǒng)的內(nèi)存，單位是字節(jié)，與top及ps命令所看到的內(nèi)存是一致的;除了分配
器分配的內(nèi)存外，used_memory_rss還包括進(jìn)程運(yùn)行本身需要的內(nèi)存，內(nèi)存碎片等，但是不包括虛擬內(nèi)存)
因此，used_memory和used_memory_rss，前者是從redis角度看到的量，后都是從操作系統(tǒng)看到的量。二者
之所以不同，一方面是因?yàn)閮?nèi)存碎片和Redis進(jìn)程運(yùn)行需要占用內(nèi)存，使得前者可能比后者小，另一方面虛擬內(nèi)存的存在，使得前者可能比后者大。
由于在實(shí)際應(yīng)用中，Redis的數(shù)據(jù)量會(huì)比較大，此時(shí)進(jìn)程運(yùn)行占用的內(nèi)存與Redis數(shù)據(jù)量和內(nèi)存碎片相比，都會(huì)小得多；因此used_memory_rss和used_memory的比例，便成了衡量Redis內(nèi)存碎片率的參數(shù)；這個(gè)參數(shù)就是mem_fragmentation_ratio。
mem_fragmentation_ratio: Ratio between used_memory_rss and used_memory
(內(nèi)存碎片比率，該值是used_memory_rss 和used_memory的比值)
mem_fragmentation_ratio一般大于1，且該值越大，內(nèi)存碎片比例越大。mem_fragmentation_ratio<1，說(shuō)明Redis使用了虛擬內(nèi)存，由于虛擬內(nèi)存的媒介是磁盤，比內(nèi)存速度要慢很多，當(dāng)這種情況出現(xiàn)時(shí)，應(yīng)該及時(shí)排查，如果內(nèi)存不足應(yīng)該及時(shí)處理，如增加Redis節(jié)點(diǎn)、增加Redis服務(wù)器的內(nèi)存、優(yōu)化應(yīng)用等。
一般來(lái)說(shuō)，mem_fragmentation_ratio在1.03左右是比較健康的狀態(tài)（對(duì)于jemalloc來(lái)說(shuō)）；上面截圖中的mem_fragmentation_ratio值很大，是因?yàn)檫€沒有向Redis中存入數(shù)據(jù)，Redis進(jìn)程本身運(yùn)行的內(nèi)存使得used_memory_rss 比used_memory大得多。
mem_allocator:Memory allocator, chosen at compile time
(內(nèi)存分配器，在編譯時(shí)可以指定)
內(nèi)存的劃分
redis的內(nèi)存占據(jù)主要?jiǎng)澐譃橐韵聨讉€(gè)部分：
1，數(shù)據(jù)
這部分占用的內(nèi)存會(huì)統(tǒng)計(jì)在used_memory中.
2，進(jìn)程本身所需要的內(nèi)存
這部分內(nèi)存不是由jemalloc分配，因此不會(huì)統(tǒng)計(jì)在used_memory中。
補(bǔ)充說(shuō)明：除了主進(jìn)程外，Redis創(chuàng)建的子進(jìn)程運(yùn)行也會(huì)占用內(nèi)存，如Redis執(zhí)行AOF、RDB重寫時(shí)創(chuàng)建的子進(jìn)程。當(dāng)然，這部分內(nèi)存不屬于Redis進(jìn)程，也不會(huì)統(tǒng)計(jì)在used_memory和used_memory_rss中。
3，緩沖內(nèi)存
緩沖內(nèi)存包括客戶端緩沖區(qū)、復(fù)制積壓緩沖區(qū)、AOF緩沖區(qū)等；
客戶端緩沖存儲(chǔ)客戶端連接的輸入輸出緩沖；
復(fù)制積壓緩沖用于部分復(fù)制功能；
AOF緩沖區(qū)用于在進(jìn)行AOF重寫時(shí)，保存最近的寫入命令。
在了解相應(yīng)功能之前，不需要知道這些緩沖的細(xì)節(jié)；這部分內(nèi)存由jemalloc分配，因此會(huì)統(tǒng)計(jì)在used_memory中。
內(nèi)存碎片
內(nèi)存碎片是Redis在分配、回收物理內(nèi)存過程中產(chǎn)生的。內(nèi)存碎片不會(huì)統(tǒng)計(jì)在used_memory中。
如果Redis服務(wù)器中的內(nèi)存碎片已經(jīng)很大，可以通過安全重啟的方式減小內(nèi)存碎片：因?yàn)橹貑⒅?，Redis重新從備份文件中讀取數(shù)據(jù)，在內(nèi)存中進(jìn)行重排，為每個(gè)數(shù)據(jù)重新選擇合適的內(nèi)存單元，減小內(nèi)存碎片。
四，Redis數(shù)據(jù)存儲(chǔ)的細(xì)節(jié)
1，概述
關(guān)于Redis數(shù)據(jù)存儲(chǔ)的細(xì)節(jié)，涉及到內(nèi)存分配器（如jemalloc）、簡(jiǎn)單動(dòng)態(tài)字符串（SDS）、5種對(duì)象類型及內(nèi)部編碼、
redisObject。在講述具體內(nèi)容之前，先說(shuō)明一下這幾個(gè)概念之間的關(guān)系。
下圖是執(zhí)行set hello world時(shí)，所涉及到的數(shù)據(jù)模型。
（1）dictEntry：Redis是Key-Value數(shù)據(jù)庫(kù)，因此對(duì)每個(gè)鍵值對(duì)都會(huì)有一個(gè)dictEntry，里面存儲(chǔ)了指向Key和Value的指針；
next指向下一個(gè)dictEntry，與本Key-Value無(wú)關(guān)。
（2）Key：圖中右上角可見，Key（”hello”）并不是直接以字符串存儲(chǔ)，而是存儲(chǔ)在SDS結(jié)構(gòu)中。
（3）redisObject：Value(“world”)既不是直接以字符串存儲(chǔ)，也不是像Key一樣直接存儲(chǔ)在SDS中，而是存儲(chǔ)在redisObject中。
實(shí)際上，不論Value是5種類型的哪一種，都是通過redisObject來(lái)存儲(chǔ)的；而redisObject中的type字段指明了Value對(duì)象的
類型，ptr字段則指向?qū)ο笏诘牡刂?。不過可以看出，字符串對(duì)象雖然經(jīng)過了redisObject的包裝，但仍然需要通過SDS
存儲(chǔ)。
實(shí)際上，redisObject除了type和ptr字段以外，還有其他字段圖中沒有給出，如用于指定對(duì)象內(nèi)部編碼的字段；后面會(huì)詳細(xì)
介紹。
（4）jemalloc：無(wú)論是DictEntry對(duì)象，還是redisObject、SDS對(duì)象，都需要內(nèi)存分配器（如jemalloc）分配內(nèi)存進(jìn)行存儲(chǔ)。
以DictEntry對(duì)象為例，有3個(gè)指針組成，在64位機(jī)器下占24個(gè)字節(jié)，jemalloc會(huì)為它分配32字節(jié)大小的內(nèi)存單元。
下面來(lái)分別介紹jemalloc、redisObject、SDS、對(duì)象類型及內(nèi)部編碼。
2、jemalloc
Redis在編譯時(shí)便會(huì)指定內(nèi)存分配器；內(nèi)存分配器可以是 libc 、jemalloc或者tcmalloc，默認(rèn)是jemalloc。
jemalloc作為Redis的默認(rèn)內(nèi)存分配器，在減小內(nèi)存碎片方面做的相對(duì)比較好。jemalloc在64位系統(tǒng)中，將內(nèi)存空間劃分為小、
大、巨大三個(gè)范圍；每個(gè)范圍內(nèi)又劃分了許多小的內(nèi)存塊單位；當(dāng)Redis存儲(chǔ)數(shù)據(jù)時(shí)，會(huì)選擇大小最合適的內(nèi)存塊進(jìn)行存儲(chǔ)。
jemalloc劃分的內(nèi)存單元如下圖所示：
例如，如果需要存儲(chǔ)大小為130字節(jié)的對(duì)象，jemalloc會(huì)將其放入160字節(jié)的內(nèi)存單元中。
3、redisObject
前面說(shuō)到，Redis對(duì)象有5種類型；無(wú)論是哪種類型，Redis都不會(huì)直接存儲(chǔ)，而是通過redisObject對(duì)象進(jìn)行存儲(chǔ)。
redisObject對(duì)象非常重要，Redis對(duì)象的類型、內(nèi)部編碼、內(nèi)存回收、共享對(duì)象等功能，都需要redisObject支持，下面將通
過redisObject的結(jié)構(gòu)來(lái)說(shuō)明它是如何起作用的。
redisObject的定義如下（不同版本的Redis可能稍稍有所不同）：
typedef struct redisObject {
unsigned type:4;
unsigned encoding:4;
unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
* LFU data (least significant 8 bits frequency
* and most significant 16 bits access time). */
int refcount;
void *ptr;
} robj;
redisObject每個(gè)字段的含義和作用如下：
（3.1）type
type字段表示對(duì)象的類型，占4個(gè)比特；目前包括REDIS_STRING(字符串)、REDIS_LIST (列表)、
REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。
當(dāng)我們執(zhí)行type命令時(shí)，便是通過讀取RedisObject的type字段獲得對(duì)象的類型；如下圖所示：
（3.2）encoding
encoding表示對(duì)象的內(nèi)部編碼，占4個(gè)比特。
對(duì)于Redis支持的每種類型，都有至少兩種內(nèi)部編碼，例如對(duì)于字符串，有int、embstr、raw三種編碼。
通過encoding屬性，Redis可以根據(jù)不同的使用場(chǎng)景來(lái)為對(duì)象設(shè)置不同的編碼，大大提高了Redis的靈活性和效率。
以列表對(duì)象為例，有壓縮列表和雙端鏈表兩種編碼方式；如果列表中的元素較少，Redis傾向于使用壓縮列表進(jìn)行存儲(chǔ)，
因?yàn)閴嚎s列表占用內(nèi)存更少，而且比雙端鏈表可以更快載入；當(dāng)列表對(duì)象元素較多時(shí)，壓縮列表就會(huì)轉(zhuǎn)化為更適合存儲(chǔ)
大量元素的雙端鏈表。
通過object encoding命令，可以查看對(duì)象采用的編碼方式，如下圖所示：
5種對(duì)象類型對(duì)應(yīng)的編碼方式以及使用條件，將在后面介紹。
（3.3）lru
lru記錄的是對(duì)象最后一次被命令程序訪問的時(shí)間，占據(jù)的比特?cái)?shù)不同的版本有所不同（如4.0版本占24比特，
2.6版本占22比特）。
通過對(duì)比lru時(shí)間與當(dāng)前時(shí)間，可以計(jì)算某個(gè)對(duì)象的空轉(zhuǎn)時(shí)間；object idletime命令可以顯示該空轉(zhuǎn)時(shí)間（單位是秒）。
object idletime命令的一個(gè)特殊之處在于它不改變對(duì)象的lru值。
lru值除了通過object idletime命令打印之外，還與Redis的內(nèi)存回收有關(guān)系：如果Redis打開了maxmemory選項(xiàng)，且內(nèi)存
回收算法選擇的是volatile-lru或allkeys—lru，那么當(dāng)Redis內(nèi)存占用超過maxmemory指定的值時(shí)，Redis會(huì)優(yōu)先選擇空轉(zhuǎn)時(shí)
間最長(zhǎng)的對(duì)象進(jìn)行釋放。
（3.4）refcount
（3.4.1）refcount與共享對(duì)象
refcount記錄的是該對(duì)象被引用的次數(shù)，類型為整型。refcount的作用，主要在于對(duì)象的引用計(jì)數(shù)和內(nèi)存回收。當(dāng)創(chuàng)
建新對(duì)象時(shí)，refcount初始化為1；當(dāng)有新程序使用該對(duì)象時(shí)，refcount加1；當(dāng)對(duì)象不再被一個(gè)新程序使用時(shí)，refcount減
1；當(dāng)refcount變?yōu)?時(shí)，對(duì)象占用的內(nèi)存會(huì)被釋放。
Redis中被多次使用的對(duì)象(refcount>1)，稱為共享對(duì)象。Redis為了節(jié)省內(nèi)存，當(dāng)有一些對(duì)象重復(fù)出現(xiàn)時(shí)，新的程序
不會(huì)創(chuàng)建新的對(duì)象，而是仍然使用原來(lái)的對(duì)象。這個(gè)被重復(fù)使用的對(duì)象，就是共享對(duì)象。目前共享對(duì)象僅支持整數(shù)值的
字符串對(duì)象。
Redis的共享對(duì)象目前只支持整數(shù)值的字符串對(duì)象。之所以如此，實(shí)際上是對(duì)內(nèi)存和CPU（時(shí)間）的平衡：共享對(duì)象
雖然會(huì)降低內(nèi)存消耗，但是判斷兩個(gè)對(duì)象是否相等卻需要消耗額外的時(shí)間。對(duì)于整數(shù)值，判斷操作復(fù)雜度為O(1)；對(duì)于
普通字符串，判斷復(fù)雜度為O(n)；而對(duì)于哈希、列表、集合和有序集合，判斷的復(fù)雜度為O(n^2)。
雖然共享對(duì)象只能是整數(shù)值的字符串對(duì)象，但是5種類型都可能使用共享對(duì)象（如哈希、列表等的元素可以使用）。
就目前的實(shí)現(xiàn)來(lái)說(shuō)，Redis服務(wù)器在初始化時(shí)，會(huì)創(chuàng)建10000個(gè)字符串對(duì)象，值分別是0~9999的整數(shù)值；當(dāng)Redis需
要使用值為0~9999的字符串對(duì)象時(shí)，可以直接使用這些共享對(duì)象。10000這個(gè)數(shù)字可以通過調(diào)整參數(shù)
REDIS_SHARED_INTEGERS（4.0中是OBJ_SHARED_INTEGERS）的值進(jìn)行改變。
共享對(duì)象的引用次數(shù)可以通過object refcount命令查看，如下圖所示。命令執(zhí)行的結(jié)果頁(yè)佐證了只有0~9999之間的
整數(shù)會(huì)作為共享對(duì)象。
（3.5）ptr
ptr指針指向具體的數(shù)據(jù)，如前面的例子中，set hello world，ptr指向包含字符串world的SDS。
（3.6）總結(jié)
綜上所述，redisObject的結(jié)構(gòu)與對(duì)象類型、編碼、內(nèi)存回收、共享對(duì)象都有關(guān)系；一個(gè)redisObject對(duì)象的大小為16
字節(jié)：
4bit+4bit+24bit+4Byte+8Byte=16Byte。
4，SDS
(1)SDS結(jié)構(gòu)
Redis沒有直接使用C字符串(即以空字符’\0’結(jié)尾的字符數(shù)組)作為默認(rèn)的字符串表示，而是使用了SDS。SDS是簡(jiǎn)單動(dòng)態(tài)字符串
(SimpleDynamic String)的縮寫。
通過SDS的結(jié)構(gòu)可以看出，buf數(shù)組的長(zhǎng)度=free+len+1（其中1表示字符串結(jié)尾的空字符）；所以，一個(gè)SDS結(jié)構(gòu)占據(jù)的空間為：
free所占長(zhǎng)度+len所占長(zhǎng)度+ buf數(shù)組的長(zhǎng)度=4+4+free+len+1=free+len+9。
SDS在C字符串的基礎(chǔ)上加入了free和len字段，帶來(lái)了很多好處：
獲取字符串長(zhǎng)度：SDS是O(1)，C字符串是O(n)
緩沖區(qū)溢出：使用C字符串的API時(shí)，如果字符串長(zhǎng)度增加（如strcat操作）而忘記重新分配內(nèi)存，很容易造成緩沖區(qū)的溢出；而SDS由于記錄了長(zhǎng)度，相應(yīng)的API在可能造成緩沖區(qū)溢出時(shí)會(huì)自動(dòng)重新分配內(nèi)存，杜絕了緩沖區(qū)溢出。
修改字符串時(shí)內(nèi)存的重分配：對(duì)于C字符串，如果要修改字符串，必須要重新分配內(nèi)存（先釋放再申請(qǐng)），因?yàn)槿绻麤]有重新分配，字符串長(zhǎng)度增大時(shí)會(huì)造成內(nèi)存緩沖區(qū)溢出，字符串長(zhǎng)度減小時(shí)會(huì)造成內(nèi)存泄露。而對(duì)于SDS，由于可以記錄len和free，因此解除了字符串長(zhǎng)度和空間數(shù)組長(zhǎng)度之間的關(guān)聯(lián)，可以在此基礎(chǔ)上進(jìn)行優(yōu)化：空間預(yù)分配策略（即分配內(nèi)存時(shí)比實(shí)際需要的多）使得字符串長(zhǎng)度增大時(shí)重新分配內(nèi)存的概率大大減??；惰性空間釋放策略使得字符串長(zhǎng)度減小時(shí)重新分配內(nèi)存的概率大大減小。
存取二進(jìn)制數(shù)據(jù)：SDS可以，C字符串不可以。因?yàn)镃字符串以空字符作為字符串結(jié)束的標(biāo)識(shí)，而對(duì)于一些二進(jìn)制文件（如圖片等），內(nèi)容可能包括空字符串，因此C字符串無(wú)法正確存??；而SDS以字符串長(zhǎng)度len來(lái)作為字符串結(jié)束標(biāo)識(shí)，因此沒有這個(gè)問題。
此外，由于SDS中的buf仍然使用了C字符串（即以’\0’結(jié)尾），因此SDS可以使用C字符串庫(kù)中的部分函數(shù)；但是需要注意的
是，只有當(dāng)SDS用來(lái)存儲(chǔ)文本數(shù)據(jù)時(shí)才可以這樣使用，在存儲(chǔ)二進(jìn)制數(shù)據(jù)時(shí)則不行（’\0’不一定是結(jié)尾）。
Redis在存儲(chǔ)對(duì)象時(shí)，一律使用SDS代替C字符串。例如set hello world命令，hello和world都是以SDS的形式存儲(chǔ)的。
而sadd myset member1 member2 member3命令，不論是鍵（”myset”），還是集合中的元素（”member1”、 ”member2”
和”member3”），都是以SDS的形式存儲(chǔ)。除了存儲(chǔ)對(duì)象，SDS還用于存儲(chǔ)各種緩沖區(qū)。
只有在字符串不會(huì)改變的情況下，如打印日志時(shí)，才會(huì)使用C字符串。
前面已經(jīng)說(shuō)過，Redis支持5種對(duì)象類型，而每種結(jié)構(gòu)都有至少兩種編碼；這樣做的好處在于：一方面接口與實(shí)現(xiàn)分離，當(dāng)需要增加或改變內(nèi)部編碼時(shí)，用戶使用不受影響，另一方面可以根據(jù)不同的應(yīng)用場(chǎng)景切換內(nèi)部編碼，提高效率。
Redis各種對(duì)象類型支持的內(nèi)部編碼如下圖所示(圖中版本是Redis3.0，www.baohuayule.cn Redis后面版本中又增加了內(nèi)部編碼，略過不提；本章所介紹的內(nèi)部編碼都是基于3.0的)：
關(guān)于Redis內(nèi)部編碼的轉(zhuǎn)換，都符合以下規(guī)律：編碼轉(zhuǎn)換在Redis寫入數(shù)據(jù)時(shí)完成，且轉(zhuǎn)換過程不可逆，只能從小內(nèi)存編碼向大內(nèi)存編碼轉(zhuǎn)換。
字符串是最基礎(chǔ)的類型，因?yàn)樗械逆I都是字符串類型，且字符串之外的其他幾種復(fù)雜類型的元素也是字符串。
字符串長(zhǎng)度不能超過512MB。
字符串類型的內(nèi)部編碼有3種，它們的應(yīng)用場(chǎng)景如下：
int：8個(gè)字節(jié)的長(zhǎng)整型。字符串值是整型時(shí)，這個(gè)值使用long整型表示。
embstr：www.006665.cn <=39字節(jié)的字符串。embstr與raw都使用www.baohuayule.com redisObject和sds保存數(shù)據(jù)，區(qū)別在于，embstr的使用只分配一次內(nèi)存空間（因此redisObject和sds是連續(xù)的），而raw需要分配兩次內(nèi)存空間（分別為redisObject和sds分配空間）。因此與raw相比，embstr的好處在于創(chuàng)建時(shí)少分配一次空間，刪除時(shí)少釋放一次空間，以及對(duì)象的所有數(shù)據(jù)連在一起，尋找方便。而embstr的壞處也很明顯，如果字符串的長(zhǎng)度增加需要重新分配內(nèi)存時(shí)，整個(gè)redisObject和sds都需要重新分配空間，因此redis中的embstr實(shí)現(xiàn)為只讀。
raw：大于39個(gè)字節(jié)的字符串
示例如下圖所示：
embstr和raw進(jìn)行區(qū)分的長(zhǎng)度，是39；是因?yàn)閞edisObject的長(zhǎng)度是16字節(jié)，sds的長(zhǎng)度是9+字符串長(zhǎng)度；因此當(dāng)字符串長(zhǎng)度是39時(shí)，
embstr的長(zhǎng)度正好是16+9+39=64，jemalloc正好可以分配64字節(jié)的內(nèi)存單元。
當(dāng)int數(shù)據(jù)不再是整數(shù)，或大小超過了long的范圍時(shí)，自動(dòng)轉(zhuǎn)化為raw。
而對(duì)于embstr，由于其實(shí)現(xiàn)是只讀的，www.leyouzaixan.cn 因此在對(duì)embstr對(duì)象進(jìn)行修改時(shí)，都會(huì)先轉(zhuǎn)化為raw再進(jìn)行修改，因此，
只要是修改embstr對(duì)象，修改后的對(duì)象一定是raw的，無(wú)論是否達(dá)到了39個(gè)字節(jié)。示例如下圖所示：
列表（list）用來(lái)存儲(chǔ)多個(gè)有序的字符串，每個(gè)字符串稱為元素；一個(gè)列表可以存儲(chǔ)2^32-1個(gè)元素。Redis中的列表支持兩端插入和彈出，并可以獲得指定位置（或范圍）的元素，可以充當(dāng)數(shù)組、隊(duì)列、棧等。
列表的內(nèi)部編碼可以是壓縮列表（ziplist）或雙端鏈表（linkedlist）。
雙端鏈表：由一個(gè)list結(jié)構(gòu)和多個(gè)listNode結(jié)構(gòu)組成；典型結(jié)構(gòu)如下圖所示：
通過圖中可以看出，雙端鏈表同時(shí)保存了表頭指針和表尾指針，并且每個(gè)節(jié)點(diǎn)都有指向前和指向后的指針；鏈表中保存了列表的
長(zhǎng)度；dup、free和match為節(jié)點(diǎn)值設(shè)置類型特定函數(shù)，所以鏈表可以用于保存各種不同類型的值。而鏈表中每個(gè)節(jié)點(diǎn)指向的是type為
字符串的redisObject。
壓縮列表：壓縮列表是Redis為了節(jié)約內(nèi)存而開發(fā)的，是由一系列特殊編碼的連續(xù)內(nèi)存塊(而不是像雙端鏈表一樣每個(gè)節(jié)點(diǎn)是指針)
組成的順序型數(shù)據(jù)結(jié)構(gòu)；具體結(jié)構(gòu)相對(duì)比較復(fù)雜，略。與雙端鏈表相比，壓縮列表可以節(jié)省內(nèi)存空間，但是進(jìn)行修改或增刪操作時(shí)，復(fù)
雜度較高；因此當(dāng)節(jié)點(diǎn)數(shù)量較少時(shí)，可以使用壓縮列表；但是節(jié)點(diǎn)數(shù)量多時(shí)，還是使用雙端鏈表劃算。
壓縮列表不僅用于實(shí)現(xiàn)列表，也用于實(shí)現(xiàn)哈希、有序列表；使用非常廣泛。
只有同時(shí)滿足下面兩個(gè)條件時(shí)，才會(huì)使用壓縮列表：列表中元素?cái)?shù)量小于512個(gè)；列表中所有字符串對(duì)象都不足64字節(jié)。如果有一
個(gè)條件不滿足，則使用雙端列表；且編碼只可能由壓縮列表轉(zhuǎn)化為雙端鏈表，反方向則不可能。
下圖展示了列表編碼轉(zhuǎn)換的特點(diǎn)：
其中，單個(gè)字符串不能超過64字節(jié)，是為了便于統(tǒng)一分配每個(gè)節(jié)點(diǎn)的長(zhǎng)度；這里的64字節(jié)是指字符串的長(zhǎng)度，不包括SDS結(jié)構(gòu)，
因?yàn)閴嚎s列表使用連續(xù)、定長(zhǎng)內(nèi)存塊存儲(chǔ)字符串，不需要SDS結(jié)構(gòu)指明長(zhǎng)度。后面提到壓縮列表，也會(huì)強(qiáng)調(diào)長(zhǎng)度不超過64字節(jié)，原理
與這里類似。
哈希（作為一種數(shù)據(jù)結(jié)構(gòu)），不僅是redis對(duì)外提供的5種對(duì)象類型的一種（與字符串、列表、集合、有序結(jié)合并列），也是Redis
作為Key-Value數(shù)據(jù)庫(kù)所使用的數(shù)據(jù)結(jié)構(gòu)。為了說(shuō)明的方便，在本文后面當(dāng)使用“內(nèi)層的哈?！睍r(shí)，代表的是redis對(duì)外提供的5種對(duì)象類型
的一種；使用“外層的哈?！贝窻edis作為Key-Value數(shù)據(jù)庫(kù)所使用的數(shù)據(jù)結(jié)構(gòu)。
內(nèi)層的哈希使用的內(nèi)部編碼可以是壓縮列表（www.255055.cn ziplist）和哈希表（hashtable）兩種；Redis的外層的哈希則只使用
了hashtable。
壓縮列表前面已介紹。與哈希表相比，壓縮列表用于元素個(gè)數(shù)少、元素長(zhǎng)度小的場(chǎng)景；其優(yōu)勢(shì)在于集中存儲(chǔ)，節(jié)省空間；同時(shí)，雖
然對(duì)于元素的操作復(fù)雜度也由O(n)變?yōu)榱薕(1)，但由于哈希中元素?cái)?shù)量較少，因此操作的時(shí)間并沒有明顯劣勢(shì)。
hashtable：一個(gè)hashtable由1個(gè)dict結(jié)構(gòu)、2個(gè)dictht結(jié)構(gòu)、1個(gè)dictEntry指針數(shù)組（稱為bucket）和多個(gè)dictEntry結(jié)構(gòu)組成。
正常情況下（即hashtable沒有進(jìn)行rehash時(shí)）各部分關(guān)系如下圖所示：
下面從底層向上依次介紹各個(gè)部分：
dictEntry
dictEntry結(jié)構(gòu)用于保存鍵值對(duì)，結(jié)構(gòu)定義如下：
其中，各個(gè)屬性的功能如下：
key：鍵值對(duì)中的鍵；
val：鍵值對(duì)中的值，使用union(即共用體)實(shí)現(xiàn)，存儲(chǔ)的內(nèi)容既可能是一個(gè)指向值的指針，也可能是64位整型，或無(wú)符號(hào)64位整型；
next：指向下一個(gè)dictEntry，用于解決哈希沖突問題
在64位系統(tǒng)中，一個(gè)dictEntry對(duì)象占24字節(jié)（key/val/next各占8字節(jié)）。
bucket
bucket是一個(gè)數(shù)組，數(shù)組的每個(gè)元素都是指向dictEntry結(jié)構(gòu)的指針。redis中bucket數(shù)組的大小計(jì)算規(guī)則如下：
大于dictEntry的、最小的2^n；
例如，如果有1000個(gè)dictEntry，那么bucket大小為1024；如果有1500個(gè)dictEntry，則bucket大小為2048。
dictht
dictht結(jié)構(gòu)如下：
其中，各個(gè)屬性的功能說(shuō)明如下：
table屬性是一個(gè)指針，指向bucket；
size屬性記錄了哈希表的大小，即www.wanmeiyuele.cn bucket的大?。?/p>
used記錄了已使用的dictEntry的數(shù)量；
sizemask屬性的值總是為size-1，這個(gè)屬性和哈希值一起決定一個(gè)鍵在table中存儲(chǔ)的位置。
dict
一般來(lái)說(shuō)，通過使用dictht和dictEntry結(jié)構(gòu)，便可以實(shí)現(xiàn)普通哈希表的功能；但是Redis的實(shí)現(xiàn)中，在dictht結(jié)構(gòu)的上層，還有一個(gè)
dict結(jié)構(gòu)。下面說(shuō)明dict結(jié)構(gòu)的定義及作用。
dict結(jié)構(gòu)如下：
其中，type屬性和privdata屬性是為了適應(yīng)不同類型的鍵值對(duì)，用于創(chuàng)建多態(tài)字典。
ht屬性和trehashidx屬性則用于rehash，即當(dāng)哈希表需要擴(kuò)展或收縮時(shí)使用。ht是一個(gè)包含兩個(gè)項(xiàng)的數(shù)組，每項(xiàng)都指向一個(gè)dictht結(jié)
構(gòu)，這也是Redis的哈希會(huì)有1個(gè)dict、2個(gè)dictht結(jié)構(gòu)的原因。通常情況下，所有的數(shù)據(jù)都是存在放dict的ht[0]中，ht[1]只在rehash的
時(shí)候使用。dict進(jìn)行rehash操作的時(shí)候，將ht[0]中的所有數(shù)據(jù)rehash到ht[1]中。然后將ht[1]賦值給ht[0]，并清空ht[1]。
因此，Redis中的哈希之所以在dictht和dictEntry結(jié)構(gòu)之外還有一個(gè)dict結(jié)構(gòu)，一方面是為了適應(yīng)不同類型的鍵值對(duì)，另一方面是
為了rehash。
如前所述，Redis中內(nèi)層的哈希既可能使用哈希表，也可能使用壓縮列表。
只有同時(shí)滿足下面兩個(gè)條件時(shí)，才會(huì)使用壓縮列表：哈希中元素?cái)?shù)量小于512個(gè)；哈希中所有鍵值對(duì)的鍵和值字符串長(zhǎng)度都小于64
字節(jié)。如果有一個(gè)條件不滿足，則使用哈希表；且編碼只可能由壓縮列表轉(zhuǎn)化為哈希表，反方向則不可能。
下圖展示了Redis內(nèi)層的哈希編碼轉(zhuǎn)換的特點(diǎn)：
集合（set）與列表類似，都是用來(lái)保存多個(gè)字符串，但集合與列表有兩點(diǎn)不同：集合中的元素是無(wú)序的，因此不能通過索引來(lái)操
作元素；集合中的元素不能有重復(fù)。
一個(gè)集合中最多可以存儲(chǔ)2^32-1個(gè)元素；除了支持常規(guī)的增刪改查，Redis還支持多個(gè)集合取交集、并集、差集。
集合的內(nèi)部編碼可以是整數(shù)集合（intset）或哈希表（hashtable）。
哈希表前面已經(jīng)講過，這里略過不提；需要注意的是，集合在使用哈希表時(shí)，值全部被置為null。
整數(shù)集合的結(jié)構(gòu)定義如下：
其中，encoding代表contents中存儲(chǔ)內(nèi)容的類型，雖然contents（存儲(chǔ)集合中的元素）是int8_t類型，但實(shí)際上其存儲(chǔ)的值是
int16_t、int32_t或int64_t，具體的類型便是由encoding決定的；length表示元素個(gè)數(shù)。
整數(shù)集合適用于集合所有元素都是整數(shù)且集合元素?cái)?shù)量較小的時(shí)候，與哈希表相比，整數(shù)集合的優(yōu)勢(shì)在于集中存儲(chǔ)，節(jié)省空間；
同時(shí)，雖然對(duì)于元素的操作復(fù)雜度也由O(n)變?yōu)榱薕(1)，但由于集合數(shù)量較少，因此操作的時(shí)間并沒有明顯劣勢(shì)。
只有同時(shí)滿足下面兩個(gè)條件時(shí)，集合才會(huì)使用整數(shù)集合：集合中元素?cái)?shù)量小于512個(gè)；集合中所有元素都是整數(shù)值。如果有一個(gè)
條件不滿足，則使用哈希表；且編碼只可能由整數(shù)集合轉(zhuǎn)化為哈希表，反方向則不可能。
下圖展示了集合編碼轉(zhuǎn)換的特點(diǎn)：
有序集合與集合一樣，元素都不能重復(fù)；但與集合不同的是，有序集合中的元素是有順序的。與列表使用索引下標(biāo)作為排序
依據(jù)不同，有序集合為每個(gè)元素設(shè)置一個(gè)分?jǐn)?shù)（score）作為排序依據(jù)。
有序集合的內(nèi)部編碼可以是壓縮列表（ziplist）或跳躍表（skiplist）。
ziplist在列表和哈希中都有使用，前面已經(jīng)講過，這里略過不提。
跳躍表是一種有序數(shù)據(jù)結(jié)構(gòu)，通過在每個(gè)節(jié)點(diǎn)中維持多個(gè)指向其他節(jié)點(diǎn)的指針，從而達(dá)到快速訪問節(jié)點(diǎn)的目的。除了跳躍表，
實(shí)現(xiàn)有序數(shù)據(jù)結(jié)構(gòu)的另一種典型實(shí)現(xiàn)是平衡樹；大多數(shù)情況下，跳躍表的效率可以和平衡樹媲美，且跳躍表實(shí)現(xiàn)比平衡樹簡(jiǎn)單很多，因此redis中選用跳躍表代替平衡樹。跳躍表支持平均O(logN)、最壞O(N)的復(fù)雜點(diǎn)進(jìn)行節(jié)點(diǎn)查找，并支持順序操作。Redis的跳躍表實(shí)現(xiàn)由zskiplist和zskiplistNode兩個(gè)結(jié)構(gòu)組成：前者用于保存跳躍表信息（如頭結(jié)點(diǎn)、尾節(jié)點(diǎn)、長(zhǎng)度等），后者用于表示跳躍表節(jié)點(diǎn)。具體結(jié)構(gòu)相對(duì)比較復(fù)雜，略。
只有同時(shí)滿足下面兩個(gè)條件時(shí)，才會(huì)使用壓縮列表：有序集合中元素?cái)?shù)量小于128個(gè)；有序集合中所有成員長(zhǎng)度都不足64字節(jié)。如果有一個(gè)條件不滿足，則使用跳躍表；且編碼只可能由壓縮列表轉(zhuǎn)化為跳躍表，反方向則不可能。
下圖展示了有序集合編碼轉(zhuǎn)換的特點(diǎn)：
了解Redis的內(nèi)存模型之后，下面通過幾個(gè)例子說(shuō)明其應(yīng)用。
要估算redis中的數(shù)據(jù)占據(jù)的內(nèi)存大小，需要對(duì)redis的內(nèi)存模型有比較全面的了解，包括前面介紹的hashtable、sds、redisobject、各種對(duì)象類型的編碼方式等。
下面以最簡(jiǎn)單的字符串類型來(lái)進(jìn)行說(shuō)明。
假設(shè)有90000個(gè)鍵值對(duì)，每個(gè)key的長(zhǎng)度是7個(gè)字節(jié)，每個(gè)value的長(zhǎng)度也是7個(gè)字節(jié)（且key和value都不是整數(shù)）；下面來(lái)估算這90000個(gè)鍵值對(duì)所占用的空間。在估算占據(jù)空間之前，首先可以判定字符串類型使用的編碼方式：embstr。
90000個(gè)鍵值對(duì)占據(jù)的內(nèi)存空間主要可以分為兩部分：一部分是90000個(gè)dictEntry占據(jù)的空間；一部分是鍵值對(duì)所需要的bucket空間。
每個(gè)dictEntry占據(jù)的空間包括：
一個(gè)dictEntry，24字節(jié)，jemalloc會(huì)分配32字節(jié)的內(nèi)存塊;
一個(gè)key，7字節(jié)，所以SDS(key)需要7+9=16個(gè)字節(jié)，jemalloc會(huì)分配16字節(jié)的內(nèi)存塊;
一個(gè)redisObject，16字節(jié)，jemalloc會(huì)分配16字節(jié)的內(nèi)存塊;
一個(gè)value，7字節(jié)，所以SDS(value)需要7+9=16個(gè)字節(jié)，jemalloc會(huì)分配16字節(jié)的內(nèi)存塊;
綜上，一個(gè)dictEntry需要32+16+16+16=80個(gè)字節(jié);
bucket空間：bucket數(shù)組的大小為大于90000的最小的2^n，是131072；每個(gè)bucket元素為8字節(jié)（因?yàn)?4位系統(tǒng)中指針大小為8字節(jié)）。
因此，可以估算出這90000個(gè)鍵值對(duì)占據(jù)的內(nèi)存大小為：90000*80 + 131072*8 = 8248576。
下面寫個(gè)程序在redis中驗(yàn)證一下：
運(yùn)行結(jié)果：8247552
理論值與結(jié)果值誤差在萬(wàn)分之1.2，對(duì)于計(jì)算需要多少內(nèi)存來(lái)說(shuō)，這個(gè)精度已經(jīng)足夠了。之所以會(huì)存在誤差，是因?yàn)樵谖覀儾迦?0000條數(shù)據(jù)之前redis已分配了一定的bucket空間，而這些bucket空間尚未使用。
作為對(duì)比將key和value的長(zhǎng)度由7字節(jié)增加到8字節(jié)，則對(duì)應(yīng)的SDS變?yōu)?7個(gè)字節(jié)，jemalloc會(huì)分配32個(gè)字節(jié)，因此每個(gè)dictEntry占用的字節(jié)數(shù)也由80字節(jié)變?yōu)?12字節(jié)。此時(shí)估算這90000個(gè)鍵值對(duì)占據(jù)內(nèi)存大小為：90000*112 + 131072*8 = 11128576。
在redis中驗(yàn)證代碼如下（只修改插入數(shù)據(jù)的代碼）：
運(yùn)行結(jié)果：11128576；估算準(zhǔn)確。
對(duì)于字符串類型之外的其他類型，對(duì)內(nèi)存占用的估算方法是類似的，需要結(jié)合具體類型的編碼方式來(lái)確定。
了解redis的內(nèi)存模型，對(duì)優(yōu)化redis內(nèi)存占用有很大幫助。下面介紹幾種優(yōu)化場(chǎng)景。
（1）利用jemalloc特性進(jìn)行優(yōu)化
上一小節(jié)所講述的90000個(gè)鍵值便是一個(gè)例子。由于jemalloc分配內(nèi)存時(shí)數(shù)值是不連續(xù)的，因此key/value字符串變化一個(gè)字節(jié)，可能會(huì)引起占用內(nèi)存很大的變動(dòng)；在設(shè)計(jì)時(shí)可以利用這一點(diǎn)。
例如，如果key的長(zhǎng)度如果是8個(gè)字節(jié)，則SDS為17字節(jié)，jemalloc分配32字節(jié)；此時(shí)將key長(zhǎng)度縮減為7個(gè)字節(jié)，則SDS為16字節(jié)，jemalloc分配16字節(jié)；則每個(gè)key所占用的空間都可以縮小一半。
（2）使用整型/長(zhǎng)整型
如果是整型/長(zhǎng)整型，Redis會(huì)使用int類型（8字節(jié)）存儲(chǔ)來(lái)代替字符串，可以節(jié)省更多空間。因此在可以使用長(zhǎng)整型/整型代替字符串的場(chǎng)景下，盡量使用長(zhǎng)整型/整型。
（3）共享對(duì)象
利用共享對(duì)象，可以減少對(duì)象的創(chuàng)建（同時(shí)減少了redisObject的創(chuàng)建），節(jié)省內(nèi)存空間。目前redis中的共享對(duì)象只包括10000個(gè)整數(shù)（0-9999）；可以通過調(diào)整REDIS_SHARED_INTEGERS參數(shù)提高共享對(duì)象的個(gè)數(shù)；例如將REDIS_SHARED_INTEGERS調(diào)整到20000，則0-19999之間的對(duì)象都可以共享。
考慮這樣一種場(chǎng)景：論壇網(wǎng)站在redis中存儲(chǔ)了每個(gè)帖子的瀏覽數(shù)，而這些瀏覽數(shù)絕大多數(shù)分布在0-20000之間，這時(shí)候通過適當(dāng)增大REDIS_SHARED_INTEGERS參數(shù)，便可以利用共享對(duì)象節(jié)省內(nèi)存空間。
（4）避免過度設(shè)計(jì)
然而需要注意的是，不論是哪種優(yōu)化場(chǎng)景，都要考慮內(nèi)存空間與設(shè)計(jì)復(fù)雜度的權(quán)衡；而設(shè)計(jì)復(fù)雜度會(huì)影響到代碼的復(fù)雜度、可維護(hù)性。
如果數(shù)據(jù)量較小，那么為了節(jié)省內(nèi)存而使得代碼的開發(fā)、維護(hù)變得更加困難并不劃算；還是以前面講到的90000個(gè)鍵值對(duì)為例，實(shí)際上節(jié)省的內(nèi)存空間只有幾MB。但是如果數(shù)據(jù)量有幾千萬(wàn)甚至上億，考慮內(nèi)存的優(yōu)化就比較必要了。
內(nèi)存碎片率是一個(gè)重要的參數(shù)，對(duì)redis 內(nèi)存的優(yōu)化有重要意義。
如果內(nèi)存碎片率過高（jemalloc在1.03左右比較正常），說(shuō)明內(nèi)存碎片多，內(nèi)存浪費(fèi)嚴(yán)重；這時(shí)便可以考慮重啟redis服務(wù)，在內(nèi)存中對(duì)數(shù)據(jù)進(jìn)行重排，減少內(nèi)存碎片。
如果內(nèi)存碎片率小于1，說(shuō)明redis內(nèi)存不足，部分?jǐn)?shù)據(jù)使用了虛擬內(nèi)存（即swap）；由于虛擬內(nèi)存的存取速度比物理內(nèi)存差很多（2-3個(gè)數(shù)量級(jí)），此時(shí)redis的訪問速度可能會(huì)變得很慢。因此必須設(shè)法增大物理內(nèi)存（可以增加服務(wù)器節(jié)點(diǎn)數(shù)量，或提高單機(jī)內(nèi)存），或減少redis中的數(shù)據(jù)。
要減少redis中的數(shù)據(jù)，除了選用合適的數(shù)據(jù)類型、利用共享對(duì)象等，還有一點(diǎn)是要設(shè)置合理的數(shù)據(jù)回收策略（maxmemory-policy），當(dāng)內(nèi)存達(dá)到一定量后，根據(jù)不同的優(yōu)先級(jí)對(duì)內(nèi)存進(jìn)行回收。
“Redis內(nèi)存對(duì)像模型分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼
