為什么使用top命令時，Redis還是占了很多內(nèi)存？

Redis做了數(shù)據(jù)刪除操作，為什么使用top命令時，Redis還是占了很多內(nèi)存？

沒做相關(guān)功課的人覺得這個問題有問題，刪了數(shù)據(jù)還說占著內(nèi)存，面試官不是在誤導(dǎo)我嗎，事實并非如此！

這里先說答案

實際上，這是因為，當數(shù)據(jù)刪除后，Redis 釋放的內(nèi)存空間會由內(nèi)存分配器管理，并不會立即返回給操作系統(tǒng)。所以，操作系統(tǒng)仍然會記錄著給 Redis 分配了大量內(nèi)存。

而 used_memory_rss 記錄著在操作系統(tǒng)角度，Redis進程占用的物理總內(nèi)存

這樣看來文章好像講完了，開頭就知道答案，當然不是，內(nèi)容多著呢~

文章將從下面這些點分析擴展你對于Redis內(nèi)存方面的知識點，以及內(nèi)存碎片和如何清理內(nèi)存碎片。

畢竟面試官問你一個問題，你選擇只回答一句和面試官掰扯掰扯兩種方式，那么第二種情況更會讓他覺得你厲害爆了，懂得真多！

Redis內(nèi)存消耗組成

Redis內(nèi)存消耗主要在于其主進程消耗和子進程消耗。而主進程消耗又主要包括自身內(nèi)存、對象內(nèi)存、緩沖區(qū)內(nèi)存、內(nèi)存碎片四個方面：

自身進程占用內(nèi)存

Redis進程自身所占用的內(nèi)存，這部分內(nèi)存通常很小，一個空的Redis進程所消耗的內(nèi)存幾乎可以忽略不計

數(shù)據(jù)對象內(nèi)存

對象占用的內(nèi)存是Redis中占用內(nèi)存最大的，這里存儲這我們的鍵值對，我們知道不同的數(shù)據(jù)類型占用的內(nèi)存空間大小也不同，特別是那種大key占用內(nèi)存的情況就更驚人了。

緩沖區(qū)

Redis主要有三大緩沖區(qū)：客戶端緩沖區(qū)、AOF緩沖區(qū)、復(fù)制緩存區(qū)

客戶端緩沖區(qū)：為了解決客戶端和服務(wù)端請求和處理速度不匹配問題(即CPU 與 I/O 設(shè)備速度不匹配的矛盾)，分為輸入和輸出緩沖區(qū)。

輸入緩沖區(qū)會先把客戶端發(fā)送過來的命令暫存起來，Redis 主線程再從輸入緩沖區(qū)中讀取命令，進行處理。當在處理完數(shù)據(jù)后，會把結(jié)果寫入到輸出緩沖區(qū)，再通過輸出緩沖區(qū)返回給客戶端。

AOF緩沖區(qū)：在進行AOF持久化時所用到的緩沖區(qū)，AOF緩沖區(qū)消耗的內(nèi)存取決于AOF重寫時間和寫入命令量， 分為AOF緩沖區(qū)和AOF重寫緩沖區(qū)

復(fù)制緩沖區(qū)：是在集群環(huán)境中為了保證主從節(jié)點數(shù)據(jù)同步的所設(shè)置的，由于主從節(jié)點間的數(shù)據(jù)復(fù)制包括全量復(fù)制和增量復(fù)制兩種。因此復(fù)制緩沖區(qū)也分為復(fù)制緩沖區(qū)和復(fù)制積壓緩沖區(qū)兩種，分別用于全量和增量同步

內(nèi)存碎片

內(nèi)存碎片主要是有兩個原因：操作系統(tǒng)的內(nèi)存分配機制、Redis存儲特性，這兩個原因我們在文章中會具體提到。

子進程消耗

子進程消耗是指在RDB、AOF重寫時fork()子進程的內(nèi)存消耗

有人說這不是用到了寫時復(fù)制技術(shù)嗎？

雖然子進程可以不用完全復(fù)制父進程的物理內(nèi)存，但是仍然需要復(fù)制其內(nèi)存頁表，在此期間如果有寫入操作則需要復(fù)制出一份副本出來，因此同樣會消耗一部分內(nèi)存，消耗的內(nèi)存兩取決于RDB和AOF重寫期間的寫入命令數(shù)量。

查看內(nèi)存指標

查看當前Redis相關(guān)內(nèi)存信息用 info memory 命令，如果是集群使用 cluster info命令

127.0.0.1:6379> info memory


used_memory:856472  // Redis 存儲數(shù)據(jù)占用的內(nèi)存量
used_memory_human:836.40K  // 人類可讀形式返回內(nèi)存總量
used_memory_rss:1282048  // 操作系統(tǒng)角度，進程占用的物理總內(nèi)存
used_memory_rss_human:1.22M // used_memory_rss 可讀性模式展示
used_memory_peak:857448 // 內(nèi)存使用的最大值，表示 used_memory 的峰值
used_memory_peak_human:837.35K  // 以可讀的格式返回 used_memory_peak的值
used_memory_lua:37888   // Lua 引擎所消耗的內(nèi)存大小。
used_memory_lua_human:37.00K
maxmemory:2147483648    // 能使用的最大內(nèi)存值，字節(jié)為單位。
maxmemory_human:2.00G  // 可讀形式
maxmemory_policy:noeviction // 內(nèi)存淘汰策略


// used_memory_rss / used_memory 的比值，代表內(nèi)存碎片率
mem_fragmentation_ratio:2.79

used_memory_rss：操作系統(tǒng)分配給 Redis 進程的內(nèi)存空間（包含內(nèi)存碎片占用的空間），此數(shù)據(jù)結(jié)果約等于top、ps命令看到的數(shù)據(jù)結(jié)果，是從操作系統(tǒng)層看到的數(shù)據(jù)

maxmemory：Redis 最大可用內(nèi)存，0表示不限制，我們一般會設(shè)置這個值，避免所有內(nèi)存超過物理內(nèi)存

內(nèi)存為何沒釋放

Redis 釋放的內(nèi)存空間會由內(nèi)存分配器管理，并不會立即返回給操作系統(tǒng)，是因為采用了一種稱為“惰性刪除”的機制，即在數(shù)據(jù)被刪除之后，并不會立即釋放內(nèi)存空間，而是等到有新數(shù)據(jù)需要使用該空間時才會釋放。

這種方式的好處是可以減少內(nèi)存分配和釋放的開銷，提高 Redis 的性能。

但是Redis釋放內(nèi)存空間可能不是連續(xù)的，可能導(dǎo)致空間閑置(也就是出現(xiàn)內(nèi)存碎片)，而內(nèi)存碎片過大會導(dǎo)致明明有空間可用，但是卻無法存儲數(shù)據(jù)！

ok！我們繼續(xù)看看什么是內(nèi)存碎片

內(nèi)存碎片

前面我們已經(jīng)了解了Redis占用內(nèi)存的組成以及如何查看內(nèi)存占用信息，接下來看什么是內(nèi)存碎片和導(dǎo)致出現(xiàn)內(nèi)存碎片的原因。

Redis使用多種內(nèi)存分配策略，例如 jemalloc 和 libc，這些分配器無法做到按需分配，通常會按照固定大小進行分配。例如，如果Redis申請6字節(jié)的內(nèi)存，操作系統(tǒng)會分配8字節(jié)的內(nèi)存給Redis使用，剩下的2個字節(jié)空間無法被使用就是內(nèi)存碎片。

但這種分配方式也有優(yōu)勢，可以減少向操作系統(tǒng)申請空間分配。

導(dǎo)致Redis產(chǎn)生內(nèi)存碎片主要由以下兩點：

內(nèi)存分配機制導(dǎo)致

數(shù)據(jù)修改引發(fā)空間擴容和釋放

內(nèi)存分配機制導(dǎo)致

操作系統(tǒng)的架構(gòu)和 Redis jemalloc 分配策略無法做到按需分配，而是應(yīng)用程序申請內(nèi)存大小必須是一塊連續(xù)的內(nèi)存地址空間。

這種連續(xù)是按固定大小來分配的，比如：8字節(jié)、16 字節(jié)、32 字節(jié)、64 字節(jié) ... 這種方式會在程序申請內(nèi)存接近某個值的時候，jemalloc就會給它分配響應(yīng)大小的內(nèi)存空間。

上圖中：

第一次存儲數(shù)據(jù)是需要6字節(jié)，而Redis內(nèi)存分配策略給你分配了8字節(jié)，空出2個字節(jié)的空間。

第二次存儲數(shù)據(jù)是需要4個字節(jié)，但是空出的2個字節(jié)無法保存4字節(jié)數(shù)據(jù)，所以會再次向系統(tǒng)申請8字節(jié)內(nèi)存空間，空出了4字節(jié)，兩次存儲數(shù)據(jù)就多出來6個字節(jié)的內(nèi)存碎片。

這也就是內(nèi)存分配機制導(dǎo)致的形成碎片的風險和原因。

數(shù)據(jù)修改引發(fā)空間擴容和釋放

這個原因應(yīng)該更好理解吧，若修改數(shù)據(jù)時占用的空間有變化，此時就需要擴容或者縮容；而刪除數(shù)據(jù)也會將內(nèi)存釋放出來，形成碎片。

如下圖：

各數(shù)據(jù)占用內(nèi)存字節(jié)空間分別是A：2、B：1、C：3、D：3

此時D釋放了一個字節(jié)空間

A修改了數(shù)據(jù)，增加了一個字節(jié)。為保證A的內(nèi)存空間連續(xù)性，B的數(shù)據(jù)拷貝到了第二階段D釋放出來的那個字節(jié)位置

C修改后刪除了2個字節(jié)空間

可以看出經(jīng)過一系列對數(shù)據(jù)的修改，C和D之間有2字段內(nèi)存空間，此時多出來2字節(jié)空間就是內(nèi)存碎片。

處理內(nèi)存碎片

如何在進行處理內(nèi)存碎片，那么以什么為參考呢？

前面說的 info memory命令，如果指標值 mem_fragmentation_ratio (內(nèi)存碎片率)的值，在 1 < 碎片率 < 1.5，可以認為是合理的，而大于 1.5 說明碎片已經(jīng)超過 50%，我們需要采取一些手段解決碎片率過大的問題。

有下面三種方式可處理 ：

重啟Redis實例

重啟Redis屬于直接當時粗暴的方式，在重啟之前要考慮兩點：

若Redis的數(shù)據(jù)沒有持久化，數(shù)據(jù)會丟失

即使做了持久化，重啟需要通過AOF或RDB恢復(fù)數(shù)據(jù)，恢復(fù)時間取決于日志的大小，如果恢復(fù)時間長，這個階段實例就不能提供服務(wù)了

這種方式還是要慎重！

memory purge手動碎片整理

手動整理內(nèi)存碎片，會阻塞主進程，生產(chǎn)環(huán)境慎用。

memory purge 和 activedefrag回收的并不是同一塊區(qū)域的內(nèi)存，它簡單粗暴的嘗試清除臟頁以便內(nèi)存分配器回收。可以根據(jù)實際情況和activedefrag配合使用，memory purge在極端情況下效果較好，activedefrag則更徹底。

開啟activedefrag自動碎片整理

在Redis 4.0 版本后新增配置項activedefrag，activedefrag默認關(guān)閉，計劃清理碎片時需手動開啟，命令如下：

127.0.0.1:6379> config set activedefrag yes

自動整理內(nèi)存碎片，其原理是通過scan迭代整個Redis數(shù)據(jù)，通過一系列的內(nèi)存復(fù)制、轉(zhuǎn)移操作完成內(nèi)存碎片整理，由于此操作使用的是主線程，故會影響Redis對其他請求的響應(yīng)。

如上圖碎片整理過程：

清理前，C和D之間多了2字節(jié)的內(nèi)存碎片

清理過程：將B和D的數(shù)據(jù)分別拷貝到C和D之間的閑置空間，這樣2個字節(jié)的閑置空間就形成了連續(xù)空間。當新應(yīng)用要申請小于3個字節(jié)的空間時，這個閑置空間就能利用起來了

清理的條件

active-defrag-ignore-bytes 200mb：內(nèi)存碎片占用的內(nèi)存達到 200MB，開始清理；

active-defrag-threshold-lower 20：內(nèi)存碎片的空間占比超過系統(tǒng)分配給 Redis 空間的 20% ，開始清理

審核編輯：劉清