作為內(nèi)存數(shù)據(jù)庫，內(nèi)存空間大小對于 Redis 來說是至關重要的。內(nèi)存越多，意味著存儲的數(shù)據(jù)也會越多。但是不知道你有沒有遇到過這樣的情況，明明空間很大，但是內(nèi)存的使用卻不是很理想。

為什么會出現(xiàn)這樣的情況呢?這期我們就來看看這個"詭異"的事件。

坐好了，準備發(fā)車!

- 思維導圖 -

查看內(nèi)存使用情況

首先想要知道 Redis 內(nèi)存的使用情況，我們就需要獲取相關的信息。

Redis 中查看內(nèi)存相關信息是很簡單的，只需要在命令行輸入『info memory』就可以看到各種相關數(shù)據(jù)。在這里我羅列了一些較為重要的參數(shù)：

• used_memory：已經(jīng)使用了的內(nèi)存大小。
• used_memory_rss：redis 物理內(nèi)存的大小。
• mem_fragmentation_ratio：內(nèi)存碎片率。

這里有一個內(nèi)存碎片率的名詞需要關注下，它可以用來表示當前的內(nèi)存使用情況。

具體計算方式：

對于內(nèi)存碎片率，一般保持在 1~1.5 之間是最合理的。

什么是內(nèi)存碎片

了解了內(nèi)存碎片率，那什么是內(nèi)存碎片呢?

定義是這樣的：由于一塊連續(xù)空閑的空間比所要申請的空間小，導致這塊空間不可用，對于內(nèi)存整體來說就是內(nèi)存碎片。

舉個例子：

假設有一塊 100MB 的連續(xù)空閑內(nèi)存空間，你每次都會從中申請一塊 30MB 的內(nèi)存。那么當你申請了 3 次后，這塊內(nèi)存就只剩下了 10MB 的空間，第 4 次申請的時候就會失敗。如果沒有其它的空間釋放并且每次申請的空間都比 10MB 大，那么剩下的空間對于整塊內(nèi)存來說就是內(nèi)存碎片。

內(nèi)存碎片導致的原因

Redis 中，最常用的是寫入、修改、刪除數(shù)據(jù)。這些操作在執(zhí)行后都會產(chǎn)生 一定程度的內(nèi)存碎片。

寫入數(shù)據(jù)

Redis 中分配內(nèi)存是根據(jù)固定的大小來劃分內(nèi)存空間的。為了減少分配次數(shù)，Redis 會根據(jù)申請的內(nèi)存最接近的固定值分配相應大小的空間。

什么意思呢，假如 Redis 按照 8 字節(jié)、16 字節(jié)、32 字節(jié)、48 字節(jié)等來分配內(nèi)存。當你想要存儲一個 18 字節(jié)的數(shù)據(jù)時，此時 Redis 就會分配 32 字節(jié)(因為 32 是與 18 最接近的固定值)。如果這時候，再寫入的數(shù)據(jù)需要的內(nèi)存空間在 14 個字節(jié)內(nèi)，那 Redis 就無需再進行分配了。

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

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

修改數(shù)據(jù)

鍵值對進行修改時，可能會變大也會變小，相應的就會占用額外空間或者釋放不用的空間。

如圖中所示，當前 A、B、C 分別占用了 3、2、4 個字節(jié)，將 A 從 3 字節(jié)修改為 2 字節(jié)時，此時就會有 1 個字節(jié)的空間空了出來，這時就會出現(xiàn) 1 個字節(jié)的碎片。

那如果我將數(shù)據(jù) A 從 3 字節(jié)修改為 4 字節(jié)呢?此時為了保持數(shù)據(jù) A 的空間連續(xù)性，操作系統(tǒng)會把 B 拷貝到別的空間。此時又會出現(xiàn) 1 個字節(jié)的碎片。

刪除數(shù)據(jù)

理解了修改數(shù)據(jù)，刪除數(shù)據(jù)就很容易明白了。還是上邊的例子，此時刪除了數(shù)據(jù) B，那么就釋放了 2 個字節(jié)的空間。這樣對于整個內(nèi)存空間來說就產(chǎn)生了 2 個字節(jié)的碎片。

如何解決內(nèi)存碎片

你可能會有疑問，內(nèi)存碎片會有什么危害呢?

我們還是以上邊的箱子來表示。你想想，如果你要把這些箱子都裝上車運走，每個箱子里都有空出來的空間(內(nèi)存碎片)，那么運行一次的效率及性價比是不是會很低。同樣，在 Redis 中，由于大量的碎片存在，會導致實際利用率變低。

那么我們有沒有辦法來解決內(nèi)存碎片呢?

推倒重來

第一種方式很簡單，直接推倒重來。也就是把 Redis 直接重啟完事兒，內(nèi)存一斷電全世界就清凈。但是這種暴力省事的方式卻有很多隱患。

生產(chǎn)環(huán)境中你這么搞的話得提前燒燒香，保佑不會出什么問題。如果你沒進行過持久化，那么就別燒了，燒了也沒用。如果有持久化的話，那么恢復時長還得取決你持久化文件的大小，在這個階段還無法提供服務。糟心不?

空間置換

那么有沒有不這么刺激的方式。

有的，高版本的 Redis 提供了內(nèi)存碎片清理的方式。一言以蔽之，就是空間置換。

怎么個置換法?我們的目的是為了消除內(nèi)存碎片，那么我們把已使用的內(nèi)存數(shù)據(jù)重新整理到一起不就行了嗎?讓不連續(xù)的空間變成連續(xù)的，剩下的空間，繼續(xù)來分配。

畫個圖理解下：

但是，說說還是挺容易的，理論到實踐中間還隔著性能損耗。

在進行多次數(shù)據(jù)拷貝過程中，單線程的 Redis 只能干等著，無法響應客戶端的請求。這時候只能干瞪眼，性能太受影響。

涼，那該咋整?!別急，有緩解的策略，你接著往下看。

Redis 中有專門的參數(shù)設置用來進行自動清理內(nèi)存碎片：activedefrag yes。

這個命令是啟動清理功能的，這還不夠，Redis 中還需要其他的條件限制才能夠進行清理。

下面參數(shù)都是滿足任一條件后就可以進行清理：

• active-defrag-ignore-bytes 100mb：

          碎片達到100MB時，開啟清理。

• active-defrag-threshold-lower 10：

          當碎片超過 10% 時，開啟清理。

• active-defrag-threshold-upper 100：

          內(nèi)存碎片超過 100%，盡最大清理。

在處理的過程中，為了避免對正常請求的影響，同時又能保證性能。Redis 同時還提供了監(jiān)控 CPU 占用比例的參數(shù)，在滿足以下條件時才會保證清理正常開展：

• active-defrag-cycle-min 5：

          清理內(nèi)存碎片占用 CPU 時間的比例不低于此值，保證清理能正常開展。

• active-defrag-cycle-max 75：

          清理內(nèi)存碎片占用 CPU 時間的比例不高于此值。一旦超過則停止清理，從而避免在清理時，大量的內(nèi)存拷貝阻塞 Redis，導致其它請求延遲。

總結(jié)

查看內(nèi)存使用情況

• 在命令行執(zhí)行 info memory 即可查看 Redis 內(nèi)存相關信息。根據(jù)內(nèi)存碎片率可以在一定時機內(nèi)進行清理碎片清理。

內(nèi)存碎片導致原因

• 寫入數(shù)據(jù)時，Redis 為了減少分配次數(shù)在分配內(nèi)存是根據(jù)固定的大小來劃分內(nèi)存空間的。修改數(shù)據(jù)時會釋放或占用額外的內(nèi)存空間，刪除數(shù)據(jù)時會釋放空間。這樣就會產(chǎn)生不同程度的內(nèi)存碎片。

如何解決內(nèi)存碎片

• 通過重啟 Redis 的方式進行處理，如果沒有持久化可能會導致事故。在持久化情況下，恢復速度需要取決于文件的大小。
• 通過空間置換方式，也就是將已使用的內(nèi)存數(shù)據(jù)重新整理到一起。

 【編輯推薦】