溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了Redis內存碎片產生原因及Pipeline管道原理是什么的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇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是相當影響性能的。
如果你的Redis版本是4.0-RC3以下的，Redis服務器重啟后，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
Redis客戶端執行一條命令分4個過程：
發送命令－〉命令排隊－〉命令執行－〉返回結果
這個過程稱為 Round Trip Time(簡稱RTT, 往返時間) ，mget mset有效節約了RTT，但大部分命令（如hgetall，并沒有mhgetall）不支持批量操作，需要消耗N次RTT ，這個時候需要Pipeline來解決這個問題
Pipeline 模式則是將執行的命令寫入到緩沖中，最后由exec命令一次性發送給Redis執行返回。
1、未使用Pipeline執行N條命令
2、使用了Pipeline執行N條命令
原生批命令是原子性，Pipeline是非原子性
原生批命令一命令多個key, 但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管道原理是什么”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
