Redis記憶體碎片產生原因及Pipeline管道原理解析

記憶體碎片

記憶體碎片如何產生的？

Redis內部有自己的記憶體分配器，預設是jemalloc，為了提高記憶體使用的效率，來對記憶體的申請和釋放進行管理。 而記憶體分配器按照固定大小分配記憶體，並不是完全按照程式申請的記憶體大小來進行分配。 比如程式申請一個20位元組的記憶體，記憶體分配器會分配一個32位元組的記憶體空間，這麼做是為了減少分配次數。redis會申請不同大小的記憶體空間來儲存不同業務不同型別的資料，由於記憶體按照固定大小分配且會比實際申請的記憶體要大一些，這個過程中會產生記憶體碎片。 舉個例子： 我們用高鐵車廂說明，假設一個車廂的座位總共有60個，現在已經賣 了57張票，需要三張連在一起的票，但發現買不到了，只好換一趟車。我們可以把這些分散的空座位叫作車廂座位碎片。

記憶體碎片類似上面高鐵座位的例子。雖然作業系統的剩餘空間總量足夠，但申請一塊連續地址空間N位元組時，剩餘記憶體空間中沒有大小為N位元組的連續空間，那麼這些剩餘空間就是記憶體碎片。

Redis的這種機制，提高了記憶體的使用率，但是會使Redis中有部分自己沒在用，卻不釋放的記憶體，導致了記憶體碎片的發生。

記憶體分配器

在編譯時指定的Redis使用的記憶體分配器，可以是libc、jemalloc、tcmalloc，預設是jemalloc。

jemalloc在64位元系統中，將記憶體空間劃分為小、大、巨大三個範圍；每個範圍內又劃分了許多小的記憶體塊單位；儲存資料的時候，會選擇大小最合適的記憶體塊進行儲存。

jemalloc劃分的記憶體單元如下圖所示：

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

這就像你有不同的箱子，為了裝東西，你需要找一個體積最接近的箱子來裝。但是裝進去後，你發現還有空間可以放一些小東西，就無需再找箱子了。但是，這種分配空間的方式會帶來一定程度的記憶體碎片。我們可以把固定大小的劃分空間看成不同體積的箱子，每種箱子裡的空間不同程度上都會有剩餘。這些剩餘的空間就是記憶體碎片。

怎麼看是否有記憶體碎片？

我們登陸到Redis伺服器上，執行以下命令：

redis> info memory

我們會看到這些資訊：

指標mem_fragmentation_ratio:1.86 表示當前的記憶體碎片率。

mem_fragmentation_ratio = used_memory_rss / used_memory

used_memory_rss：是Redis向作業系統申請的記憶體。 used_memory：是Redis中的資料佔用的記憶體。

所以，mem_fragmentation_ratio=1應該是最理想的情況

碎片率的意義？

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

• 大於1：說明記憶體有碎片，一般在1到1.5之間是正常的。
• 大於1.5：說明記憶體碎片率比較大，需要考慮是否要進行記憶體碎片清理，要引起重視。
• 小於1：說明已經開始使用交換記憶體，也就是使用硬碟了，正常的記憶體不夠用了，需要考慮是否要進行記憶體的擴容，使用swap是相當影響效能的。

清理記憶體碎片

低於4.0-RC3版本的Redis

如果你的Redis版本是4.0-RC3以下的，Redis伺服器重啟後，Redis會將沒用的記憶體歸還給作業系統，碎片率會降下來。

高於4.0-RC3版本的Redis

Redis4.0-RC3版本開始，可以在不重啟的情況下，線上整理記憶體碎片。 自動碎片清理，只要設定了如下的設定，記憶體就會自動清理了。

redis> config set activedefrag yes 

自動清理記憶體碎片的功能需要該Redis的記憶體分配器是jemalloc時才能啟用。

啟用後需要同時滿足下面2個引數的設定條件時才會觸發自動清理

active-defrag-ignore-bytes 100mb    # 預設100MB,表示記憶體碎片空間達到100MB時
active-defrag-threshold-lower 10    # 預設10，表示記憶體碎片空間佔OS分配給redis的實體記憶體空間的比例達到10%時

redis是單程序模型，記憶體碎片自動清理是通過主執行緒操作的，也會消耗一定的CPU資源。為了避免自動清理降低Redis的處理效能，如下兩個引數可以控制清理動作消耗的CPU時間比例的上下限。

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

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

redis > memory purge

需要注意的是，該清理命令也只當Redis的記憶體分配器是jemalloc時才能生效

#碎片整理總開關
activedefrag yes
 
#當碎片達到 100mb 時，開啟記憶體碎片整理
active-defrag-ignore-bytes 100mb
 
#當碎片超過 10% 時，開啟記憶體碎片整理
active-defrag-threshold-lower 10
 
#記憶體碎片超過 100%，則盡最大努力整理
active-defrag-threshold-upper 100
 
#記憶體自動整理佔用資源最小百分比
active-defrag-cycle-min 5
 
#記憶體自動整理佔用資源最大百分比
active-defrag-cycle-max 50

Pipeline管道

為什麼需要Pipeline

Redis使用者端執行一條命令分4個過程：

傳送命令－〉命令排隊－〉命令執行－〉返回結果

這個過程稱為 Round Trip Time(簡稱RTT, 往返時間) ，mget mset有效節約了RTT，但大部分命令（如hgetall，並沒有mhgetall）不支援批次操作，需要消耗N次RTT ，這個時候需要Pipeline來解決這個問題

Pipeline 模式則是將執行的命令寫入到緩衝中，最後由exec命令一次性傳送給Redis執行返回。

1、未使用Pipeline執行N條命令

2、使用了Pipeline執行N條命令

原生批命令(mset, mget)與Pipeline對比

• 原生批命令是原子性，Pipeline是非原子性
• 原生批命令一命令多個key, 但Pipeline支援多命令，Pipeline 不支援事務，因為命令是一條一條執行的。
• 原生批命令是伺服器端實現，而Pipeline需要伺服器端與使用者端共同完成

Pipeline的優缺點

• pipeline 每批打包的命令不能過多，因為 Pipeline 方式打包命令再傳送，那麼 Redis 必須在處理完所有命令前先快取起所有命令的處理結果。這樣就有一個記憶體的消耗。
• Pipeline 操作是非原子性的，如果要求原子性的，不推薦使用 Pipeline
• 使用Pipeline組裝的命令個數不能太多，不然資料量過大，增加使用者端的等待時間，還可能造成網路阻塞，可以將大量命令的拆分多個小的pipeline命令完成。

一些疑問

Pipeline 執行多少命令合適？

根據官方的解釋，推薦是以 10k 每批 (注意：這個是一個參考值，請根據自身實際業務情況調整)。

Pipeline 批次執行的時候，是否對Redis進行了鎖定，導致其他應用無法再進行讀寫？

Redis 採用多路I/O複用模型，非阻塞IO，所以Pipeline批次寫入的時候，一定範圍內不影響其他的讀操作。

在編碼時請注意，Pipeline 期間將“獨佔”連結，此期間將不能進行非“管道”型別的其他操作，直到 Pipeline 關閉；如果你的 Pipeline 的指令集很龐大，為了不干擾連結中的其他操作，你可以為 Pipeline 操作新建 Client 連結，讓 Pipeline 和其他正常操作分離在2個 client 中。

相關程式碼

    @Test
    void pipeline() {
        List<Object> result = redisTemplate.executePipelined((RedisCallback<String>) connection -> {
            for (int i = 0; i < 100; i++) {
                redisTemplate.opsForValue().set("pipel:" + i, i);
            }
            return null;
        });
    }

以上就是Redis記憶體碎片產生原因及Pipeline管道原理解析的詳細內容，更多關於Redis記憶體碎片Pipeline管道的資料請關注it145.com其它相關文章！