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

?

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

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

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

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

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

這一套組合拳下來(lái)直接封神。

具體詳情，且看「碼哥」一一道來(lái)。

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

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

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

Redis 如何存儲(chǔ)鍵值對(duì)

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

redisDb

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

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

String 字符串

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

List 列表

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

Set 集合

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

Hash 哈希表

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

Sorted Set 有序集合

• ziplist：元素個(gè)數(shù)小于 zset-max-ziplist-entries 同時(shí)每個(gè)元素的value小于“zset-max-ziplist-value`配置。
• skiplist：當(dāng)ziplist條件不滿足時(shí)，有序集合會(huì)使用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 對(duì)象的 type 和 encoding 對(duì)應(yīng)關(guān)系圖：

type 與編碼

?

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

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

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

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

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

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

ziplist 存儲(chǔ) list 時(shí)每個(gè)元素會(huì)作為一個(gè) entry，存儲(chǔ) hash 時(shí) key 和 value 會(huì)作為相鄰的兩個(gè) entry。

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

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

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

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

ziplist 的不足

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

因此修改操作的效率較低，在 ziplist 的元素很多時(shí)這個(gè)問(wèn)題更加突出。

優(yōu)化手段：

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

3. 對(duì)象共享池

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

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

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

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

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

4.使用 Bit 比特位或 byte 級(jí)別操作

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

?

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

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

假如我們?cè)谂袛嘤脩羰欠竦顷懙膱?chǎng)景中使用 Redis 的 String 類(lèi)型實(shí)現(xiàn)（key -> userId，value -> 0 表示下線，1 – 登陸），假如存儲(chǔ) 100 萬(wàn)個(gè)用戶的登陸狀態(tài)，如果以字符串的形式存儲(chǔ)，就需要存儲(chǔ) 100 萬(wàn)個(gè)字符串，內(nèi)存開(kāi)銷(xiāo)太大。

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

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

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

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

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

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

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

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

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

如下所示：

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

?

為啥使用 String 類(lèi)型，為每個(gè)屬性設(shè)置一個(gè) key 會(huì)占用大量?jī)?nèi)存呢？

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

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

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

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

redisObejct

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

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

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

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

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

?

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

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

• 操作系統(tǒng)內(nèi)存分配機(jī)制：內(nèi)存分配策略決定了無(wú)法做到按需分配。因?yàn)榉峙淦魇前凑展潭ù笮?lái)分配內(nèi)存。
• 鍵值對(duì)被修改和刪除，從而導(dǎo)致內(nèi)存空間的擴(kuò)容和釋放。

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

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

因?yàn)?Redis 是單線程，在數(shù)據(jù)拷貝時(shí)，Redis 只能等著，這就導(dǎo)致 Redis 無(wú)法處理請(qǐng)求，性能就會(huì)降低。

手動(dòng)整理碎片

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

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

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

這個(gè)配置還不夠，至于啥時(shí)候清理還需要看下面的兩個(gè)配置：

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

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

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

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

7. 使用 32 位的 Redis

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

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