在我們探究和優(yōu)化Redis性能的過程中，「Redis內存碎片」是一個不可忽視的話題。

這篇文章將深入研究這個看似微不足道，但實際上對Redis運行效率產生重要影響的問題。首先，讓我們揭開Redis內存碎片的神秘面紗，理解它的本質及其為何成為我們必須面對的挑戰(zhàn)。

內存碎片如何產生的

Redis內存碎片主要是因為Redis數(shù)據(jù)存儲和回收過程中的內存管理問題導致的。

Redis分配內存時，會根據(jù)需要申請一段連續(xù)的內存空間。但當Redis刪除或修改數(shù)據(jù)時，釋放的內存空間并不一定能被立即重新利用，尤其是當這些空閑內存空間大小不一致時，就可能導致內存碎片的出現(xiàn)。

為了提高內存使用的效率，Redis內部使用內存分配器來對內存的申請和釋放進行管理。Redis使用的內存分配器默認是「jemalloc」。

而內存分配器是按照固定大小來分配內存的，并不是完全按照程序申請的內存大小來進行分配。

比如程序申請一個20字節(jié)的內存，內存分配器會分配一個32字節(jié)的內存空間，這么做是為了減少分配次數(shù)。redis會申請不同大小的內存空間來存儲不同業(yè)務不同類型的數(shù)據(jù)，由于內存按照固定大小分配且會比實際申請的內存要大一些，這個過程中會產生內存碎片。

舉個生活中的例子，幫助大家理解：

假設你正在整理一間圖書館。圖書館的書架就像是Redis儲存數(shù)據(jù)的內存空間。每本書都代表不同大小的數(shù)據(jù)。剛開始時，你把所有的書都按照大小放好。小書在一側，大書在另一側。這樣你可以有效地利用書架的空間，也方便找書。

但是，如果你需要移除一些書（刪除某些數(shù)據(jù)），然后又加入新的書（新增數(shù)據(jù)），就可能出現(xiàn)問題了。例如，你移除了一些大書，把它們的位置空出來，然后把新的小書放進去。這樣下來，原本屬于大書的空間，現(xiàn)在只被小書部分占用，剩余的空白就成了“內存碎片”。

又或者你有一堆新的大書要放，但書架上只有分散的小書的空位，無法容納這些大書。這個時候你可能需要重新排列整個書架（類似于Redis的內存整理）去騰出連續(xù)的大片空間來擺放這些新的大書。

總結來說：當數(shù)據(jù)不斷刪除和新增時，內存中空出的位置可能無法完全匹配新數(shù)據(jù)的大小，導致產生未被利用的“碎片”空間，這就是內存碎片。

內存分配器

Redis 使用內存分配器來管理其在運行期間需要使用的內存資源?？梢允莑ibc、jemalloc、tcmalloc。默認是jemalloc。

要指定 Redis 使用哪個內存分配器，你需要在編譯 Redis 時做出選擇。通常在執(zhí)行 make 命令時可以通過 MALLOC 參數(shù)來指定。例如，如果你想使用 jemalloc，你可以像這樣編譯 Redis：make MALLOC=jemalloc。

jemalloc在64位系統(tǒng)中，將內存空間劃分為小、大、巨大三個范圍。每個范圍內又劃分了許多小的內存塊單位，存儲數(shù)據(jù)的時候，會選擇大小最合適的內存塊進行存儲。

jemalloc劃分的內存單元如下圖所示：

也就是說Redis是以指定大小的塊為單位進行連續(xù)內存分配的，而不是按需分配的，Redis 會根據(jù)申請的內存最接近的固定值分配相應大小的空間。

這就像你有不同的箱子，為了裝東西，你需要找一個體積最接近的箱子來裝。但是裝進去后，你發(fā)現(xiàn)還有空間可以放一些小東西，就無需再找箱子了。

但是，這種分配空間的方式會帶來一定程度的內存碎片。我們可以把固定大小的劃分空間看成不同體積的箱子，每種箱子里的空間不同程度上都會有剩余。這些剩余的空間就是內存碎片。

怎么看是否有內存碎片

我們登陸到Redis服務器上，執(zhí)行以下命令，這會返回一段描述Redis內存使用情況的文本。

redis> info memory

我們會看到類似如下的信息：

在這里，我們主要關注的是名為mem_fragmentation_ratio的字段，它顯示了Redis內存碎片的比例。

如果mem_fragmentation_ratio大于1，那就表示存在內存碎片。這個值越大，內存碎片就越多。如果該值非常接近1或者小于1，則表示內存碎片很少或者沒有。

計算公式為：

mem_fragmentation_ratio = used_memory_rss / used_memory

其中：

• used_memory_rss：代表Redis進程占用的總物理內存大小（包括碼區(qū)、數(shù)據(jù)區(qū)和堆棧等），單位是字節(jié)。
• used_memory：代表Redis分配器申請的內存總量，也就是從操作系統(tǒng)角度看進程實際使用的虛擬內存空間，單位是字節(jié)。

碎片率的意義

mem_fragmentation_ratio的不同值，說明不同的情況。

• 大于1：說明內存有碎片，通常在1到1.5之間是正常的。
• 大于1.5：說明內存碎片率比較大，需要考慮是否要進行內存碎片清理，要引起重視。
• 小于1：說明已經(jīng)開始使用交換內存，也就是使用硬盤了，正常的內存不夠用了，需要考慮是否要進行內存的擴容，使用swap是相當影響性能的。

清理內存碎片

1.低于4.0-RC3版本的Redis

Redis 4.0-RC3之前的版本并沒有內置的內存碎片整理工具。如果你想要清理內存碎片，可以通過重啟的方式。

當Redis重新啟動時，它會通過RDB持久化功能將數(shù)據(jù)存儲到磁盤，然后再從磁盤加載數(shù)據(jù)到內存，這個過程可以有效地清理內存碎片。但這種方法會導致服務的臨時中斷。

2.高于4.0-RC3版本的Redis

Redis4.0-RC3版本開始，引入了active-defrag 特性?？梢栽诓恢貑⒌那闆r下，自動進行碎片清理。

開啟配置如下，此選項的默認值是關閉的，激活碎片整理可能會占據(jù)一些 CPU 時間。

redis> config set activedefrag yes 

注意：自動清理內存碎片的功能需要該Redis的內存分配器是jemalloc時才能啟用。

啟用后需要同時滿足下面2個參數(shù)的設置條件時才會觸發(fā)自動清理：

active-defrag-ignore-bytes 100mb    # 默認100MB,表示內存碎片空間達到100MB時
active-defrag-threshold-lower 10    # 默認10，表示內存碎片空間占OS分配給redis的物理內存空間的比例達到10%時

redis是單進程模型，內存碎片自動清理是通過主線程操作的，也會消耗一定的CPU資源。為了避免自動清理降低Redis的處理性能，如下兩個參數(shù)可以控制清理動作消耗的CPU時間比例的上下限：

active-defrag-cycle-min 5  # 默認5，表示自動清理過程所用 CPU 時間的比例不低于5%，保證清理能正常開展；
active-defrag-cycle-max 75 # 默認75，表示自動清理過程所用 CPU 時間的比例不高于 75%，一旦超過，就停止清理，從而避免在清理時，大量的內存拷貝阻塞 Redis，導致響應延遲升高。

如果你對自動清理的效果不滿意，可以使用如下命令，直接進行手動碎片清理：

redis > memory purge

需要注意的是，該命令會阻塞主進程，并且目前也僅實現(xiàn)了jemalloc作為內存分配器的內存統(tǒng)計，對其他分配器暫不支持。

本篇文章到這就結束了。在我們深入研究Redis內存碎片管理和優(yōu)化策略后，可以明確一點：理解并合理處理內存碎片化對于保證Redis的性能及穩(wěn)定性至關重要。

不論是進行內存分配策略的調整，還是使用適當?shù)臄?shù)據(jù)結構，都是對Redis內存管理的優(yōu)化。

同時，定期的監(jiān)控和審視也是必不可少的步驟。希望本文能為你在處理Redis內存碎片問題上提供一些有價值的啟示。記住，每一個優(yōu)秀的工程師都應該以理解其使用的工具為榮。讓我們持續(xù)關注和優(yōu)化Redis，使其更好地服務于我們的項目，推動業(yè)務的發(fā)展。