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：

redisDb

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 關系圖：

redis存盤結構

void *key 和 void *value 指標指向的是 redisObject，Redis 中每個物件都是用 redisObject 表示，

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

一、鍵值對優化

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

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

對于 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% 的空間，

二、小資料集合編碼優化

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 會自動轉成正常編碼，

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

1、String 字串

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

2、List 串列

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

ziplist

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

quicklist：Redis 3.2 引入，并作為 List 資料型別的底層實作，不再使用雙端鏈表 linkedlist 和 ziplist 實作，

3、Set 集合

intset 整數集合：元素都是整數，且元素個數小于 set-max-intset-entries配置

hashtable 哈希表：集合型別無法滿足intset的條件時就會使用hashtable 編碼，

4、Hash 哈希表

ziplist：元素個數小于 hash-max-ziplist-entries配置，同時任意一個 value 的占用位元組大小都小于hash-max-ziplist-value ，

hashtable：hash 型別無法滿足 intset 的條件時就會使用hashtable，

5、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 對應關系圖：

type 與編碼

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

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

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

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

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

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，

2）ziplist 的不足

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

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

優化手段：

key 盡量控制在 44 位元組以內，走 embstr 編碼，

集合型別的 value 物件的元素個數不要太多太大，充分利用 ziplist 編碼實作記憶體壓縮，

三、物件共享池

整數我們經常在作業中使用，Redis 在啟動的時候默認生成一個 0 ~9999 的整數物件共享池用于物件復用，減少記憶體占用，

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

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

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

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

原因如下：

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

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

原因如下：

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

四、使用 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 的優勢，

五、妙用 Hash 型別優化

盡可能把資料抽象到一個哈希表里，

比如說系統中有一個用戶物件，我們不需要為一個用戶的昵稱、姓名、郵箱、地址等單獨設定一個 key，而是將這個資訊存放在一個哈希表里，

如下所示：

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

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

因為 Redis 的資料型別有很多，不同資料型別都有些相同的元資料要記錄（比如最后一次訪問的時間、被參考的次數等），

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

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

如下所示 redisObject 記憶體占用：

redisObejct

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

六、記憶體碎片優化

Redis 釋放的記憶體空間可能并不是連續的，這些不連續的記憶體空間很有可能處于一種閑置的狀態，

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

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

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

兩個層面原因導致：

作業系統記憶體分配機制：記憶體分配策略決定了無法做到按需分配，因為分配器是按照固定大小來分配記憶體，

鍵值對被修改和洗掉，從而導致記憶體空間的擴容和釋放，

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

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

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

1、手動整理碎片

執行 memory purge命令即可，

2、自動整理記憶體碎片

使用 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執行命令，

七、使用 32 位的 Redis

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

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

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

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

總結

打完收工，這一套神技下來，只想說一個字「絕」，希望這篇文章，能幫你使用全域視角去破解記憶體優化難題，

>>>>

參考資料

https://redis.io/docs/reference/optimization/memory-optimization/
《Redis 核心技術與實戰》
https://segmentfault.com/a/1190000041771534

作者丨就是碼哥呀

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Redis-optimization-magic-skill-how-to-save-more-data-with-less-memory.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/528864.html

標籤：NoSQL

上一篇：mongodb踩坑

下一篇：9個GaussDB常用的物件陳述句