這次跟大家分享一些優(yōu)化神技，當(dāng)你工作中遇到如下問題，那就使出今天學(xué)到的絕招，一招定乾坤！

?

如何用更少的內(nèi)存保存更多的數(shù)據(jù)？

我們應(yīng)該從 Redis 是如何保存數(shù)據(jù)的原理展開，分析鍵值對的存儲結(jié)構(gòu)和原理。

從而繼續(xù)延展出每種數(shù)據(jù)類型底層的數(shù)據(jù)結(jié)構(gòu)，針對不同場景使用更恰當(dāng)?shù)臄?shù)據(jù)結(jié)構(gòu)和編碼實(shí)現(xiàn)更少的內(nèi)存占用。

為了保存數(shù)據(jù)， Redis 需要先申請內(nèi)存，數(shù)據(jù)過期或者內(nèi)存淘汰需要回收內(nèi)存，從而拓展出內(nèi)存碎片優(yōu)化。

最后，說下 key、value 使用規(guī)范和技巧、 Bitmap 等高階數(shù)據(jù)類型，運(yùn)用這些技巧巧妙解決有限內(nèi)存去存儲更多數(shù)據(jù)難題……

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

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

主要優(yōu)化神技如下：

• 鍵值對優(yōu)化；
• 小數(shù)據(jù)集合的編碼優(yōu)化；
• 使用對象共享池；
• 使用 bit 比特位或 byte 級別操作
• 使用 hash 類型優(yōu)化；
• 內(nèi)存碎片優(yōu)化；
• 使用 32 位的 Redis。

在優(yōu)化之前，我們先掌握 Redis 是如何存儲數(shù)據(jù)的。

Redis 如何存儲鍵值對

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

redisDb

• dict：最重要的屬性之一，就是靠這個定義了保存了對象數(shù)據(jù)鍵值對，dcit 的底層結(jié)構(gòu)是一個哈希表。
• expires：保存著所有 key 的過期信息.
• blocking_keys 和 ready_keys 主要為了實(shí)現(xiàn) BLPOP 等阻塞命令
• watched_keys用于實(shí)現(xiàn)watch命令，記錄正在被watch的一些key，與事務(wù)相關(guān)。
• id 為當(dāng)前數(shù)據(jù)庫的id，redis 支持單個服務(wù)多數(shù)據(jù)庫，默認(rèn)有16個；
• clusterSlotToKeyMapping：cluster 模式下，存儲key 與哈希槽映射關(guān)系的數(shù)組。

Redis 使用「dict」結(jié)構(gòu)來保存所有的鍵值對（key-value）數(shù)據(jù)，這是一個全局哈希表，所以對 key 的查詢能以 O(1) 時間得到。

所謂哈希表，我們可以類比 Java 中的 HashMap，其實(shí)就是一個數(shù)組，數(shù)組的每個元素叫做哈希桶。

dict 結(jié)構(gòu)如下，源碼在 https://github.com/redis/redis/blob/7.0/src/dict.h：

struct dict { // 特定類型的處理函數(shù) dictType *type; // 兩個全局哈希表指針數(shù)組，與漸進(jìn)式 rehash 有關(guān) dictEntry **ht_table[2]; // 記錄 dict 中現(xiàn)有的數(shù)據(jù)個數(shù)。 unsigned long ht_used[2]; // 記錄漸進(jìn)式 rehash 進(jìn)度的標(biāo)志， -1 表示當(dāng)前沒有執(zhí)行 rehash long rehashidx; // 小于 0 表示 rehash 暫停 int16_t pauserehash; signed char ht_size_exp[2];};

• dictType：存儲了hash函數(shù)，key和value的復(fù)制等函數(shù)；
• ht_table：長度為 2 的 數(shù)組，正常情況使用 ht_table[0] 存儲數(shù)據(jù)，當(dāng)執(zhí)行 rehash 的時候，使用 ht_table[1] 配合完成 。

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

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

?

碼哥，Redis 支持那么多的數(shù)據(jù)類型，哈希桶咋保存？

哈希桶的每個元素的結(jié)構(gòu)由 dictEntry 定義：

typedef struct dictEntry { // 指向 key 的指針 void *key; union { // 指向?qū)嶋H value 的指針 void *val; uint64_t u64; int64_t s64; double d; } v; // 哈希沖突拉出的鏈表 struct dictEntry *next;} dictEntry;

• key 指向鍵值對的鍵的指針，key 都是 string 類型。
• value 是個 union（聯(lián)合體）當(dāng)它的值是 uint64_t、int64_t 或 double 類型時，就不再需要額外的存儲，這有利于減少內(nèi)存碎片。（為了節(jié)省內(nèi)存操碎了心）當(dāng)然，val 也可以是 void 指針，指向值的指針，以便能存儲任何類型的數(shù)據(jù)。
• next 指向另一個 dictEntry 結(jié)構(gòu)， 多個 dictEntry 可以通過 next 指針串連成鏈表， 從這里可以看出， ht_table 使用鏈地址法來處理鍵碰撞：當(dāng)多個不同的鍵擁有相同的哈希值時，哈希表用一個鏈表將這些鍵連接起來。

哈希桶并沒有保存值本身，而是指向具體值的指針，從而實(shí)現(xiàn)了哈希桶能存不同數(shù)據(jù)類型的需求。

而哈希桶中，鍵值對的值都是由一個叫做 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 等，根據(jù)該類型才可以確定是哪種數(shù)據(jù)類型，使用什么樣的 API 操作。
• encoding：編碼方式，表示 ptr 指向的數(shù)據(jù)類型具體數(shù)據(jù)結(jié)構(gòu)，即這個對象使用了什么數(shù)據(jù)結(jié)構(gòu)作為底層實(shí)現(xiàn)保存數(shù)據(jù)。同一個對象使用不同編碼實(shí)現(xiàn)內(nèi)存占用存在明顯差異，內(nèi)部編碼對內(nèi)存優(yōu)化非常重要。
• lru:LRU_BITS：LRU 策略下對象最后一次被訪問的時間，如果是 LFU 策略，那么低 8 位表示訪問頻率，高 16 位表示訪問時間。
• refcount ：表示引用計數(shù)，由于 C 語言并不具備內(nèi)存回收功能，所以 Redis 在自己的對象系統(tǒng)中添加了這個屬性，當(dāng)一個對象的引用計數(shù)為 0 時，則表示該對象已經(jīng)不被任何對象引用，則可以進(jìn)行垃圾回收了。
• ptr 指針：指向?qū)ο蟮牡讓訉?shí)現(xiàn)數(shù)據(jù)結(jié)構(gòu)，指向值的指針。

如下圖是由 redisDb、dict、dictEntry、redisObejct 關(guān)系圖：

redis存儲結(jié)構(gòu)

「碼哥」再嘮叨幾句，void *key 和 void *value 指針指向的是 redisObject，Redis 中每個對象都是用 redisObject 表示。

知道了 Redis 存儲原理以及不同數(shù)據(jù)類型的存儲數(shù)據(jù)結(jié)構(gòu)后，我們繼續(xù)看如何做性能優(yōu)化。

1. 鍵值對優(yōu)化

當(dāng)我們執(zhí)行 set key value 的命令，*key指針指向 SDS 字符串保存 key，而 value 的值保存在 *ptr 指針指向的數(shù)據(jù)結(jié)構(gòu)，消耗的內(nèi)存：key value。

第一個優(yōu)化神技：降低 Redis 內(nèi)存使用的最粗暴的方式就是縮減鍵（key）與值（value）的長度。

在《Redis 很強(qiáng)，不懂使用規(guī)范就糟蹋了》中我說過關(guān)于鍵值對的使用規(guī)范，對于 key 的命名使用「業(yè)務(wù)模塊名:表名:數(shù)據(jù)唯一id」這樣的方式方便定位問題。

比如：users:firends:996 表示用戶系統(tǒng)中，id = 996 的朋友信息。我們可以簡寫為：u:fs:996

對于 key 的優(yōu)化：使用單詞簡寫方式優(yōu)化內(nèi)存占用。

對于 value 的優(yōu)化那就更多了：

• 過濾不必要的數(shù)據(jù)：不要大而全的一股腦將所有信息保存，想辦法去掉一些不必要的屬性，比如緩存登錄用戶的信息，通常只需要存儲昵稱、性別、賬號等。
• 精簡數(shù)據(jù)：比如用戶的會員類型：0 表示「屌絲」、1 表示 「VIP」、2表示「VVIP」。而不是存儲 VIP 這個字符串。
• 數(shù)據(jù)壓縮：對數(shù)據(jù)的內(nèi)容進(jìn)行壓縮，比如使用 GZIP、Snappy。
• 使用性能好，內(nèi)存占用小的序列化方式。比如 Java 內(nèi)置的序列化不管是速度還是壓縮比都不行，我們可以選擇 protostuff，kryo等方式。如下圖 Java 常見的序列化工具空間壓縮比：序列化工具壓縮比?靚仔們，我們通常使用 json 作為字符串存儲在 Redis，用 json 存儲與二進(jìn)制數(shù)據(jù)存儲有什么優(yōu)缺點(diǎn)呢？json 格式的優(yōu)點(diǎn)：方便調(diào)試和跨語言；缺點(diǎn)是：同樣的數(shù)據(jù)相比字節(jié)數(shù)組占用的空間更大。一定要 json 格式的話，那就先通過壓縮算法壓縮 json，再把壓縮后的數(shù)據(jù)存入 Redis。比如 GZIP 壓縮后的 json 可降低約 60% 的空間。

2. 小數(shù)據(jù)集合編碼優(yōu)化

key 對象都是 string 類型，value 對象主要有五種基本數(shù)據(jù)類型：String、List、Set、Zset、Hash。

數(shù)據(jù)類型與底層數(shù)據(jù)結(jié)構(gòu)的關(guān)系如下所示：

編碼與數(shù)據(jù)結(jié)構(gòu)

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

另外，同一數(shù)據(jù)類型會根據(jù)鍵的數(shù)量和值的大小也有不同的底層編碼類型實(shí)現(xiàn)。

在 Redis 2.2 版本之后，存儲集合數(shù)據(jù)（Hash、List、Set、SortedSet）在滿足某些情況下會采用內(nèi)存壓縮技術(shù)來實(shí)現(xiàn)使用更少的內(nèi)存存儲更多的數(shù)據(jù)。

當(dāng)這些集合中的數(shù)據(jù)元素數(shù)量小于某個值且元素的值占用的字節(jié)大小小于某個值的時候，存儲的數(shù)據(jù)會用非常節(jié)省內(nèi)存的方式進(jìn)行編碼，理論上至少節(jié)省 10 倍以上內(nèi)存（平均節(jié)省 5 倍以上）。

比如 Hash 類型里面的數(shù)據(jù)不是很多，雖然哈希表的時間復(fù)雜度是 O(1)，ziplist 的時間復(fù)雜度是 O(n)，但是使用 ziplist 保存數(shù)據(jù)的話會節(jié)省了內(nèi)存，并且在少量數(shù)據(jù)情況下效率并不會降低很多。

所以我們需要盡可能地控制集合元素數(shù)量和每個元素的內(nèi)存大小，這樣能充分利用緊湊型編碼減少內(nèi)存占用。

并且，這些編碼對用戶和 api 是無感知的，當(dāng)集合數(shù)據(jù)超過配置文件的配置的最大值， Redis 會自動轉(zhuǎn)成正常編碼。

?

數(shù)據(jù)類型對應(yīng)的編碼規(guī)則如下所示

String 字符串

• int：整數(shù)且數(shù)字長度小于 20，直接保存在 *ptr 中。
• embstr：開辟一塊連續(xù)分配的內(nèi)存（字符串長度小于等于 44 字節(jié)）。
• raw：動態(tài)字符串（大于 44 字節(jié)的字符串，同時字符串小于 512 MB）。

List 列表

• ziplist：元素個數(shù)小于hash-max-ziplist-entries配置，同時所有的元素的值大小都小于 hash-max-ziplist-value配置。ziplist
• linkedlist：3.0 版本之前當(dāng)列表類型無法滿足 ziplist 的條件時，Redis會使用 linkedlist 作為列表的內(nèi)部實(shí)現(xiàn)。
• quicklist：Redis 3.2 引入，并作為 List 數(shù)據(jù)類型的底層實(shí)現(xiàn)，不再使用雙端鏈表 linkedlist 和 ziplist 實(shí)現(xiàn)。

Set 集合

• intset 整數(shù)集合：元素都是整數(shù)，且元素個數(shù)小于 set-max-intset-entries配置
• hashtable 哈希表：集合類型無法滿足intset的條件時就會使用hashtable 編碼。

Hash 哈希表

• ziplist：元素個數(shù)小于 hash-max-ziplist-entries配置，同時任意一個 value 的占用字節(jié)大小都小于hash-max-ziplist-value 。
• hashtable：hash 類型無法滿足 intset 的條件時就會使用hashtable。

Sorted Set 有序集合

• ziplist：元素個數(shù)小于 zset-max-ziplist-entries 同時每個元素的value小于“zset-max-ziplist-value`配置。
• skiplist：當(dāng)ziplist條件不滿足時，有序集合會使用skiplist作為內(nèi)部實(shí)現(xiàn)。

以下是 Redis redis.conf 配置文件默認(rèn)編碼閾值配置：

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

下圖是 reidsObject 對象的 type 和 encoding 對應(yīng)關(guān)系圖：

type 與編碼

?

碼哥，為啥對一種數(shù)據(jù)類型實(shí)現(xiàn)多種不同編碼方式？

主要原因是想通過不同編碼實(shí)現(xiàn)效率和空間的平衡。

比如當(dāng)我們的存儲只有100個元素的列表，當(dāng)使用雙向鏈表數(shù)據(jù)結(jié)構(gòu)時，需要維護(hù)大量的內(nèi)部字段。

比如每個元素需要：前置指針，后置指針，數(shù)據(jù)指針等，造成空間浪費(fèi)。

如果采用連續(xù)內(nèi)存結(jié)構(gòu)的壓縮列表(ziplist)，將會節(jié)省大量內(nèi)存，而由于數(shù)據(jù)長度較小，存取操作時間復(fù)雜度即使為O(n) 性能也相差不大，因為 n 值小 與 O(1) 并明顯差別。

數(shù)據(jù)編碼優(yōu)化技巧

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

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

由于目前大部分Redis運(yùn)行的版本都是在3.2以上，所以 List 類型的編碼都是quicklist。

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

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

ziplist 的不足

每次修改都可能觸發(fā) realloc 和 memcopy, 可能導(dǎo)致連鎖更新(數(shù)據(jù)可能需要挪動)。

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

優(yōu)化手段：

1. key 盡量控制在 44 字節(jié)以內(nèi)，走 embstr 編碼。
2. 集合類型的 value 對象的元素個數(shù)不要太多太大，充分利用 ziplist 編碼實(shí)現(xiàn)內(nèi)存壓縮。

3. 對象共享池

整數(shù)我們經(jīng)常在工作中使用，Redis 在啟動的時候默認(rèn)生成一個 0 ~9999 的整數(shù)對象共享池用于對象復(fù)用，減少內(nèi)存占用。

比如執(zhí)行set 碼哥 18; set 吳彥祖 18; key 等于 「碼哥」 和「吳彥祖」的 value 都指向同一個對象。

如果 value 可以使用整數(shù)表示的話盡可能使用整數(shù)，這樣即使大量鍵值對的 value 大量保存了 0~9999 范圍內(nèi)的整數(shù)，在實(shí)例中，其實(shí)只有一份數(shù)據(jù)。

靚仔們，有兩個大坑需要注意，它會導(dǎo)致對象共享池失效。

• Redis 中設(shè)置了 maxmemory 限制最大內(nèi)存占用大小且啟用了 LRU 策略（allkeys-lru 或 volatile-lru 策略）。?碼哥，為啥呀？因為 LRU 需要記錄每個鍵值對的訪問時間，都共享一個整數(shù) 對象，LRU 策略就無法進(jìn)行統(tǒng)計了。
• 集合類型的編碼采用 ziplist 編碼，并且集合內(nèi)容是整數(shù)，也不能共享一個整數(shù)對象。?這又是為啥呢？使用了 ziplist 緊湊型內(nèi)存結(jié)構(gòu)存儲數(shù)據(jù)，判斷整數(shù)對象是否共享的效率很低。

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

比如在一些「二值狀態(tài)統(tǒng)計」的場景下使用 Bitmap 實(shí)現(xiàn)，對于網(wǎng)頁 UV 使用 HyperLogLog 來實(shí)現(xiàn)，大大減少內(nèi)存占用。

?

碼哥，什么是二值狀態(tài)統(tǒng)計呀？

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

假如我們在判斷用戶是否登陸的場景中使用 Redis 的 String 類型實(shí)現(xiàn)（key -> userId，value -> 0 表示下線，1 – 登陸），假如存儲 100 萬個用戶的登陸狀態(tài)，如果以字符串的形式存儲，就需要存儲 100 萬個字符串，內(nèi)存開銷太大。

String 類型除了記錄實(shí)際數(shù)據(jù)以外，還需要額外的內(nèi)存記錄數(shù)據(jù)長度、空間使用等信息。

Bitmap 的底層數(shù)據(jù)結(jié)構(gòu)用的是 String 類型的 SDS 數(shù)據(jù)結(jié)構(gòu)來保存位數(shù)組，Redis 把每個字節(jié)數(shù)組的 8 個 bit 位利用起來，每個 bit 位 表示一個元素的二值狀態(tài)（不是 0 就是 1）。

可以將 Bitmap 看成是一個 bit 為單位的數(shù)組，數(shù)組的每個單元只能存儲 0 或者 1，數(shù)組的下標(biāo)在 Bitmap 中叫做 offset 偏移量。

為了直觀展示，我們可以理解成 buf 數(shù)組的每個字節(jié)用一行表示，每一行有 8 個 bit 位，8 個格子分別表示這個字節(jié)中的 8 個 bit 位，如下圖所示：

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

關(guān)于 Bitmap 的詳細(xì)解答，大家可移步 -> 《Redis 實(shí)戰(zhàn)篇：巧用 Bitmap 實(shí)現(xiàn)億級數(shù)據(jù)統(tǒng)計》。

5. 妙用 Hash 類型優(yōu)化

盡可能把數(shù)據(jù)抽象到一個哈希表里。

比如說系統(tǒng)中有一個用戶對象，我們不需要為一個用戶的昵稱、姓名、郵箱、地址等單獨(dú)設(shè)置一個 key，而是將這個信息存放在一個哈希表里。

如下所示：

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

?

為啥使用 String 類型，為每個屬性設(shè)置一個 key 會占用大量內(nèi)存呢？

因為 Redis 的數(shù)據(jù)類型有很多，不同數(shù)據(jù)類型都有些相同的元數(shù)據(jù)要記錄（比如最后一次訪問的時間、被引用的次數(shù)等）。

所以，Redis 會用一個 RedisObject 結(jié)構(gòu)體來統(tǒng)一記錄這些元數(shù)據(jù)，用 *prt 指針指向?qū)嶋H數(shù)據(jù)。

當(dāng)我們?yōu)槊總€屬性都創(chuàng)建 key，就會創(chuàng)建大量的 redisObejct 對象占用內(nèi)存。

如下所示 redisObject 內(nèi)存占用：

redisObejct

用 Hash 類型的話，每個用戶只需要設(shè)置一個 key。

6. 內(nèi)存碎片優(yōu)化

Redis 釋放的內(nèi)存空間可能并不是連續(xù)的，這些不連續(xù)的內(nèi)存空間很有可能處于一種閑置的狀態(tài)。

雖然有空閑空間，Redis 卻無法用來保存數(shù)據(jù)，不僅會減少 Redis 能夠?qū)嶋H保存的數(shù)據(jù)量，還會降低 Redis 運(yùn)行機(jī)器的成本回報率。

比如， Redis 存儲一個整形數(shù)字集合需要一塊占用 32 字節(jié)的連續(xù)內(nèi)存空間，當(dāng)前雖然有 64 字節(jié)的空閑，但是他們都是不連續(xù)的，導(dǎo)致無法保存。

?

內(nèi)存碎片是如何形成呢？

兩個層面原因?qū)е拢?/span>

• 操作系統(tǒng)內(nèi)存分配機(jī)制：內(nèi)存分配策略決定了無法做到按需分配。因為分配器是按照固定大小來分配內(nèi)存。
• 鍵值對被修改和刪除，從而導(dǎo)致內(nèi)存空間的擴(kuò)容和釋放。

碎片優(yōu)化可以降低內(nèi)存使用率，提高訪問效率，在4.0以下版本，我們只能使用重啟恢復(fù)：重啟加載 RDB 或者通過高可用主從切換實(shí)現(xiàn)數(shù)據(jù)的重新加載減少碎片。

在4.0以上版本，Redis提供了自動和手動的碎片整理功能，原理大致是把數(shù)據(jù)拷貝到新的內(nèi)存空間，然后把老的空間釋放掉，這個是有一定的性能損耗的。

因為 Redis 是單線程，在數(shù)據(jù)拷貝時，Redis 只能等著，這就導(dǎo)致 Redis 無法處理請求，性能就會降低。

手動整理碎片

執(zhí)行 memory purge命令即可。

自動整理內(nèi)存碎片

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

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

• active-defrag-ignore-bytes 200mb：內(nèi)存碎片的大小達(dá)到 200MB，開始清理。
• active-defrag-threshold-lower 6：表示內(nèi)存碎片空間占操作系統(tǒng)分配給 Redis 的總空間比例達(dá)到 6% 時，開始清理。

只有滿足這兩個條件， Redis 才會執(zhí)行內(nèi)存碎片自動清理。

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

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

7. 使用 32 位的 Redis

使用32位的redis，對于每一個key,將使用更少的內(nèi)存，因為32位程序，指針占用的字節(jié)數(shù)更少。

但是32的Redis整個實(shí)例使用的內(nèi)存將被限制在4G以下。我們可以通過 cluster 模式將多個小內(nèi)存節(jié)點(diǎn)構(gòu)成一個集群，從而保存更多的數(shù)據(jù)。

另外小內(nèi)存的節(jié)點(diǎn) fork 生成 rdb 的速度也更快。

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

參考文獻(xiàn)

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

[2]《Redis 核心技術(shù)與實(shí)戰(zhàn)》

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