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 存儲原理以及不同數據類型的存儲數據結構后，我們繼續看如何做性能優化。
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?配置。
ziplist
- 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 對應關系圖：
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。
ziplist 的不足
每次修改都可能觸發 realloc 和 memcopy, 可能導致連鎖更新(數據可能需要挪動)。
因此修改操作的效率較低，在 ziplist 的元素很多時這個問題更加突出。
優化手段：
- key 盡量控制在 44 字節以內，走 embstr 編碼。
- 集合類型的 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 內存占用：
redisObejct
用 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 再見。
