幾個常用命令行

• 登錄?redis-cli-h127.0.0.1-p6379-a123

• 查看內存?info memory

這里面 info 是命令 memory 是參數 單單輸入 info 就死查看所有的信息，如果只需要查看內存情況，只需要加上內存這個參數

127.0.0.1:6379> info memory # Memory used_memory:1031440 used_memory_human:1007.27K used_memory_rss:897024 used_memory_rss_human:876.00K used_memory_peak:1031440 used_memory_peak_human:1007.27K used_memory_peak_perc:100.01% used_memory_overhead:1030414 used_memory_startup:980784 used_memory_dataset:1026 used_memory_dataset_perc:2.03% total_system_memory:8589934592 total_system_memory_human:8.00G used_memory_lua:37888 used_memory_lua_human:37.00K maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction mem_fragmentation_ratio:0.87 mem_allocator:libc active_defrag_running:0 lazyfree_pending_objects:0

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

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

（2）usedmemoryrss：Redis進程占據操作系統的內存（單位是字節），與top及ps命令看到的值是一致的；除了分配器分配的內存之外，usedmemoryrss還包括進程運行本身需要的內存、內存碎片等，但是不包括虛擬內存。 因此，usedmemory和usedmemoryrss，前者是從Redis角度得到的量，后者是從操作系統角度得到的量。二者之所以有所不同，一方面是因為內存碎片和Redis進程運行需要占用內存，使得前者可能比后者小，另一方面虛擬內存的存在，使得前者可能比后者大。 由于在實際應用中，Redis的數據量會比較大，此時進程運行占用的內存與Redis數據量和內存碎片相比，都會小得多；因此usedmemoryrss和usedmemory的比例，便成了衡量Redis內存碎片率的參數；這個參數就是memfragmentationratio。

（3）memfragmentationratio：內存碎片比率，該值是usedmemoryrss / usedmemory的比值。 memfragmentationratio一般大于1，且該值越大，內存碎片比例越大。memfragmentationratio<1，說明Redis使用了虛擬內存，由于虛擬內存的媒介是磁盤，比內存速度要慢很多，當這種情況出現時，應該及時排查，如果內存不足應該及時處理，如增加Redis節點、增加Redis服務器的內存、優化應用等。 一般來說，memfragmentationratio在1.03左右是比較健康的狀態（對于jemalloc來說）；上面截圖中的memfragmentationratio值很大，是因為還沒有向Redis中存入數據，Redis進程本身運行的內存使得usedmemoryrss 比usedmemory大得多。

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

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進程，也不會統計在usedmemory和usedmemory_rss中。

緩沖內存

緩沖內存包括客戶端緩沖區、復制積壓緩沖區、AOF緩沖區等；其中，客戶端緩沖存儲客戶端連接的輸入輸出緩沖；復制積壓緩沖用于部分復制功能；AOF緩沖區用于在進行AOF重寫時，保存最近的寫入命令。在了解相應功能之前，不需要知道這些緩沖的細節；這部分內存由jemalloc分配，因此會統計在used_memory中。

內存碎片

內存碎片是Redis在分配、回收物理內存過程中產生的。例如，如果對數據的更改頻繁，而且數據之間的大小相差很大，可能導致redis釋放的空間在物理內存中并沒有釋放，但redis又無法有效利用，這就形成了內存碎片。內存碎片不會統計在used_memory中。

內存碎片的產生與對數據進行的操作、數據的特點等都有關；此外，與使用的內存分配器也有關系：如果內存分配器設計合理，可以盡可能的減少內存碎片的產生。后面將要說到的jemalloc便在控制內存碎片方面做的很好。

如果Redis服務器中的內存碎片已經很大，可以通過安全重啟的方式減小內存碎片：因為重啟之后，Redis重新從備份文件中讀取數據，在內存中進行重排，為每個數據重新選擇合適的內存單元，減小內存碎片。

Redis數據存儲的細節

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

下圖是執行set hello world時，所涉及到的數據模型。（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劃分的內存單元如下圖所示：例如，如果需要存儲大小為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;

（1）type type字段表示對象的類型，占4個比特；目前包括REDISSTRING(字符串)、REDISLIST (列表)、REDISHASH(哈希)、REDISSET(集合)、REDIS_ZSET(有序集合)。

當我們執行type命令時，便是通過讀取RedisObject的type字段獲得對象的類型；如下圖所示：

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

對于Redis支持的每種類型，都有至少兩種內部編碼，例如對于字符串，有int、embstr、raw三種編碼。通過encoding屬性，Redis可以根據不同的使用場景來為對象設置不同的編碼，大大提高了Redis的靈活性和效率。以列表對象為例，有壓縮列表和雙端鏈表兩種編碼方式；如果列表中的元素較少，Redis傾向于使用壓縮列表進行存儲，因為壓縮列表占用內存更少，而且比雙端鏈表可以更快載入；當列表對象元素較多時，壓縮列表就會轉化為更適合存儲大量元素的雙端鏈表。

通過object encoding命令，可以查看對象采用的編碼方式，如下圖所示：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這個數字可以通過調整參數REDISSHAREDINTEGERS（4.0中是OBJSHAREDINTEGERS）的值進行改變。

共享對象的引用次數可以通過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未使用的長度。下面是兩個例子。通過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內存使用量

要估算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個鍵值對占據的內存大小為：9000080 + 1310728 = 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個鍵值對占據內存大小為：90000112 + 1310728 = 11128576。 在redis中驗證代碼如下（只修改插入數據的代碼）：

public static void insertData(){for(int i = 10000; i < 100000; i++){jedis.set("aaa" + i, "aaa" + i); //key和value長度都是8字節，且不是整數}}

對于字符串類型之外的其他類型，對內存占用的估算方法是類似的，需要結合具體類型的編碼方式來確定。

優化內存占用

了解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）；可以通過調整REDISSHAREDINTEGERS參數提高共享對象的個數；例如將REDISSHAREDINTEGERS調整到20000，則0-19999之間的對象都可以共享。

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

（4）避免過度設計

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

如果數據量較小，那么為了節省內存而使得代碼的開發、維護變得更加困難并不劃算；還是以前面講到的90000個鍵值對為例，實際上節省的內存空間只有幾MB。但是如果數據量有幾千萬甚至上億，考慮內存的優化就比較必要了。

關注內存碎片率

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

如果內存碎片率過高（jemalloc在1.03左右比較正常），說明內存碎片多，內存浪費嚴重；這時便可以考慮重啟redis服務，在內存中對數據進行重排，減少內存碎片。

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

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

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Redis常用操作和内存模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。