建站
咨詢
售后
建站咨詢
新聞中心
這次碼哥跟大家分享一些優(yōu)化神技，當(dāng)你面試或者工作中你遇到如下問題，那就使出今天學(xué)到的絕招，一招定乾坤！
隴川ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！
如何用更少的內(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 ：表示引用計(jì)數(shù)，由于 C 語言并不具備內(nèi)存回收功能，所以 Redis 在自己的對象系統(tǒng)中添加了這個屬性，當(dāng)一個對象的引用計(jì)數(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ù)元素?cái)?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ù)情況下效率并不會降低很多。
所以我們需要盡可能地控制集合元素?cái)?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 512
hash-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
set-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) 性能也相差不大，因?yà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)化手段：
- key 盡量控制在 44 字節(jié)以內(nèi)，走 embstr 編碼。
- 集合類型的 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 策略）。
碼哥，為啥呀？
因?yàn)?LRU 需要記錄每個鍵值對的訪問時間，都共享一個整數(shù) 對象，LRU 策略就無法進(jìn)行統(tǒng)計(jì)了。
- 集合類型的編碼采用 ziplist 編碼，并且集合內(nèi)容是整數(shù)，也不能共享一個整數(shù)對象。
這又是為啥呢？
- 使用了 ziplist 緊湊型內(nèi)存結(jié)構(gòu)存儲數(shù)據(jù)，判斷整數(shù)對象是否共享的效率很低。
4、使用 Bit 比特位或 byte 級別操作
比如在一些「二值狀態(tài)統(tǒng)計(jì)」的場景下使用 Bitmap 實(shí)現(xiàn)，對于網(wǎng)頁 UV 使用 HyperLogLog 來實(shí)現(xiàn)，大大減少內(nèi)存占用。
碼哥，什么是二值狀態(tài)統(tǒng)計(jì)呀？
也就是集合中的元素的值只有 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)計(jì)??》。
5、妙用 Hash 類型優(yōu)化
盡可能把數(shù)據(jù)抽象到一個哈希表里。
比如說系統(tǒng)中有一個用戶對象，我們不需要為一個用戶的昵稱、姓名、郵箱、地址等單獨(dú)設(shè)置一個 key，而是將這個信息存放在一個哈希表里。
如下所示：
hset users:深圳:999 姓名 碼哥
hset users:深圳:999 年齡 18
hset users:深圳:999 愛好 女
為啥使用 String 類型，為每個屬性設(shè)置一個 key 會占用大量內(nèi)存呢？
因?yàn)?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ī)器的成本回報(bào)率。
比如， Redis 存儲一個整形數(shù)字集合需要一塊占用 32 字節(jié)的連續(xù)內(nèi)存空間，當(dāng)前雖然有 64 字節(jié)的空閑，但是他們都是不連續(xù)的，導(dǎo)致無法保存。
內(nèi)存碎片是如何形成呢？
兩個層面原因?qū)е拢?/p>
- 操作系統(tǒng)內(nèi)存分配機(jī)制：內(nèi)存分配策略決定了無法做到按需分配。因?yàn)榉峙淦魇前凑展潭ù笮矸峙鋬?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)存空間，然后把老的空間釋放掉，這個是有一定的性能損耗的。
因?yàn)?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)存，因?yàn)?2位程序，指針占用的字節(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備份文件，相反亦然。
總結(jié)
打完收工，這一套神技下來，只想說一個字「絕」。
希望這篇文章，能幫你使用全局視角去破解內(nèi)存優(yōu)化難題，我是「碼哥」，下回 Redis 再見。
文章題目：Redis內(nèi)存優(yōu)化神技，小內(nèi)存保存大數(shù)據(jù)
網(wǎng)頁路徑：http://www.dlmjj.cn/article/dpisdgd.html
