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

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

這里先說答案

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

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

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

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

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

Redis內存消耗組成

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

自身進程占用內存

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

數據對象內存

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

緩沖區

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

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

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

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

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

內存碎片

內存碎片主要是有兩個原因：操作系統的內存分配機制、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  // 操作系統角度，進程占用的物理總內存
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    // 能使用的最大內存值，字節為單位。
maxmemory_human:2.00G  // 可讀形式
maxmemory_policy:noeviction // 內存淘汰策略


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

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

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

內存為何沒釋放

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

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

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

ok！我們繼續看看什么是內存碎片

內存碎片

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

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

但這種分配方式也有優勢，可以減少向操作系統申請空間分配。

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

內存分配機制導致

數據修改引發空間擴容和釋放

內存分配機制導致

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

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

上圖中：

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

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

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

數據修改引發空間擴容和釋放

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

如下圖：

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

此時D釋放了一個字節空間

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

C修改后刪除了2個字節空間

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

處理內存碎片

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

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

有下面三種方式可處理 ：

重啟Redis實例

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

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

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

這種方式還是要慎重！

memory purge手動碎片整理

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

memory purge 和 activedefrag回收的并不是同一塊區域的內存，它簡單粗暴的嘗試清除臟頁以便內存分配器回收。可以根據實際情況和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字節的內存碎片

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

清理的條件

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

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

審核編輯：劉清