redis 内存不足 排查_一文深入了解 Redis 内存模型，Redis 的快是有原因的！
- 前言
- 一、Redis內存統(tǒng)計
- 二、Redis內存劃分
- 1、數(shù)據(jù)
- 2、進程本身運行需要的內存
- 3、緩沖內存
- 4、內存碎片
- 三、Redis數(shù)據(jù)存儲的細節(jié)
- 1、概述
- 2、jemalloc
- 3、redisObject
- 4、SDS
- 四、Redis的對象類型與內部編碼
- 1、字符串
- 2、列表
- 3、哈希
- 4、集合
- 5、有序集合
- 五、應用舉例
- 1、估算Redis內存使用量
- 2、優(yōu)化內存占用
- 3、關注內存碎片率
- 《Java 2019 超神之路》
- 《Dubbo 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《Spring 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《MyBatis 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《Spring MVC 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《Spring Boot 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《數(shù)據(jù)庫實體設計合集》
- 《Java 面試題 —— 精品合集》
- 《Java 學習指南 —— 精品合集》
前言
Redis是目前最火爆的內存數(shù)據(jù)庫之一，通過在內存中讀寫數(shù)據(jù)，大大提高了讀寫速度，可以說Redis是實現(xiàn)網站高并發(fā)不可或缺的一部分。
我們使用Redis時，會接觸Redis的5種對象類型（字符串、哈希、列表、集合、有序集合），豐富的類型是Redis相對于Memcached等的一大優(yōu)勢。在了解Redis的5種對象類型的用法和特點的基礎上，進一步了解Redis的內存模型，對Redis的使用有很大幫助，例如：
1、估算Redis內存使用量。目前為止，內存的使用成本仍然相對較高，使用內存不能無所顧忌；根據(jù)需求合理的評估Redis的內存使用量，選擇合適的機器配置，可以在滿足需求的情況下節(jié)約成本。
2、優(yōu)化內存占用。了解Redis內存模型可以選擇更合適的數(shù)據(jù)類型和編碼，更好的利用Redis內存。
3、分析解決問題。當Redis出現(xiàn)阻塞、內存占用等問題時，盡快發(fā)現(xiàn)導致問題的原因，便于分析解決問題。
這篇文章主要介紹Redis的內存模型（以3.0為例），包括Redis占用內存的情況及如何查詢、不同的對象類型在內存中的編碼方式、內存分配器(jemalloc)、簡單動態(tài)字符串(SDS)、RedisObject等；然后在此基礎上介紹幾個Redis內存模型的應用。
在后面的文章中，會陸續(xù)介紹關于Redis高可用的內容，包括主從復制、哨兵、集群等等，歡迎關注。
一、Redis內存統(tǒng)計
工欲善其事必先利其器，在說明Redis內存之前首先說明如何統(tǒng)計Redis使用內存的情況。
在客戶端通過redis-cli連接服務器后（后面如無特殊說明，客戶端一律使用redis-cli），通過info命令可以查看內存使用情況：
info memory其中，info命令可以顯示redis服務器的許多信息，包括服務器基本信息、CPU、內存、持久化、客戶端連接信息等等；memory是參數(shù)，表示只顯示內存相關的信息。
返回結果中比較重要的幾個說明如下：
（1）*used_memory：Redis分配器分配的內存總量（單位是字節(jié)），包括使用的虛擬內存（即swap）；Redis分配器后面會介紹。used_memory_human只是顯示更友好。
（2）used_memory_rs：Redis進程占據(jù)操作系統(tǒng)的內存（單位是字節(jié)），與top及ps命令看到的值是一致的；除了分配器分配的內存之外，used_memory_rss還包括進程運行本身需要的內存、內存碎片等，但是不包括虛擬內存。
因此，used_memory和used_memory_rss，前者是從Redis角度得到的量，后者是從操作系統(tǒng)角度得到的量。二者之所以有所不同，一方面是因為內存碎片和Redis進程運行需要占用內存，使得前者可能比后者小，另一方面虛擬內存的存在，使得前者可能比后者大。
由于在實際應用中，Redis的數(shù)據(jù)量會比較大，此時進程運行占用的內存與Redis數(shù)據(jù)量和內存碎片相比，都會小得多；因此used_memory_rss和used_memory的比例，便成了衡量Redis內存碎片率的參數(shù)；這個參數(shù)就是mem_fragmentation_ratio。
（3）mem_fragmentation_ratio：內存碎片比率，該值是used_memory_rss / used_memory的比值。
mem_fragmentation_ratio一般大于1，且該值越大，內存碎片比例越大。mem_fragmentation_ratio<1，說明Redis使用了虛擬內存，由于虛擬內存的媒介是磁盤，比內存速度要慢很多，當這種情況出現(xiàn)時，應該及時排查，如果內存不足應該及時處理，如增加Redis節(jié)點、增加Redis服務器的內存、優(yōu)化應用等。
一般來說，mem_fragmentation_ratio在1.03左右是比較健康的狀態(tài)（對于jemalloc來說）；上面截圖中的mem_fragmentation_ratio值很大，是因為還沒有向Redis中存入數(shù)據(jù)，Redis進程本身運行的內存使得used_memory_rss 比used_memory大得多。
（4）mem_allocator：Redis使用的內存分配器，在編譯時指定；可以是 libc 、jemalloc或者tcmalloc，默認是jemalloc；截圖中使用的便是默認的jemalloc。
二、Redis內存劃分
Redis作為內存數(shù)據(jù)庫，在內存中存儲的內容主要是數(shù)據(jù)（鍵值對）；通過前面的敘述可以知道，除了數(shù)據(jù)以外，Redis的其他部分也會占用內存。
Redis的內存占用主要可以劃分為以下幾個部分：
1、數(shù)據(jù)
作為數(shù)據(jù)庫，數(shù)據(jù)是最主要的部分；這部分占用的內存會統(tǒng)計在used_memory中。
Redis使用鍵值對存儲數(shù)據(jù)，其中的值（對象）包括5種類型，即字符串、哈希、列表、集合、有序集合。這5種類型是Redis對外提供的，實際上，在Redis內部，每種類型可能有2種或更多的內部編碼實現(xiàn)；此外，Redis在存儲對象時，并不是直接將數(shù)據(jù)扔進內存，而是會對對象進行各種包裝：如redisObject、SDS等；這篇文章后面將重點介紹Redis中數(shù)據(jù)存儲的細節(jié)。
2、進程本身運行需要的內存
Redis主進程本身運行肯定需要占用內存，如代碼、常量池等等；這部分內存大約幾兆，在大多數(shù)生產環(huán)境中與Redis數(shù)據(jù)占用的內存相比可以忽略。這部分內存不是由jemalloc分配，因此不會統(tǒng)計在used_memory中。
補充說明：除了主進程外，Redis創(chuàng)建的子進程運行也會占用內存，如Redis執(zhí)行AOF、RDB重寫時創(chuàng)建的子進程。當然，這部分內存不屬于Redis進程，也不會統(tǒng)計在used_memory和used_memory_rss中。
3、緩沖內存
緩沖內存包括客戶端緩沖區(qū)、復制積壓緩沖區(qū)、AOF緩沖區(qū)等；其中，客戶端緩沖存儲客戶端連接的輸入輸出緩沖；復制積壓緩沖用于部分復制功能；AOF緩沖區(qū)用于在進行AOF重寫時，保存最近的寫入命令。在了解相應功能之前，不需要知道這些緩沖的細節(jié)；這部分內存由jemalloc分配，因此會統(tǒng)計在used_memory中。
4、內存碎片
內存碎片是Redis在分配、回收物理內存過程中產生的。例如，如果對數(shù)據(jù)的更改頻繁，而且數(shù)據(jù)之間的大小相差很大，可能導致redis釋放的空間在物理內存中并沒有釋放，但redis又無法有效利用，這就形成了內存碎片。內存碎片不會統(tǒng)計在used_memory中。
內存碎片的產生與對數(shù)據(jù)進行的操作、數(shù)據(jù)的特點等都有關；此外，與使用的內存分配器也有關系：如果內存分配器設計合理，可以盡可能的減少內存碎片的產生。后面將要說到的jemalloc便在控制內存碎片方面做的很好。
如果Redis服務器中的內存碎片已經很大，可以通過安全重啟的方式減小內存碎片：因為重啟之后，Redis重新從備份文件中讀取數(shù)據(jù)，在內存中進行重排，為每個數(shù)據(jù)重新選擇合適的內存單元，減小內存碎片。
三、Redis數(shù)據(jù)存儲的細節(jié)
1、概述
關于Redis數(shù)據(jù)存儲的細節(jié)，涉及到內存分配器（如jemalloc）、簡單動態(tài)字符串（SDS）、5種對象類型及內部編碼、redisObject。在講述具體內容之前，先說明一下這幾個概念之間的關系。
下圖是執(zhí)行set hello world時，所涉及到的數(shù)據(jù)模型。
圖片來源：https://searchdatabase.techtarget.com.cn/7-20218/
（1）dictEntry：Redis是Key-Value數(shù)據(jù)庫，因此對每個鍵值對都會有一個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個字節(jié)，jemalloc會為它分配32字節(jié)大小的內存單元。
下面來分別介紹jemalloc、redisObject、SDS、對象類型及內部編碼。
2、jemalloc
Redis在編譯時便會指定內存分配器；內存分配器可以是 libc 、jemalloc或者tcmalloc，默認是jemalloc。
jemalloc作為Redis的默認內存分配器，在減小內存碎片方面做的相對比較好。jemalloc在64位系統(tǒng)中，將內存空間劃分為小、大、巨大三個范圍；每個范圍內又劃分了許多小的內存塊單位；當Redis存儲數(shù)據(jù)時，會選擇大小最合適的內存塊進行存儲。
jemalloc劃分的內存單元如下圖所示：
圖片來源：http://blog.csdn.net/zhengpeitao/article/details/76573053
例如，如果需要存儲大小為130字節(jié)的對象，jemalloc會將其放入160字節(jié)的內存單元中。
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(有序集合)。
當我們執(zhí)行type命令時，便是通過讀取RedisObject的type字段獲得對象的類型；如下圖所示：
（2）encoding
encoding表示對象的內部編碼，占4個比特。
對于Redis支持的每種類型，都有至少兩種內部編碼，例如對于字符串，有int、embstr、raw三種編碼。通過encoding屬性，Redis可以根據(jù)不同的使用場景來為對象設置不同的編碼，大大提高了Redis的靈活性和效率。以列表對象為例，有壓縮列表和雙端鏈表兩種編碼方式；如果列表中的元素較少，Redis傾向于使用壓縮列表進行存儲，因為壓縮列表占用內存更少，而且比雙端鏈表可以更快載入；當列表對象元素較多時，壓縮列表就會轉化為更適合存儲大量元素的雙端鏈表。
通過object encoding命令，可以查看對象采用的編碼方式，如下圖所示：
5種對象類型對應的編碼方式以及使用條件，將在后面介紹。
（3）lru
lru記錄的是對象最后一次被命令程序訪問的時間，占據(jù)的比特數(shù)不同的版本有所不同（如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會優(yōu)先選擇空轉時間最長的對象進行釋放。
（4）refcount
refcount與共享對象
refcount記錄的是該對象被引用的次數(shù)，類型為整型。refcount的作用，主要在于對象的引用計數(shù)和內存回收。當創(chuàng)建新對象時，refcount初始化為1；當有新程序使用該對象時，refcount加1；當對象不再被一個新程序使用時，refcount減1；當refcount變?yōu)?時，對象占用的內存會被釋放。
Redis中被多次使用的對象(refcount>1)，稱為共享對象。Redis為了節(jié)省內存，當有一些對象重復出現(xiàn)時，新的程序不會創(chuàng)建新的對象，而是仍然使用原來的對象。這個被重復使用的對象，就是共享對象。目前共享對象僅支持整數(shù)值的字符串對象。
共享對象的具體實現(xiàn)
Redis的共享對象目前只支持整數(shù)值的字符串對象。之所以如此，實際上是對內存和CPU（時間）的平衡：共享對象雖然會降低內存消耗，但是判斷兩個對象是否相等卻需要消耗額外的時間。對于整數(shù)值，判斷操作復雜度為O(1)；對于普通字符串，判斷復雜度為O(n)；而對于哈希、列表、集合和有序集合，判斷的復雜度為O(n^2)。
雖然共享對象只能是整數(shù)值的字符串對象，但是5種類型都可能使用共享對象（如哈希、列表等的元素可以使用）。
就目前的實現(xiàn)來說，Redis服務器在初始化時，會創(chuàng)建10000個字符串對象，值分別是0~9999的整數(shù)值；當Redis需要使用值為0~9999的字符串對象時，可以直接使用這些共享對象。10000這個數(shù)字可以通過調整參數(shù)REDIS_SHARED_INTEGERS（4.0中是OBJ_SHARED_INTEGERS）的值進行改變。
共享對象的引用次數(shù)可以通過object refcount命令查看，如下圖所示。命令執(zhí)行的結果頁佐證了只有0~9999之間的整數(shù)會作為共享對象。
（5）ptr
ptr指針指向具體的數(shù)據(jù)，如前面的例子中，set hello world，ptr指向包含字符串world的SDS。
（6）總結
綜上所述，redisObject的結構與對象類型、編碼、內存回收、共享對象都有關系；一個redisObject對象的大小為16字節(jié)：
4bit+4bit+24bit+4Byte+8Byte=16Byte。
4、SDS
Redis沒有直接使用C字符串(即以空字符’0’結尾的字符數(shù)組)作為默認的字符串表示，而是使用了SDS。SDS是簡單動態(tài)字符串(Simple Dynamic String)的縮寫。
（1）SDS結構
sds的結構如下：
struct sdshdr {int len;int free;char buf[]; };其中，buf表示字節(jié)數(shù)組，用來存儲字符串；len表示buf已使用的長度，free表示buf未使用的長度。下面是兩個例子。
圖片來源：《Redis設計與實現(xiàn)》
通過SDS的結構可以看出，buf數(shù)組的長度=free+len+1（其中1表示字符串結尾的空字符）；所以，一個SDS結構占據(jù)的空間為：free所占長度+len所占長度+ buf數(shù)組的長度=4+4+free+len+1=free+len+9。
（2）SDS與C字符串的比較
SDS在C字符串的基礎上加入了free和len字段，帶來了很多好處：
- 獲取字符串長度：SDS是O(1)，C字符串是O(n)
- 緩沖區(qū)溢出：使用C字符串的API時，如果字符串長度增加（如strcat操作）而忘記重新分配內存，很容易造成緩沖區(qū)的溢出；而SDS由于記錄了長度，相應的API在可能造成緩沖區(qū)溢出時會自動重新分配內存，杜絕了緩沖區(qū)溢出。
- 修改字符串時內存的重分配：對于C字符串，如果要修改字符串，必須要重新分配內存（先釋放再申請），因為如果沒有重新分配，字符串長度增大時會造成內存緩沖區(qū)溢出，字符串長度減小時會造成內存泄露。而對于SDS，由于可以記錄len和free，因此解除了字符串長度和空間數(shù)組長度之間的關聯(lián)，可以在此基礎上進行優(yōu)化：空間預分配策略（即分配內存時比實際需要的多）使得字符串長度增大時重新分配內存的概率大大減小；惰性空間釋放策略使得字符串長度減小時重新分配內存的概率大大減小。
- 存取二進制數(shù)據(jù)：SDS可以，C字符串不可以。因為C字符串以空字符作為字符串結束的標識，而對于一些二進制文件（如圖片等），內容可能包括空字符串，因此C字符串無法正確存取；而SDS以字符串長度len來作為字符串結束標識，因此沒有這個問題。
此外，由于SDS中的buf仍然使用了C字符串（即以’0’結尾），因此SDS可以使用C字符串庫中的部分函數(shù)；但是需要注意的是，只有當SDS用來存儲文本數(shù)據(jù)時才可以這樣使用，在存儲二進制數(shù)據(jù)時則不行（’0’不一定是結尾）。
（3）SDS與C字符串的應用
Redis在存儲對象時，一律使用SDS代替C字符串。例如set hello world命令，hello和world都是以SDS的形式存儲的。而sadd myset member1 member2 member3命令，不論是鍵（”myset”），還是集合中的元素（”member1”、 ”member2”和”member3”），都是以SDS的形式存儲。除了存儲對象，SDS還用于存儲各種緩沖區(qū)。
只有在字符串不會改變的情況下，如打印日志時，才會使用C字符串。
四、Redis的對象類型與內部編碼
前面已經說過，Redis支持5種對象類型，而每種結構都有至少兩種編碼；這樣做的好處在于：一方面接口與實現(xiàn)分離，當需要增加或改變內部編碼時，用戶使用不受影響，另一方面可以根據(jù)不同的應用場景切換內部編碼，提高效率。
Redis各種對象類型支持的內部編碼如下圖所示(圖中版本是Redis3.0，Redis后面版本中又增加了內部編碼，略過不提；本章所介紹的內部編碼都是基于3.0的)：
圖片來源：《Redis設計與實現(xiàn)》
關于Redis內部編碼的轉換，都符合以下規(guī)律：編碼轉換在Redis寫入數(shù)據(jù)時完成，且轉換過程不可逆，只能從小內存編碼向大內存編碼轉換。
1、字符串
（1）概況
字符串是最基礎的類型，因為所有的鍵都是字符串類型，且字符串之外的其他幾種復雜類型的元素也是字符串。
字符串長度不能超過512MB。
（2）內部編碼
字符串類型的內部編碼有3種，它們的應用場景如下：
- int：8個字節(jié)的長整型。字符串值是整型時，這個值使用long整型表示。
- embstr：<=39字節(jié)的字符串。embstr與raw都使用redisObject和sds保存數(shù)據(jù)，區(qū)別在于，embstr的使用只分配一次內存空間（因此redisObject和sds是連續(xù)的），而raw需要分配兩次內存空間（分別為redisObject和sds分配空間）。因此與raw相比，embstr的好處在于創(chuàng)建時少分配一次空間，刪除時少釋放一次空間，以及對象的所有數(shù)據(jù)連在一起，尋找方便。而embstr的壞處也很明顯，如果字符串的長度增加需要重新分配內存時，整個redisObject和sds都需要重新分配空間，因此redis中的embstr實現(xiàn)為只讀。
- raw：大于39個字節(jié)的字符串
示例如下圖所示：
embstr和raw進行區(qū)分的長度，是39；是因為redisObject的長度是16字節(jié)，sds的長度是9+字符串長度；因此當字符串長度是39時，embstr的長度正好是16+9+39=64，jemalloc正好可以分配64字節(jié)的內存單元。
（3）編碼轉換
當int數(shù)據(jù)不再是整數(shù)，或大小超過了long的范圍時，自動轉化為raw。
而對于embstr，由于其實現(xiàn)是只讀的，因此在對embstr對象進行修改時，都會先轉化為raw再進行修改，因此，只要是修改embstr對象，修改后的對象一定是raw的，無論是否達到了39個字節(jié)。示例如下圖所示：
2、列表
（1）概況
列表（list）用來存儲多個有序的字符串，每個字符串稱為元素；一個列表可以存儲2^32-1個元素。Redis中的列表支持兩端插入和彈出，并可以獲得指定位置（或范圍）的元素，可以充當數(shù)組、隊列、棧等。
（2）內部編碼
列表的內部編碼可以是壓縮列表（ziplist）或雙端鏈表（linkedlist）。
雙端鏈表：由一個list結構和多個listNode結構組成；典型結構如下圖所示：
圖片來源：《Redis設計與實現(xiàn)》
通過圖中可以看出，雙端鏈表同時保存了表頭指針和表尾指針，并且每個節(jié)點都有指向前和指向后的指針；鏈表中保存了列表的長度；dup、free和match為節(jié)點值設置類型特定函數(shù)，所以鏈表可以用于保存各種不同類型的值。而鏈表中每個節(jié)點指向的是type為字符串的redisObject。
壓縮列表：壓縮列表是Redis為了節(jié)約內存而開發(fā)的，是由一系列特殊編碼的連續(xù)內存塊(而不是像雙端鏈表一樣每個節(jié)點是指針)組成的順序型數(shù)據(jù)結構；具體結構相對比較復雜，略。與雙端鏈表相比，壓縮列表可以節(jié)省內存空間，但是進行修改或增刪操作時，復雜度較高；因此當節(jié)點數(shù)量較少時，可以使用壓縮列表；但是節(jié)點數(shù)量多時，還是使用雙端鏈表劃算。
壓縮列表不僅用于實現(xiàn)列表，也用于實現(xiàn)哈希、有序列表；使用非常廣泛。
（3）編碼轉換
只有同時滿足下面兩個條件時，才會使用壓縮列表：列表中元素數(shù)量小于512個；列表中所有字符串對象都不足64字節(jié)。如果有一個條件不滿足，則使用雙端列表；且編碼只可能由壓縮列表轉化為雙端鏈表，反方向則不可能。
下圖展示了列表編碼轉換的特點：
其中，單個字符串不能超過64字節(jié)，是為了便于統(tǒng)一分配每個節(jié)點的長度；這里的64字節(jié)是指字符串的長度，不包括SDS結構，因為壓縮列表使用連續(xù)、定長內存塊存儲字符串，不需要SDS結構指明長度。后面提到壓縮列表，也會強調長度不超過64字節(jié)，原理與這里類似。
3、哈希
（1）概況
哈希（作為一種數(shù)據(jù)結構），不僅是redis對外提供的5種對象類型的一種（與字符串、列表、集合、有序結合并列），也是Redis作為Key-Value數(shù)據(jù)庫所使用的數(shù)據(jù)結構。為了說明的方便，在本文后面當使用“內層的哈?！睍r，代表的是redis對外提供的5種對象類型的一種；使用“外層的哈希”代指Redis作為Key-Value數(shù)據(jù)庫所使用的數(shù)據(jù)結構。
（2）內部編碼
內層的哈希使用的內部編碼可以是壓縮列表（ziplist）和哈希表（hashtable）兩種；Redis的外層的哈希則只使用了hashtable。
壓縮列表前面已介紹。與哈希表相比，壓縮列表用于元素個數(shù)少、元素長度小的場景；其優(yōu)勢在于集中存儲，節(jié)省空間；同時，雖然對于元素的操作復雜度也由O(1)變?yōu)榱薕(n)，但由于哈希中元素數(shù)量較少，因此操作的時間并沒有明顯劣勢。
hashtable：一個hashtable由1個dict結構、2個dictht結構、1個dictEntry指針數(shù)組（稱為bucket）和多個dictEntry結構組成。
正常情況下（即hashtable沒有進行rehash時）各部分關系如下圖所示：
圖片改編自：《Redis設計與實現(xiàn)》
下面從底層向上依次介紹各個部分：
dictEntry
dictEntry結構用于保存鍵值對，結構定義如下：
typedef` `struct` `dictEntry{`` ``void` `*key;`` ``union``{`` ``void` `*val;`` ``uint64_tu64;`` ``int64_ts64;`` ``}v;`` ``struct` `dictEntry *next;``}dictEntry;其中，各個屬性的功能如下：
- key：鍵值對中的鍵；
- val：鍵值對中的值，使用union(即共用體)實現(xiàn)，存儲的內容既可能是一個指向值的指針，也可能是64位整型，或無符號64位整型；
- next：指向下一個dictEntry，用于解決哈希沖突問題
在64位系統(tǒng)中，一個dictEntry對象占24字節(jié)（key/val/next各占8字節(jié)）。
bucket
bucket是一個數(shù)組，數(shù)組的每個元素都是指向dictEntry結構的指針。redis中bucket數(shù)組的大小計算規(guī)則如下：大于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的數(shù)量；
- sizemask屬性的值總是為size-1，這個屬性和哈希值一起決定一個鍵在table中存儲的位置。
dict
一般來說，通過使用dictht和dictEntry結構，便可以實現(xiàn)普通哈希表的功能；但是Redis的實現(xiàn)中，在dictht結構的上層，還有一個dict結構。下面說明dict結構的定義及作用。
dict結構如下：
typedef struct dict{dictType *type;void *privdata;dictht ht[2];int trehashidx; } dict;其中，type屬性和privdata屬性是為了適應不同類型的鍵值對，用于創(chuàng)建多態(tài)字典。
ht屬性和trehashidx屬性則用于rehash，即當哈希表需要擴展或收縮時使用。ht是一個包含兩個項的數(shù)組，每項都指向一個dictht結構，這也是Redis的哈希會有1個dict、2個dictht結構的原因。通常情況下，所有的數(shù)據(jù)都是存在放dict的ht[0]中，ht[1]只在rehash的時候使用。dict進行rehash操作的時候，將ht[0]中的所有數(shù)據(jù)rehash到ht[1]中。然后將ht[1]賦值給ht[0]，并清空ht[1]。
因此，Redis中的哈希之所以在dictht和dictEntry結構之外還有一個dict結構，一方面是為了適應不同類型的鍵值對，另一方面是為了rehash。
（3）編碼轉換
如前所述，Redis中內層的哈希既可能使用哈希表，也可能使用壓縮列表。
只有同時滿足下面兩個條件時，才會使用壓縮列表：哈希中元素數(shù)量小于512個；哈希中所有鍵值對的鍵和值字符串長度都小于64字節(jié)。如果有一個條件不滿足，則使用哈希表；且編碼只可能由壓縮列表轉化為哈希表，反方向則不可能。
下圖展示了Redis內層的哈希編碼轉換的特點：
4、集合
（1）概況
集合（set）與列表類似，都是用來保存多個字符串，但集合與列表有兩點不同：集合中的元素是無序的，因此不能通過索引來操作元素；集合中的元素不能有重復。
一個集合中最多可以存儲2^32-1個元素；除了支持常規(guī)的增刪改查，Redis還支持多個集合取交集、并集、差集。
（2）內部編碼
集合的內部編碼可以是整數(shù)集合（intset）或哈希表（hashtable）。
哈希表前面已經講過，這里略過不提；需要注意的是，集合在使用哈希表時，值全部被置為null。
整數(shù)集合的結構定義如下：
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表示元素個數(shù)。
整數(shù)集合適用于集合所有元素都是整數(shù)且集合元素數(shù)量較小的時候，與哈希表相比，整數(shù)集合的優(yōu)勢在于集中存儲，節(jié)省空間；同時，雖然對于元素的操作復雜度也由O(1)變?yōu)榱薕(n)，但由于集合數(shù)量較少，因此操作的時間并沒有明顯劣勢。
（3）編碼轉換
只有同時滿足下面兩個條件時，集合才會使用整數(shù)集合：集合中元素數(shù)量小于512個；集合中所有元素都是整數(shù)值。如果有一個條件不滿足，則使用哈希表；且編碼只可能由整數(shù)集合轉化為哈希表，反方向則不可能。
下圖展示了集合編碼轉換的特點：
5、有序集合
（1）概況
有序集合與集合一樣，元素都不能重復；但與集合不同的是，有序集合中的元素是有順序的。與列表使用索引下標作為排序依據(jù)不同，有序集合為每個元素設置一個分數(shù)（score）作為排序依據(jù)。
（2）內部編碼
有序集合的內部編碼可以是壓縮列表（ziplist）或跳躍表（skiplist）。ziplist在列表和哈希中都有使用，前面已經講過，這里略過不提。
跳躍表是一種有序數(shù)據(jù)結構，通過在每個節(jié)點中維持多個指向其他節(jié)點的指針，從而達到快速訪問節(jié)點的目的。除了跳躍表，實現(xiàn)有序數(shù)據(jù)結構的另一種典型實現(xiàn)是平衡樹；大多數(shù)情況下，跳躍表的效率可以和平衡樹媲美，且跳躍表實現(xiàn)比平衡樹簡單很多，因此redis中選用跳躍表代替平衡樹。跳躍表支持平均O(logN)、最壞O(N)的復雜點進行節(jié)點查找，并支持順序操作。Redis的跳躍表實現(xiàn)由zskiplist和zskiplistNode兩個結構組成：前者用于保存跳躍表信息（如頭結點、尾節(jié)點、長度等），后者用于表示跳躍表節(jié)點。具體結構相對比較復雜，略。
（3）編碼轉換
只有同時滿足下面兩個條件時，才會使用壓縮列表：有序集合中元素數(shù)量小于128個；有序集合中所有成員長度都不足64字節(jié)。如果有一個條件不滿足，則使用跳躍表；且編碼只可能由壓縮列表轉化為跳躍表，反方向則不可能。
下圖展示了有序集合編碼轉換的特點：
五、應用舉例
了解Redis的內存模型之后，下面通過幾個例子說明其應用。
1、估算Redis內存使用量
要估算redis中的數(shù)據(jù)占據(jù)的內存大小，需要對redis的內存模型有比較全面的了解，包括前面介紹的hashtable、sds、redisobject、各種對象類型的編碼方式等。
下面以最簡單的字符串類型來進行說明。
假設有90000個鍵值對，每個key的長度是7個字節(jié)，每個value的長度也是7個字節(jié)（且key和value都不是整數(shù)）；下面來估算這90000個鍵值對所占用的空間。在估算占據(jù)空間之前，首先可以判定字符串類型使用的編碼方式：embstr。
90000個鍵值對占據(jù)的內存空間主要可以分為兩部分：一部分是90000個dictEntry占據(jù)的空間；一部分是鍵值對所需要的bucket空間。
每個dictEntry占據(jù)的空間包括：
bucket空間：bucket數(shù)組的大小為大于90000的最小的2^n，是131072；每個bucket元素為8字節(jié)（因為64位系統(tǒng)中指針大小為8字節(jié)）。
因此，可以估算出這90000個鍵值對占據(jù)的內存大小為：9000080 + 1310728 = 8248576。
下面寫個程序在redis中驗證一下：
publicclass RedisTest {publicstatic 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字節(jié)，且不是整數(shù)}}public static String getMemory(){String memoryAllLine = jedis.info("memory");String usedMemoryLine = memoryAllLine.split("rn")[1];String memory = usedMemoryLine.substring(usedMemoryLine.indexOf(':') + 1);return memory;} }運行結果：8247552
理論值與結果值誤差在萬分之1.2，對于計算需要多少內存來說，這個精度已經足夠了。之所以會存在誤差，是因為在我們插入90000條數(shù)據(jù)之前redis已分配了一定的bucket空間，而這些bucket空間尚未使用。
作為對比將key和value的長度由7字節(jié)增加到8字節(jié)，則對應的SDS變?yōu)?7個字節(jié)，jemalloc會分配32個字節(jié)，因此每個dictEntry占用的字節(jié)數(shù)也由80字節(jié)變?yōu)?12字節(jié)。此時估算這90000個鍵值對占據(jù)內存大小為：90000112 + 1310728 = 11128576。
在redis中驗證代碼如下（只修改插入數(shù)據(jù)的代碼）：
public static void insertData(){for(int i = 10000; i < 100000; i++){jedis.set("aaa" + i, "aaa" + i); //key和value長度都是8字節(jié)，且不是整數(shù)} }運行結果：11128576；估算準確。
對于字符串類型之外的其他類型，對內存占用的估算方法是類似的，需要結合具體類型的編碼方式來確定。
2、優(yōu)化內存占用
了解redis的內存模型，對優(yōu)化redis內存占用有很大幫助。下面介紹幾種優(yōu)化場景。
（1）利用jemalloc特性進行優(yōu)化
上一小節(jié)所講述的90000個鍵值便是一個例子。由于jemalloc分配內存時數(shù)值是不連續(xù)的，因此key/value字符串變化一個字節(jié)，可能會引起占用內存很大的變動；在設計時可以利用這一點。
例如，如果key的長度如果是8個字節(jié)，則SDS為17字節(jié)，jemalloc分配32字節(jié)；此時將key長度縮減為7個字節(jié)，則SDS為16字節(jié)，jemalloc分配16字節(jié)；則每個key所占用的空間都可以縮小一半。
（2）使用整型/長整型
如果是整型/長整型，Redis會使用int類型（8字節(jié)）存儲來代替字符串，可以節(jié)省更多空間。因此在可以使用長整型/整型代替字符串的場景下，盡量使用長整型/整型。
（3）共享對象
利用共享對象，可以減少對象的創(chuàng)建（同時減少了redisObject的創(chuàng)建），節(jié)省內存空間。目前redis中的共享對象只包括10000個整數(shù)（0-9999）；可以通過調整REDIS_SHARED_INTEGERS參數(shù)提高共享對象的個數(shù)；例如將REDIS_SHARED_INTEGERS調整到20000，則0-19999之間的對象都可以共享。
考慮這樣一種場景：論壇網站在redis中存儲了每個帖子的瀏覽數(shù)，而這些瀏覽數(shù)絕大多數(shù)分布在0-20000之間，這時候通過適當增大REDIS_SHARED_INTEGERS參數(shù)，便可以利用共享對象節(jié)省內存空間。
（4）避免過度設計
然而需要注意的是，不論是哪種優(yōu)化場景，都要考慮內存空間與設計復雜度的權衡；而設計復雜度會影響到代碼的復雜度、可維護性。
如果數(shù)據(jù)量較小，那么為了節(jié)省內存而使得代碼的開發(fā)、維護變得更加困難并不劃算；還是以前面講到的90000個鍵值對為例，實際上節(jié)省的內存空間只有幾MB。但是如果數(shù)據(jù)量有幾千萬甚至上億，考慮內存的優(yōu)化就比較必要了。
3、關注內存碎片率
內存碎片率是一個重要的參數(shù)，對redis 內存的優(yōu)化有重要意義。
如果內存碎片率過高（jemalloc在1.03左右比較正常），說明內存碎片多，內存浪費嚴重；這時便可以考慮重啟redis服務，在內存中對數(shù)據(jù)進行重排，減少內存碎片。
如果內存碎片率小于1，說明redis內存不足，部分數(shù)據(jù)使用了虛擬內存（即swap）；由于虛擬內存的存取速度比物理內存差很多（2-3個數(shù)量級），此時redis的訪問速度可能會變得很慢。因此必須設法增大物理內存（可以增加服務器節(jié)點數(shù)量，或提高單機內存），或減少redis中的數(shù)據(jù)。
要減少redis中的數(shù)據(jù)，除了選用合適的數(shù)據(jù)類型、利用共享對象等，還有一點是要設置合理的數(shù)據(jù)回收策略（maxmemory-policy），當內存達到一定量后，根據(jù)不同的優(yōu)先級對內存進行回收。
來源：編程迷思
http://cnblogs.com/kismetv/p/8654978.html
- 《Java 2019 超神之路》
- 《Dubbo 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《Spring 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《MyBatis 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《Spring MVC 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《Spring Boot 實現(xiàn)原理與源碼解析 —— 精品合集》
- 《數(shù)據(jù)庫實體設計合集》
- 《Java 面試題 —— 精品合集》
- 《Java 學習指南 —— 精品合集》
總結
以上是生活随笔為你收集整理的redis 内存不足 排查_一文深入了解 Redis 内存模型，Redis 的快是有原因的！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 美团点评上市最新消息 9月20日正式登陆
- 下一篇： 自己能不能把二类卡升级为一类卡