Redis詳解（2）內存使用與管理

 

一、內存使用情況

---

可以通過info memory命令查看內存使用情況

used_memory: Redis分配的內存總量，即存儲的所有數據佔用的內存。包括redis進程內部開銷和使用的虛擬內存（即swap)，單位byte。

used_memory_human: 以可讀格式返回使用的內存量(只是顯示更友好).

used_memory_rss:從系統角度,顯示Redis進程佔用的物理內存總量，與top及ps命令看到的值是一致的；除了分配器分配的內存之外，used_memory_rss還包括進程運行本身需要的內存、內存碎片等，但是不包括虛擬內存。

used_memory_rss_human:以可讀格式返回Redis進程佔用的物理內存總量

used_memory_peak:內存使用的最大值，表示used_memory峯值

used_memory_peak_human:以可讀格式返回內存使用的最大值

total_system_memory:系統總內存

total_system_memory_human:以可讀格式返回系統總內存

used_memory_lua:Lua進程使用內存

used_memory_lua_human:以可讀格式返回Lua進程使用內存

mem_fragmentation_ratio:內存碎片率，等價於(used_memory_rss /used_memory)

mem_allocator:redis使用的內存分配器:在編譯時指定；可以是 libc 、jemalloc或者tcmalloc，默認是jemalloc；

 

重點關注used_memory以及used_memory_rss和碎片率mem_fragmentation_ratio

1) used_memory和used_memory_rss: 前者是從Redis角度得到的量，後者是從操作系統角度得到的量。二者之所以有所不同，一方面是因爲內存碎片和Redis進程運行需要佔用內存，使得前者可能比後者小，另一方面虛擬內存的存在，使得前者可能比後者大。

2) mem_fragmentation_ratio : 

由於在實際應用中，Redis的數據量會比較大，此時進程運行佔用的內存與Redis數據量和內存碎片相比，都會小得多；因此used_memory_rss和used_memory的比例，便成了衡量Redis內存碎片率的參數；這個參數就是mem_fragmentation_ratio。

mem_fragmentation_ratio =表示(used_memory_rss/used_memory)的比值。

mem_fragmentation_ratio > 1 碎片率過大，導致內存資源浪費；，如果值越大，說明碎片越嚴重。

mem_fragmentation_ratio < 1: 一般出現在操作系統把Redis內存交換到硬盤導致，redis已使用swap分區。由於虛擬內存的媒介是磁盤，比內存速度要慢很多，當這種情況出現時，應該及時排查，如果內存不足應該及時處理，如增加Redis節點、增加Redis服務器的內存、優化應用等。

一般來說，mem_fragmentation_ratio在1.03左右是比較健康的狀態（對於jemalloc來說）；上面截圖中的mem_fragmentation_ratio值很大，是因爲還沒有向Redis中存入數據，Redis進程本身運行的內存使得used_memory_rss 比used_memory大得多。

 

二、內存佔用分析

---

Redis的內存主要包括：對象內存+緩衝內存+自身內存+內存碎片。

1、Redis進程內的內存

其中Redis自身內存消耗的很少，這部分內存大約幾兆。通常佔用used_memory_rss在3MB左右，used_memory在800k左右。

在大多數生產環境中與Redis數據佔用的內存相比可以忽略。這部分內存不是由jemalloc分配，因此不會統計在used_memory中。

補充說明：除了主進程外，Redis創建的子進程運行也會佔用內存，如Redis執行AOF、RDB重寫時創建的子進程。當然，這部分內存不屬於Redis進程，也不會統計在used_memory和used_memory_rss中。

 

2、 數據對象內存佔用

對象內存是Redis中最佔內存的一塊，存儲着用戶所有數據。Redis所有數據都採用key-value，每次你創建key-value,都是創建2個對象，即key對象和value對象，即 key的size + value的size.

Key對象：都是字符串，我們應當避免使用過長的key.

Value對象：根據數據類型不同（五種數據類型–String，List，Hash，Set，Zset），則佔用的內存就不同。這5種類型是Redis對外提供的，實際上，在Redis內部，每種類型可能有2種或更多的內部編碼實現；此外，Redis在存儲對象時，並不是直接將數據扔進內存，而是會對對象進行各種包裝：如redisObject、SDS等；這篇文章後面將重點介紹Redis中數據存儲的細節。

測試表明：string類型需要90字節的額外代價，就是說key 1個字節，value 1個字節時，還是需要佔用92字節的長度，而上面的
使用jemalloc分配內存，刪除數據後，內存並不會乖乖還給操作系統而是被Redis截留下來重用到新的數據上，直到Redis重啓。因此進程實際佔用內存是看INFO裏返回的used_memory_peak_human。
Redis內部用了ziplist/intset這樣的壓縮結構來減少hash/list/set/zset的存儲，默認當集合的元素少於512個且最長那個值不超過64字節時使用，可配置。
用make 32bit可以編譯出32位的版本，每個指針佔用的內存更小，但只支持最大4GB內存。

 

3、緩衝內存：

緩衝內存涉及到客戶端緩衝區，複製積壓緩衝區和AOF緩衝區。這部分內存由jemalloc分配，因此會統計在used_memory中。

客戶端緩衝：指的是所有連接到Redis的服務器tcp連接輸入輸出緩衝，輸入緩衝無法控制，最大空間1G；輸出緩衝可通過client-output-buffer-limit控制。

       1）普通客戶端的連接：client-output-buffer-limit normal 0 0 0

          普通客戶端默認並沒有對輸出緩衝區做限制。但是如果當有大量的慢連接客戶端接入時，這部分消耗就不能忽略了，因爲消費的很慢，在成輸出緩衝區數據積壓。所以可以設置maxclients做限制。

        2）從客戶端：client-output-buffer-limit slave 256mb 64mb 60

        主節點會每一個從節點單獨建立一條連接用於命令複製。當主節點網絡延遲較高或主節點掛載大量的從節點時，這部分內存消耗將佔用很大一部分，建議主節點掛載從節點最好不要超過2個。

        3）  訂閱客戶端：client-output-buffer-limit pubsub 32mb 8mb 60 當生產消息的速度快於消費的速度時，輸出緩衝區容易積壓消息

 

複製積壓緩衝區：一個可重用的固定大小緩衝區用於實現部分複製功能，根據repl-backlog-size參數控制，默認1MB. 對於複製積壓緩區，主節點有一個，所有從節點啊共享這個緩衝區，因此可以設置較大的值，比如100MB,這部分投入是有價值的，可以有效避免全量複製。

 

AOF緩衝區：用於AOF重寫期間保存最近寫入的命令，等待被刷到磁盤。會先寫入到緩衝區，然後根據響應的策略向磁盤進行同步，消耗的內存取決於寫入的命令量和重寫時間，通常很小。

 

4、內存碎片

 

Redis進程需要用內存的話，會先通過OS向device申請，然後才能夠使用。一般進程在不需要使用的時候，會釋放掉這部分內存並返回給device。但是redis可能爲了更高的性能，所以在redis中實現了自己的內存分配器來管理內存，不會馬上返還內存，不用每次都向OS申請了，從而實現高性能。

Redis默認的內存分配器是jemalloc，內存分配器的作用就是爲了更好的管理和重複利用內存。內存碎片是Redis在分配、回收物理內存過程中產生的。

出現高內存碎片問題的情況：當存儲的數據長短差異較大的時候，以下場景容易出現高內存碎片問題

1)、頻繁更新，對已經存在的key進行append setrange操作

2)、大量過期鍵刪除，鍵對象過期刪除後，釋放的 空間無法得到拆分利用

這些操作可能導致redis釋放的空間在物理內存中並沒有釋放，但redis又無法有效利用，這就形成了內存碎片。內存碎片不會統計在used_memory中。
 

解決辦法：

內存碎片的產生與對數據進行的操作、數據的特點等都有關；此外，與使用的內存分配器也有關係：如果內存分配器設計合理，可以儘可能的減少內存碎片的產生。

如果Redis服務器中的內存碎片已經很大，可以通過安全重啓的方式減小內存碎片：

1)、儘量數據對齊，視業務情況而定

2)、安全重啓：重啓可以做到內存碎片重新整理。

      redis4.0以上可以使用新增指令來手動回收內存碎片。

 

5、子進程內存消耗

子進程內存主要是指AOF/RDB重寫時Redis創建的子進程內存消耗。Redis執行fork操作產生子進程內存佔用對外表現爲與父進程相同，理論上需要一倍的相同物理內存來完成重寫操作。但是Linux的copy-on-write機制使得父子進程共享相同的物理內存頁，當父進程處理寫請求時會對需要修改的頁複製出一份副本完成寫操作，而子進程依舊讀取fork時整個父進程內存快照。

# Redis子進程並不需要消耗1倍 的父進程內存，但是依然要預留一些內存防止內存溢出

# 需要設置sysctl vm.overcommit_memory=1允許內核可以分配所有的物理內存，防止Redis進程執行fork時因系統剩餘內存不足而失敗。

# 排查當前系統是否支持並開啓THP，如果開啓，建議關閉。

 

三、內存管理

---

1 、最大內存

Redis通過maxmemory參數限制最大可用內存。限制內存目的主要有：

用於緩存場景，當超出內存上限maxmemory時候使用LRU等刪除策略釋放空間，防止所用內存超過服務器物理內存。

所有的數據都必須在內存中，原來2.0版的VM策略(將Value放到磁盤，Key仍然放在內存)，2.4版後嫌麻煩又不支持了。
一定要設置最大內存，否則物理內存用爆了就會大量使用Swap，寫RDB文件時的速度慢得你想死。我們可以通過配置redis.conf中的maxmemory這個值設置最大內存

# maxmemory <bytes>

若是啓用了Redis快照功能，應該設置“maxmemory”值爲系統可使用內存的45%，因爲快照時需要一倍的內存來複制整個數據集，也就是說如果當前已使用45%，在快照期間會變成95%(45%+45%+5%)，其中5%是預留給其他的開銷。 如果沒開啓快照功能，maxmemory最高能設置爲系統可用內存的95%。

多留一倍內存是最安全的。重寫AOF文件和RDB文件的進程(即使不做持久化，複製到Slave的時候也要寫RDB)會fork出一條新進程來，採用了操作系統的Copy-On-Write策略(子進程與父進程共享Page。如果父進程的Page-每頁4K有修改，父進程自己創建那個Page的副本，不會影響到子進程，父愛如山)。留意Console打出來的報告，如”RDB: 1215 MB of memory used by copy-on-write”。在系統極度繁忙時，如果父進程的所有Page在子進程寫RDB過程中都被修改過了，就需要兩倍內存。
按照Redis啓動時的提醒，設置 vm.overcommit_memory = 1 ，使得fork()一條10G的進程時，因爲COW策略而不一定需要有10G的free memory。

需要注意的是：

maxmeory限制的是Redis實際使用的內存量，也就是used_memory統計項對應的內存。由於有內存碎片的存在，所以實際的內存使用比used_memory要大。需要考慮的內存包括：
1.AOF rewrite過程中對新寫入命令的緩存(rewrite結束後會merge到新的aof文件)，留意”Background AOF buffer size: 80 MB”的字樣。
2.負責與Slave同步的Client的緩存，默認設置master需要爲每個slave預留不高於256M的緩存(見5.1持久化)。

通過設置上限，可以方便實現一臺服務器部署多個Redis進程的內存控制。比如一臺32G的內存的服務器，預留4GB內存給系統，預留4GB給Redis fork進程，留給Redis24GB內存，這樣就可以部署3個maxmemory=8GB的redis進程。

 

2、動態調整內存上限

可以通過命令config set maxmemory8GB

3、 內存回收策略

內存回收機制主要體現在以下兩個方面：

1）刪除過期的key：Redis採用惰性刪除和定時任務刪除機制實現過期key的內存回收

    惰性刪除：

     用於當客戶端讀取帶有超時屬性的key的時候，如果已經超過設置的過期時間，會執行刪除操作並返回空。但是有一個問題，當過期鍵一直沒有訪問將無法得到及時刪除，從而導致內存 不能及時釋放

    定時任務刪除：

Redis內部維護一個定時任務，默認每秒運行10次，通過配置hz屬性控制。

 

 2）內存使用達到maxmeory上限時觸發內存溢出的控制策略：

當Redis所用內存達到maxmeory上限時，會觸發相應的溢出控制策略。即按照配置的Policy進行處理， 默認策略爲volatile-lru，對設置了expire time的key進行LRU清除(不是按實際expire time)。如果沒有數據設置了expire time或者policy爲noeviction，則直接報錯，但此時系統仍支持get之類的讀操作。

具體策略受maxmeory-policy參數控制，Redis支持6種策略：

volatile-lru ：根據LRU算法刪除設置了超時屬性的鍵，直到騰出足夠空間爲止

 allkeys-lru： 根據LRU算法刪除鍵，不管有沒有設置超時屬性，直到騰出足夠空間爲止

volatile-random： 隨即刪除過期鍵，直到騰出足夠空間爲止

allkeys-random ：隨即刪除所有鍵，直到騰出足夠空間爲止

volatile-ttl：根據ttl屬性，刪除最近將要過期的數據，如果沒有回退到noeviction策略

noeviction： 不會刪除任何數據，拒絕所有寫入操作，並返回錯誤信息，此時只是響應讀

 

四、內存淘汰清理機制（回收機制）

---

1、刪除過期的key

官方文檔 與 《Redis設計與實現》中的詳述，過期數據的清除從來不容易，爲每一條key設置一個timer，到點立刻刪除的消耗太大，每秒遍歷所有數據消耗也大，Redis使用了一種相對務實的做法：

刪除過期的key：Redis採用惰性刪除和定時任務刪除機制實現過期key的內存回收

    惰性刪除：

     用於當client讀取帶有超時屬性的key的時候，如果已經超過設置的過期時間，會執行刪除操作並返回空。

     但是有一個問題，當過期鍵一直沒有訪問將無法得到及時刪除，從而導致內存 不能及時釋放。

    定時任務刪除：

    Redis內部維護一個定時任務，默認每秒運行10次，通過配置hz屬性控制。

     每秒10次的執行如下操作： 隨機選取100個key校驗是否過期，如果有25個以上的key過期了，立刻額外隨機選取下100個key(不計算在10次之內)。可見，如果過期的key不多，它最多每秒回收200條左右，如果有超過25%的key過期了，它就會做得更多，但只要key不被主動get，它佔用的內存什麼時候最終被清理掉只有天知道。

 

2、內存使用達到maxmeory上限時觸發內存溢出的控制策略：

redis爲了更好地實現這個功能，必須爲不同的應用場景提供不同的策略，內存淘汰策略講的是爲實現內存淘汰我們具體怎麼做，要解決的問題包括淘汰鍵空間如何選擇？在鍵空間中淘汰鍵如何選擇？

淘汰策略的選擇可以通過下面的配置指定：

# maxmemory-policy noeviction

Redis提供了下面幾種淘汰策略供用戶選擇，其中默認的策略爲noeviction。

策略：

• noeviction：當內存使用達到閾值的時候，所有引起申請內存的命令會報錯。

• allkeys-lru：在主鍵空間中，優先移除最近未使用的key。

• volatile-lru：在設置了過期時間的鍵空間中，優先移除最近未使用的key。

• allkeys-random：在主鍵空間中，隨機移除某個key。

• volatile-random：在設置了過期時間的鍵空間中，隨機移除某個key。

• volatile-ttl：在設置了過期時間的鍵空間中，具有更早過期時間的key優先移除。

下面看看幾種策略的適用場景：

• allkeys-lru：如果我們的應用對緩存的訪問符合冪律分佈（也就是存在相對熱點數據），或者我們不太清楚我們應用的緩存訪問分佈狀況，我們可以選擇allkeys-lru策略。

• allkeys-random：如果我們的應用對於緩存key的訪問概率相等，則可以使用這個策略。

• volatile-ttl：這種策略使得我們可以向Redis提示哪些key更適合被eviction。

另外，volatile-lru策略和volatile-random策略適合我們將一個Redis實例既應用於緩存和又應用於持久化存儲的時候，然而我們也可以通過使用兩個Redis實例來達到相同的效果，值得一提的是將key設置過期時間實際上會消耗更多的內存，因此我們建議使用allkeys-lru策略從而更有效率的使用內存。

 

提示：主鍵空間和設置了過期時間的鍵空間，舉個例子，假設我們有一批鍵存儲在Redis中，則有那麼一個哈希表用於存儲這批鍵及其值，如果這批鍵中有一部分設置了過期時間，那麼這批鍵還會被存儲到另外一個哈希表中，這個哈希表中的值對應的是鍵被設置的過期時間。設置了過期時間的鍵空間爲主鍵空間的子集。

 

3、非精準的LRU

上面提到的LRU（Least Recently Used）策略，實際上Redis實現的LRU並不是可靠的LRU，也就是名義上我們使用LRU算法淘汰鍵，但是實際上被淘汰的鍵並不一定是真正的最久沒用的，這裏涉及到一個權衡的問題，如果需要在全部鍵空間內搜索最優解，則必然會增加系統的開銷，Redis是單線程的，也就是同一個實例在每一個時刻只能服務於一個客戶端，所以耗時的操作一定要謹慎。爲了在一定成本內實現相對的LRU，早期的Redis版本是基於採樣的LRU，也就是放棄全部鍵空間內搜索解改爲採樣空間搜索最優解。自從Redis3.0版本之後，Redis作者對於基於採樣的LRU進行了一些優化，目的是在一定的成本內讓結果更靠近真實的LRU。

 

五、數據存儲的細節

---

5.1、概述

關於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、對象類型及內部編碼。

5.2、jemalloc

Redis在編譯時便會指定內存分配器；內存分配器可以是 libc 、jemalloc或者tcmalloc，默認是jemalloc。

jemalloc作爲Redis的默認內存分配器，在減小內存碎片方面做的相對比較好。jemalloc在64位系統中，將內存空間劃分爲小、大、巨大三個範圍；每個範圍內又劃分了許多小的內存塊單位；當Redis存儲數據時，會選擇大小最合適的內存塊進行存儲。

jemalloc劃分的內存單元如下圖所示：

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

5.3、redisObject

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

redisObject對象非常重要，Redis對象的類型、內部編碼、內存回收、共享對象等功能，都需要redisObject支持，下面將通過redisObject的結構來說明它是如何起作用的。

redisObject的定義如下（不同版本的Redis可能稍稍有所不同）：

redisObject的每個字段的含義和作用如下：

5.3.1、type

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

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

5.3.2、encoding

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

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

通過object encoding命令，可以查看對象採用的編碼方式，如下圖所示：

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

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

5.3.4、refcount

（3.4.1）refcount與共享對象

refcount記錄的是該對象被引用的次數，類型爲整型。refcount的作用，主要在於對象的引用計數和內存回收。當創建新對象時，refcount初始化爲1；當有新程序使用該對象時，refcount加1；當對象不再被一個新程序使用時，refcount減1；當refcount變爲0時，對象佔用的內存會被釋放。

Redis中被多次使用的對象(refcount>1)，稱爲共享對象。Redis爲了節省內存，當有一些對象重複出現時，新的程序不會創建新的對象，而是仍然使用原來的對象。這個被重複使用的對象，就是共享對象。目前共享對象僅支持整數值的字符串對象。

（3.4.2）共享對象的具體實現

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.3.5、ptr

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

5.3.6、總結

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

4bit+4bit+24bit+4Byte+8Byte=www.leyou1178.cn  16Byte。

 

5.4、SDS

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

舉個例子：執行一個list的命令，lpush queue "redis" "list" "queue"，首先會創建queue鍵字符串，然後創建鏈表對象，鏈表對象內在包含三個字符串對象。

5.4.1、SDS結構

sds的結構如下：

其中

buf：表示字節數組，用來存儲字符串；

len：表示buf已使用的長度，

free:表示buf未使用的長度。下面是兩個例子。

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

 

SDS有幾個特點：

時間複雜度爲O(1)，因爲有已知長度，未知長度，字符串長度
支持安全的二進制數據存儲，用於保存字節數組
內部實現空間預分配機制，降低內存再分配次數
惰性刪除機制，字符串縮減後的空間不釋放，作爲與分配空間保留

    所以字符串在使用的時候，儘量減少追加操作，避免大量的追加操作需要內存重新分配，造成內存碎片率上升。而是儘量使用直接插入。
    字符串預分配每次都不是翻倍擴容，空間的預分配規則如下：

    第一次創建len屬性等於數據實際大小，free等於0，不做預分配。
    修改後，如果已有free空間不夠且數據小於1MB，每次與分配一倍容量。
    修改後如果已有free空間不夠且數據大於1MB，每次預分配1MB數據空間。如果數據量太大，也翻一倍的話，很有可能會造成內存不足，所有大於1MB的數據，每次預分配1MB空間，也是基於此原因。

一個簡單的例子，比如在Redis中set一個簡單點的值，在Redis內存中的結構圖如下（參考樣例）：

5.4.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’不一定是結尾）。

5.4.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支持5種對象類型（String，List，Hash，Set，Zset），而每種結構都有至少兩種編碼；這樣做的好處在於：一方面接口與實現分離，當需要增加或改變內部編碼時，用戶使用不受影響，另一方面可以根據不同的應用場景切換內部編碼，提高效率。

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

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

但是不同的類型，在存儲到Redis中時會有不同的底層數據結構實現。類似集合ArrayList的底層實現是數組，而Linkedlist的底層實現是鏈表結構一樣，編碼不同，則存儲是佔用的內存以及讀寫的效率也是不同的。

 

embstr與raw的區別
    在講兩種編碼格式的區別之前，先講點其他的，現代的計算機的結構上邊在CPU和內存之間存在一個緩存結構，用來協調CPU的高效和訪存的相對緩慢的矛盾。平時聽到的L1 Cache，L2 Cache，L3 Cache就是這個緩存。當CPU要訪問內存之前會先在緩存裏面找一找看有沒有，如果沒有，就去內存找，找到之後放到緩存裏面。這個緩存的最小單位一般是64字節，一次性緩存連續的64個字節，這個最小的單位稱爲緩存行。

  
    在Redis中，每個value對象都有一個redisObject對象頭，對於Redis的字符串對象，當讀取數據時，拿到*ptr指針，然後再去找到指向的SDS對象，如果這個對象距離很遠，就會影響Redis讀取的效率。因此在Redis中設計了一種特殊的編碼結構，這種結構就是embstr，它把redisObject請求頭和SDS對象緊緊地捱到一起，然後整體放到一個緩存行中去，這樣，在查詢的時候就可以直接從緩存中獲取到相關的數據，提高了查詢的效率。

    在上邊也講了，緩存行一般的長度爲64字節，如果想要把對象存到緩存行中，首先整體的長度不得超過64字節，每個請求頭redisObject佔用16字節，而SDS至少有3個自己被佔用，同時Redis中會以\0來作爲結尾的標誌，也佔用一個字節，因此，留給可輸入的數據的長度就成了（64-16-3-1）=44字節，當存儲的數據長度超過了44字節，就會變成raw的編碼形式。
 

6.1、字符串

字符串是最基礎的類型，因爲所有的鍵都是字符串類型，且字符串之外的其他幾種複雜類型的元素也是字符串。

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

6.1.1、內部編碼

字符串類型的內部編碼有3種，它們的應用場景如下：

• int：8個字節的長整型。字符串值是整型時，這個值使用long整型表示。

• embstr：www.006665.cn  <=39字節的字符串。embstr與raw都使用www.baohuayule.com   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字節的內存單元。

6.1.2、編碼轉換

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

而對於embstr，由於其實現是隻讀的，www.leyouzaixan.cn 因此在對embstr對象進行修改時，都會先轉化爲raw再進行修改，因此，只要是修改embstr對象，修改後的對象一定是raw的，無論是否達到了39個字節。示例如下圖所示：

6.2、列表LIST

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

6.2.1 內部編碼

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

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

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

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

壓縮列表不僅用於實現列表，也用於實現哈希、有序列表；使用非常廣泛。

6.2.2 編碼轉換

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

下圖展示了列表編碼轉換的特點：

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

6.3、哈希

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

6.3.1 內部編碼

內層的哈希使用的內部編碼可以是壓縮列表（www.255055.cn ziplist）和哈希表（hashtable）兩種；Redis的外層的哈希則只使用了hashtable。

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

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

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

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

dictEntry

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

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

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

• size屬性記錄了哈希表的大小，即www.wanmeiyuele.cn  bucket的大小；

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

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

dict

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

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。

6.3.3）編碼轉換

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

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

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

6.4、集合

集合（set）與列表類似，都是用來保存多個字符串，但集合與列表有兩點不同：集合中的元素是無序的，因此不能通過索引來操作元素；集合中的元素不能有重複。

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

6.4.1內部編碼

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

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

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

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

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

6.4.2 編碼轉換

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

下圖展示了集合編碼轉換的特點：

6.5、有序集合

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

6.5.1內部編碼

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

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

6.5.2 編碼轉換

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

下圖展示了有序集合編碼轉換的特點：

 

 

七、內存優化

---

Redis內部有很多的數據類型，這些在官方文檔上都可以看到，下面是其內部優化的一些細節點：

1、縮減鍵值對象

降低Redis內存使用最直接的方式就是縮減key和value的長度

# key的設計：越短越好，如user:{userid}:friends:notify:{fid}，可以簡化爲u:{uid}:fs:nt:{fid}

# value： 值對象縮減比較複雜，常見的需求是把業務對象序列化放入Redis。

2. String 和 數字:

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

在Redis中如果存儲的是“123”Redis是能夠識別出來這是一個數字並且按照數字來存儲，節省存儲空間，當然除了這個優化之外，Redis內部會構建一個數字池，默認是10000，那麼如果是在這個池子的數字就只需要用一個簡單的索引來引用進來就可以，而不需要把重複的數字都分開存儲。這個數值可以調整源代碼的宏：REDIS_SHARED_INTEGERS來擴大和縮小池子的大小。

3.複雜類型的存儲優化:

比如Map，List，Set等，這些集合都有一個特點可大可小，根據實際場景來定，一般情況下如果這些集合所包含的Entry不多，並且每個Entry所包含的Value不是很長的情況下，Redis內部使用緊湊格式來存儲數據，緊湊格式存儲數據在查詢場景的算法複雜度是O(N)，而類似Map或者Set他們的查詢算法複雜度都是O(1)那爲什麼要這麼做呢 ？爲了能夠節省內存空間，在N很小的時候其實和O(1)沒什麼區別。所以這裏不的不介紹緊湊格式的代表ZIPMap，他的數據結構是這樣：

可以看出，這個結構中初始情況只有2個字節，隨着操作的增加它會變長，其中最關鍵的是一個關於Free這個字段的理解，以Map爲例，如果新插入一個Key，那麼對應ZipMap就會多出來一長串數據:<len><key><len><free><value>。從圖中可以看到插入key1的時候只有綠色的一串，當key2插入的時候就會又出來一個類似的黃色結構串。free的功能是在插入的時候用來冗餘空間的，當key所對應的數值發生變化的時候，如果數據變的比之前短了，那麼free的長度就變大，這個時候不需要做ZipMap的resize操作，如果數據長度變長了，並且在free能夠足以支持新數據的範圍之內，那麼free就被利用起來，並且也不需要做Resize。這個時候會有空間的浪費或者說碎片。空間換時間吧，沒什麼好說的。當然Redis的代碼中還有另外一個參數ZIPMAP_VALUE_MAX_FREE，這個參數可以用來設置如果Free的大小超過了這個值，那麼ZipMap會發生Resize（收縮），從而節約空間。

 

內存優化總結：

1、首先最重要的一點是不要開啓Redis的VM選項，即虛擬內存功能，這個本來是作爲Redis存儲超出物理內存數據的一種數據在內存與磁盤換入換出的一個持久化策略，但是其內存管理成本也非常的高，並且我們後續會分析此種持久化策略並不成熟，所以要關閉VM功能，請檢查你的redis.conf文件中 vm-enabled 爲 no。

2、其次最好設置下redis.conf中的maxmemory選項，該選項是告訴Redis當使用了多少物理內存後就開始拒絕後續的寫入請求，該參數能很好的保護好你的Redis不會因爲使用了過多的物理內存而導致swap,最終嚴重影響性能甚至崩潰。