Redis優化神技：如何用更少記憶體，保存更多數據

今天跟大家分享一些優化神技，當你面試或者工作中你遇到如下問題，那就使出今天學到的絕招，一招定乾坤！如何用更少的記憶體保存更多的數據？我們應該從 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