Redis 記憶體優化神技，小記憶體儲存大資料

大家好，我是「碼哥」，大家可以叫我靚仔。

這次碼哥跟大家分享一些優化神技，當你面試或者工作中你遇到如下問題，那就使出今天學到的絕招，一招定乾坤！

如何用更少的記憶體儲存更多的資料？

我們應該從 Redis 是如何儲存資料的原理展開，分析鍵值對的儲存結構和原理。

從而繼續延展出每種資料型別底層的資料結構，針對不同場景使用更恰當的資料結構和編碼實現更少的記憶體佔用。

為了儲存資料， Redis 需要先申請記憶體，資料過期或者記憶體淘汰需要回收記憶體，從而擴充出記憶體碎片優化。

最後，說下 key、value 使用規範和技巧、 Bitmap 等高階資料型別，運用這些技巧巧妙解決有限記憶體去儲存更多資料難題……

這一套組合拳下來直接封神。

具體詳情，且看「碼哥」一一道來。

主要優化神技如下：

• 鍵值對優化；
• 小資料集合的編碼優化；
• 使用物件共享池；
• 使用 Bit 位元位或 byte 級別操作
• 使用 hash 型別優化；
• 記憶體碎片優化；
• 使用 32 位的 Redis。

在優化之前，我們先掌握 Redis 是如何儲存資料的。

Redis 如何儲存鍵值對

Redis 以 redisDb為中心儲存，redis 7.0 原始碼在 https://github.com/redis/redis/blob/7.0/src/server.h：

• dict：最重要的屬性之一，就是靠這個定義了儲存了物件資料鍵值對，dcit 的底層結構是一個雜湊表。
• expires：儲存著所有 key 的過期資訊.
• blocking_keys 和 ready_keys 主要為了實現 BLPOP 等阻塞命令
• watched_keys用於實現watch命令，記錄正在被watch的一些key，與事務相關。
• id 為當前資料庫的id，redis 支援單個服務多資料庫，預設有16個；
• clusterSlotToKeyMapping：cluster 模式下，儲存key 與雜湊槽對映關係的陣列。

Redis 使用「dict」結構來儲存所有的鍵值對（key-value）資料，這是一個全域性雜湊表，所以對 key 的查詢能以 O(1) 時間得到。

所謂雜湊表，我們可以類比 Java 中的 HashMap，其實就是一個陣列，陣列的每個元素叫做雜湊桶。

dict 結構如下，原始碼在 https://github.com/redis/redis/blob/7.0/src/dict.h：

struct dict {
    // 特定型別的處理函式
    dictType *type;
		// 兩個全域性雜湊表指標陣列，與漸進式 rehash 有關
    dictEntry **ht_table[2];
    // 記錄 dict 中現有的資料個數。
    unsigned long ht_used[2];
	  // 記錄漸進式 rehash 進度的標誌， -1 表示當前沒有執行 rehash 
    long rehashidx;

   // 小於 0 表示 rehash 暫停
    int16_t pauserehash;
    signed char ht_size_exp[2];
};

• dictType：儲存了hash函式，key和value的複製等函式；
• ht_table：長度為 2 的 陣列，正常情況使用 ht_table[0] 儲存資料，當執行 rehash 的時候，使用 ht_table[1] 配合完成 。

key 的雜湊值最終會對映到 ht_table 的一個位置，如果發生雜湊衝突，則拉出一個雜湊連結串列。

大家重點關注 dictEntry 的 ht_table，ht_table 陣列每個位置我們也叫做雜湊桶，就是這玩意儲存了所有鍵值對。

碼哥，Redis 支援那麼多的資料型別，雜湊桶咋儲存？

雜湊桶的每個元素的結構由 dictEntry 定義：

typedef struct dictEntry {
   // 指向 key 的指標
    void *key;
    union {
        // 指向實際 value 的指標
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    // 雜湊衝突拉出的連結串列
    struct dictEntry *next;
} dictEntry;

• key 指向鍵值對的鍵的指標，key 都是 string 型別。
• value 是個 union（聯合體）當它的值是 uint64_t、int64_t 或 double 型別時，就不再需要額外的儲存，這有利於減少記憶體碎片。（為了節省記憶體操碎了心）當然，val 也可以是 void 指標，指向值的指標，以便能儲存任何型別的資料。
• next 指向另一個 dictEntry 結構， 多個 dictEntry 可以通過 next 指標串連成連結串列， 從這裡可以看出， ht_table 使用鏈地址法來處理鍵碰撞： 當多個不同的鍵擁有相同的雜湊值時，雜湊表用一個連結串列將這些鍵連線起來。

雜湊桶並沒有儲存值本身，而是指向具體值的指標，從而實現了雜湊桶能存不同資料型別的需求。

而雜湊桶中，鍵值對的值都是由一個叫做 redisObject 的物件定義，原始碼地址：https://github.com/redis/redis/blob/7.0/src/server.h。

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS;
    int refcount;
    void *ptr;
} robj;

• type： 記錄了物件的型別，string、set、hash 、Lis、Sorted Set 等，根據該型別才可以確定是哪種資料型別，使用什麼樣的 API 操作。
• encoding：編碼方式，表示 ptr 指向的資料型別具體資料結構，即這個物件使用了什麼資料結構作為底層實現儲存資料。同一個物件使用不同編碼實現記憶體佔用存在明顯差異，內部編碼對記憶體優化非常重要。
• lru:LRU_BITS：LRU 策略下物件最後一次被訪問的時間，如果是 LFU 策略，那麼低 8 位表示訪問頻率，高 16 位表示訪問時間。
• refcount ：表示引用計數，由於 C 語言並不具備記憶體回收功能，所以 Redis 在自己的物件系統中新增了這個屬性，當一個物件的引用計數為 0 時，則表示該物件已經不被任何物件引用，則可以進行垃圾回收了。
• ptr 指標：指向物件的底層實現資料結構，指向值的指標。

如下圖是由 redisDb、dict、dictEntry、redisObejct 關係圖：

「碼哥」再嘮叨幾句，void *key 和 void *value 指標指向的是 redis物件，因為 Redis 中每個物件都是用 redisObject 表示。

知道了 Redis 儲存原理以及不同資料型別的儲存資料結構後，我們繼續看如何做效能優化。

1. 鍵值對優化

當我們執行 set key value 的命令，*key指標指向 SDS 字串儲存 key，而 value 的值儲存在 *ptr 指標指向的資料結構，消耗的記憶體：key + value。

第一個優化神技：降低 Redis 記憶體使用的最粗暴的方式就是縮減鍵（key）與值（value）的長度。

在《Redis 很強，不懂使用規範就糟蹋了》中我說過關於鍵值對的使用規範，對於 key 的命名使用「業務模組名:表名:資料唯一id」這樣的方式方便定位問題。

比如：users:firends:996 表示使用者系統中，id = 996 的朋友資訊。我們可以簡寫為：u:fs:996

對於 key 的優化：使用單詞簡寫方式優化記憶體佔用。

對於 value 的優化那就更多了：

• 過濾不必要的資料：不要大而全的一股腦將所有資訊儲存，想辦法去掉一些不必要的屬性，比如快取登入使用者的資訊，通常只需要儲存暱稱、性別、賬號等。

• 精簡資料：比如使用者的會員型別：0 表示「屌絲」、1 表示 「VIP」、2表示「VVIP」。而不是儲存 VIP 這個字串。

• 資料壓縮：對資料的內容進行壓縮，比如使用 GZIP、Snappy。

• 使用效能好，記憶體佔用小的序列化方式。比如 Java 內建的序列化不管是速度還是壓縮比都不行，我們可以選擇 protostuff，kryo等方式。如下圖 Java 常見的序列化工具空間壓縮比：

  

  靚仔們，我們通常使用 json 作為字串儲存在 Redis，用 json 儲存與二進位制資料儲存有什麼優缺點呢？

  json 格式的優點：方便除錯和跨語言；缺點是：同樣的資料相比位元組陣列佔用的空間更大。

  一定要 json 格式的話，那就先通過壓縮演算法壓縮 json，再把壓縮後的資料存入 Redis。比如 GZIP 壓縮後的 json 可降低約 60% 的空間。

2. 小資料集合編碼優化

key 物件都是 string 型別，value 物件主要有五種基本資料型別：String、List、Set、Zset、Hash。

資料型別與底層資料結構的關係如下所示：


特別說明下在最新版（非穩定版本，時間 2022-7-3），ziplist 壓縮列表由 quicklist 代替（3.2 版本引入），而雙向連結串列由 listpack 代替。

另外，同一資料型別會根據鍵的數量和值的大小也有不同的底層編碼型別實現。

在 Redis 2.2 版本之後，儲存集合資料（Hash、List、Set、SortedSet）在滿足某些情況下會採用記憶體壓縮技術來實現使用更少的記憶體儲存更多的資料。

當這些集合中的資料元素數量小於某個值且元素的值佔用的位元組大小小於某個值的時候，儲存的資料會用非常節省記憶體的方式進行編碼，理論上至少節省 10 倍以上記憶體（平均節省 5 倍以上）。

比如 Hash 型別裡面的資料不是很多，雖然雜湊表的時間複雜度是 O(1)，ziplist 的時間複雜度是 O(n)，但是使用 ziplist 儲存資料的話會節省了記憶體，並且在少量資料情況下效率並不會降低很多。

所以我們需要儘可能地控制集合元素數量和每個元素的記憶體大小，這樣能充分利用緊湊型編碼減少記憶體佔用。

並且，這些編碼對使用者和 api 是無感知的，當集合資料超過配置檔案的配置的最大值， Redis 會自動轉成正常編碼。

資料型別對應的編碼規則如下所示

String 字串

• int：整數且數字長度小於 20，直接儲存在 *ptr 中。
• embstr：開闢一塊連續分配的記憶體（字串長度小於等於 44 位元組）。
• raw：動態字串（大於 44 位元組的字串，同時字串小於 512 MB）。

List 列表

• ziplist：元素個數小於hash-max-ziplist-entries配置，同時所所的元素的值大小都小於 hash-max-ziplist-value配置。

  

• linkedlist：3.0 版本之前當列表型別無法滿足 ziplist 的條件時，Redis會使用 linkedlist 作為列表的內部實現。

• quicklist：Redis 3.2 引入，並作為 List 資料型別的底層實現，不再使用雙端連結串列 linkedlist 和 ziplist 實現。

Set 集合

• intset 整數集合：元素都是整數，且元素個數小於 set-max-intset-entries配置
• hashtable 雜湊表：集合型別無法滿足intset的條件時就會使用hashtable 編碼。

Hash 雜湊表

• ziplist：元素個數小於 hash-max-ziplist-entries配置，同時任意一個 value 的佔用位元組大小都小於hash-max-ziplist-value 。
• hashtable：hash 型別無法滿足 intset 的條件時就會使用hashtable。

Sorted Set 有序集合

• ziplist：元素個數小於 zset-max-ziplist-entries 同時每個元素的value小於``zset-max-ziplist-value`配置。
• skiplist：當ziplist條件不滿足時，有序集合會使用skiplist作為內部實現。

以下是 Redis redis.conf 配置檔案預設編碼閾值配置：

hash-max-ziplist-entries 512
hash-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
set-max-intset-entries 512

下圖是 reidsObject 物件的 type 和 encoding 對應關係圖：

碼哥，為啥對一種資料型別實現多種不同編碼方式？

主要原因是想通過不同編碼實現效率和空間的平衡。

比如當我們的儲存只有100個元素的列表，當使用雙向連結串列資料結構時，需要維護大量的內部欄位。

比如每個元素需要：前置指標，後置指標，資料指標等，造成空間浪費。

如果採用連續記憶體結構的壓縮列表(ziplist)，將會節省大量記憶體，而由於資料長度較小，存取操作時間複雜度即使為O(n) 效能也相差不大，因為 n 值小 與 O(1) 並明顯差別。

資料編碼優化技巧

ziplist 儲存 list 時每個元素會作為一個 entry，儲存 hash 時 key 和 value 會作為相鄰的兩個 entry。

儲存 zset 時 member 和 score 會作為相鄰的兩個entry，當不滿足上述條件時，ziplist 會升級為 linkedlist, hashtable 或 skiplist 編碼。

由於目前大部分Redis執行的版本都是在3.2以上，所以 List 型別的編碼都是quicklist。

quicklist 是 ziplist 和 linkedlist 的混合體，它將 linkedlist 按段切分，每一段使用 ziplist 來緊湊儲存，多個 ziplist 之間使用雙向指標串接起來。

考慮了綜合平衡空間碎片和讀寫效能兩個維度所以使用了個新編碼 quicklist。

ziplist 的不足

每次修改都可能觸發 realloc 和 memcopy, 可能導致連鎖更新(資料可能需要挪動)。

因此修改操作的效率較低，在 ziplist 的元素很多時這個問題更加突出。

優化手段：

1. key 儘量控制在 44 位元組以內，走 embstr 編碼。
2. 集合型別的 value 物件的元素個數不要太多太大，充分利用 ziplist 編碼實現記憶體壓縮。

3. 物件共享池

整數我們經常在工作中使用，Redis 在啟動的時候預設後生成一個 0 ~9999 的整數物件共享池用於物件複用，減少記憶體佔用。

比如執行set 碼哥 18; set 吳彥祖 18; key 等於 「碼哥」 和「吳彥祖」的 value 都指向同一個物件。

如果 value 可以使用整數表示的話儘可能使用整數，這樣即使大量鍵值對的 value 大量儲存了 0~9999 範圍內的整數，在例項中，其實只有一份資料。

靚仔們，有兩個大坑遇到注意，它會導致物件共享池失效。

• Redis 中設定了 maxmemory 限制最大記憶體佔用大小且啟用了 LRU 策略（allkeys-lru 或 volatile-lru 策略）。

  碼哥，為啥呀？

  因為 LRU 需要記錄每個鍵值對的訪問時間，都共享一個整數 物件，LRU 策略就無法進行統計了。

• 集合型別的編碼採用 ziplist 編碼，並且集合內容是整數，也不能共享一個整數物件。

  這又是為啥呢？

  使用了 ziplist 緊湊型記憶體結構儲存資料，判斷整數物件是否共享的效率很低。

4.使用 Bit 位元位或 byte 級別操作

比如在一些「二值狀態統計」的場景下使用 Bitmap 實現，對於網頁 UV 使用 HyperLogLog 來實現，大大減少記憶體佔用。

碼哥，什麼是二值狀態統計呀？

也就是集合中的元素的值只有 0 和 1 兩種，在簽到打卡和使用者是否登陸的場景中，只需記錄簽到(1)或 未簽到(0)，已登入(1)或未登陸(0)。

假如我們在判斷使用者是否登陸的場景中使用 Redis 的 String 型別實現（key -> userId，value -> 0 表示下線，1 - 登陸），假如儲存 100 萬個使用者的登陸狀態，如果以字串的形式儲存，就需要儲存 100 萬個字串，記憶體開銷太大。

String 型別除了記錄實際資料以外，還需要額外的記憶體記錄資料長度、空間使用等資訊。

Bitmap 的底層資料結構用的是 String 型別的 SDS 資料結構來儲存位陣列，Redis 把每個位元組陣列的 8 個 bit 位利用起來，每個 bit 位 表示一個元素的二值狀態（不是 0 就是 1）。

可以將 Bitmap 看成是一個 bit 為單位的陣列，陣列的每個單元只能儲存 0 或者 1，陣列的下標在 Bitmap 中叫做 offset 偏移量。

為了直觀展示，我們可以理解成 buf 陣列的每個位元組用一行表示，每一行有 8 個 bit 位，8 個格子分別表示這個位元組中的 8 個 bit 位，如下圖所示：

8 個 bit 組成一個 Byte，所以 Bitmap 會極大地節省儲存空間。 這就是 Bitmap 的優勢。

關於 Bitmap 的詳細解答，大家可移步 -> 《Redis 實戰篇：巧用 Bitmap 實現億級資料統計》。

5. 妙用 Hash 型別優化

儘可能把資料抽象到一個雜湊表裡。

比如說系統中有一個使用者物件，我們不需要為一個使用者的暱稱、姓名、郵箱、地址等單獨設定一個 key，而是將這個資訊存放在一個雜湊表裡。

如下所示：

hset users:深圳:999 姓名 碼哥
hset users:深圳:999 年齡 18
hset users:深圳:999 愛好 女

為啥使用 String 型別，為每個屬性設定一個 key 會佔用大量記憶體呢？

因為 Redis 的資料型別有很多，不同資料型別都有些相同的後設資料要記錄（比如最後一次訪問的時間、被引用的次數等）。

所以，Redis 會用一個 RedisObject 結構體來統一記錄這些後設資料，用 *prt 指標指向實際資料。

當我們為每個屬性都建立 key，就會建立大量的 redisObejct 物件佔用記憶體。

如下所示 redisObject 記憶體佔用：

用 Hash 型別的話，每個使用者只需要設定一個 key。

6. 記憶體碎片優化

Redis 釋放的記憶體空間可能並不是連續的，這些不連續的記憶體空間很有可能處於一種閒置的狀態。

雖然有空閒空間，Redis 卻無法用來儲存資料，不僅會減少 Redis 能夠實際儲存的資料量，還會降低 Redis 執行機器的成本回報率。

比如， Redis 儲存一個整形數字集合需要一塊佔用 32 位元組的連續記憶體空間，當前雖然有 64 位元組的空閒，但是他們都是不連續的，導致無法儲存。

記憶體碎片是如何形成呢？

兩個層面原因導致：

• 作業系統記憶體分配機制：記憶體分配策略決定了無法做到按需分配。因為分配器是按照固定大小來分配記憶體。
• 鍵值對被修改和刪除，從而導致記憶體空間的擴容和釋放。

碎片優化可以降低記憶體使用率，提高訪問效率，在4.0以下版本，我們只能使用重啟恢復：重啟載入 RDB 或者通過高可用主從切換實現資料的重新載入減少碎片。

在4.0以上版本，Redis提供了自動和手動的碎片整理功能，原理大致是把資料拷貝到新的記憶體空間，然後把老的空間釋放掉，這個是有一定的效能損耗的。

因為 Redis 是單執行緒，在資料拷貝時，Redis 只能等著，這就導致 Redis 無法處理請求，效能就會降低。

手動整理碎片

執行 memory purge命令即可。

自動整理記憶體碎片

使用 config set activedefrag yes 指令或者在 redis.conf 配置 activedefrag yes 將 activedefrag 配置成 yes 表示啟動自動清理功能。

這個配置還不夠，至於啥時候清理還需要看下面的兩個配置：

• active-defrag-ignore-bytes 200mb：記憶體碎片的大小達到 200MB，開始清理。
• active-defrag-threshold-lower 6：表示記憶體碎片空間佔作業系統分配給 Redis 的總空間比例達到 6% 時，開始清理。

只有滿足這兩個條件， Redis 才會執行記憶體碎片自動清理。

除此之外，Redis 為了防止清理碎片對 Redis 正常處理指令造成影響，有兩個引數用於控制清理操作佔用 CPU 的時間比例上下限。

• active-defrag-cycle-min 15： 自動清理過程所用 CPU 時間的比例不低於 15%，保證清理能有效展開。
• active-defrag-cycle-max 50：表示自動清理過程所用 CPU 時間的比例不能大於 50%，一旦超過，就停止清理，從而避免在清理時，大量的記憶體拷貝阻塞 Redis執行命令。

7. 使用 32 位的 Redis

使用32位的redis，對於每一個key,將使用更少的記憶體，因為32位程式，指標佔用的位元組數更少。

但是32的Redis整個例項使用的記憶體將被限制在4G以下。我們可以通過 cluster 模式將多個小記憶體節點構成一個叢集，從而儲存更多的資料。

另外小記憶體的節點 fork 生成 rdb 的速度也更快。

RDB和AOF檔案是不區分32位和64位的（包括位元組順序）,所以你可以使用64位的Redis 恢復32位的RDB備份檔案，相反亦然。

總結

打完收工，這一套神技下來，只想說一個字「絕」。

希望這篇文章，能幫你使用全域性視角去破解記憶體優化難題，我是「碼哥」，下回 Redis 再見。

想要加技術群的少年留步，掃描備註「加群」，進專屬技術讀者群一起吹牛逼。

看到這裡的靚仔，給個「三連」寫個評論呀，靚仔。

參考文獻

[1]https://redis.io/docs/reference/optimization/memory-optimization/

[2]《Redis 核心技術與實戰》

[3] https://segmentfault.com/a/1190000041771534