Redis做了數據刪除操作，為什么使用top命令時，Redis還是占了很多內存？

沒做相關功課的人覺得這個問題有問題，刪了數據還說占著內存，面試官不是在誤導我嗎，事實并非如此！

這里先說答案

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

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

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

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

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

Redis內存消耗組成

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

自身進程占用內存

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

數據對象內存

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

緩沖區(qū)

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

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

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

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

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

內存碎片

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

子進程消耗

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

有人說這不是用到了寫時復制技術嗎？

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

查看內存指標

查看當前Redis相關內存信息用 info memory 命令，如果是集群使用 cluster info命令

127.0.0.1:6379> info memory


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


// used_memory_rss / used_memory 的比值，代表內存碎片率
mem_fragmentation_ratio:2.79

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

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

內存為何沒釋放

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

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

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

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

內存碎片

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

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

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

導致Redis產生內存碎片主要由以下兩點：

內存分配機制導致

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

內存分配機制導致

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

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

上圖中：

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

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

這也就是內存分配機制導致的形成碎片的風險和原因。

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

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

如下圖：

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

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

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

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

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

處理內存碎片

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

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

有下面三種方式可處理 ：

重啟Redis實例

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

若Redis的數據沒有持久化，數據會丟失

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

這種方式還是要慎重！

memory purge手動碎片整理

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

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

開啟activedefrag自動碎片整理

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

127.0.0.1:6379> config set activedefrag yes

自動整理內存碎片，其原理是通過scan迭代整個Redis數據，通過一系列的內存復制、轉移操作完成內存碎片整理，由于此操作使用的是主線程，故會影響Redis對其他請求的響應。

如上圖碎片整理過程：

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

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

清理的條件

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

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

審核編輯：劉清