Redis 內存優化神技，小內存保存大數據

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

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

從而繼續延展出每種數據類型底層的數據結構，針對不同場景使用更恰當的數據結構和編碼實現更少的內存佔用。

爲了保存數據， Redis 需要先申請內存，數據過期或者內存淘汰需要回收內存，從而拓展出內存碎片優化。

最後，說下 key、value 使用規範和技巧、 Bitmap 等高階數據類型，運用這些技巧巧妙解決有限內存去存儲更多數據難題……

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

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

主要優化神技如下：

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

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

redisDb

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 表示當前沒有執行 rehashlong rehashidx;// 小於 0 表示 rehash 暫停int16_t pauserehash;signed char ht_size_exp[2];};

key 的哈希值最終會映射到 ht_table 的一個位置，如果發生哈希衝突，則拉出一個哈希鏈表。

大家重點關注 dictEntry 類型的 ht_table，ht_table 數組每個位置我們也叫做哈希桶，就是這玩意保存了所有鍵值對。

哈希桶的每個元素的結構由 dictEntry 定義：

typedef struct dictEntry {// 指向 key 的指針void *key;union {// 指向實際 value 的指針void *val;uint64_t u64;int64_t s64;double d;} v;// 哈希衝突拉出的鏈表struct dictEntry *next;} dictEntry;

哈希桶並沒有保存值本身，而是指向具體值的指針，從而實現了哈希桶能存不同數據類型的需求。

而哈希桶中，鍵值對的值都是由一個叫做 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;

如下圖是由 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）的長度。

在《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 格式的優點：方便調試和跨語言；缺點是：同樣的數據相比字節數組佔用的空間更大。

一定要 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 會自動轉成正常編碼。

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

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

quicklist：Redis 3.2 引入，並作爲 List 數據類型的底層實現，不再使用雙端鏈表 linkedlist 和 ziplist 實現。

以下是 Redis redis.conf 配置文件默認編碼閾值配置：

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

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

type 與編碼

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

比如當我們的存儲只有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。

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

因此修改操作的效率較低，在 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 緊湊型內存結構存儲數據，判斷整數對象是否共享的效率很低。

比如在一些「二值狀態統計」的場景下使用 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 實現億級數據統計》。

儘可能把數據抽象到一個哈希表裡。

比如說系統中有一個用戶對象，我們不需要爲一個用戶的暱稱、姓名、郵箱、地址等單獨設置一個 key，而是將這個信息存放在一個哈希表裡。

如下所示：

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

因爲 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 無法處理請求，性能就會降低。

執行 memory purge命令即可。

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

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

只有滿足這兩個條件， Redis 纔會執行內存碎片自動清理。

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

使用32位的redis，對於每一個key,將使用更少的內存，因爲32位程序，指針佔用的字節數更少。

但是32的Redis整個實例使用的內存將被限制在4G以下。我們可以通過 cluster 模式將多個小內存節點構成一個集羣，從而保存更多的數據。

另外小內存的節點 fork 生成 rdb 的速度也更快。

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

參考文獻[1]https://redis.io/docs/reference/optimization/memory-optimization/[2]《Redis 核心技術與實戰》[3] https://segmentfault.com/a/1190000041771534