1. 程式人生 > >Redis 記憶體淘汰機制

Redis 記憶體淘汰機制

簡介

Redis記憶體淘汰指的是使用者儲存的一些鍵被可以被Redis主動地從例項中刪除,從而產生讀miss的情況,那麼Redis為什麼要有這種功能?這就是我們需要探究的設計初衷。Redis最常見的兩種應用場景為快取和持久儲存,首先要明確的一個問題是記憶體淘汰策略更適合於那種場景?是持久儲存還是快取?

假設我們有一個Redis伺服器,伺服器實體記憶體大小為1G的,我們需要存在Redis中的資料量很小,這看起來似乎足夠用很長時間了,隨著業務量的增長,我們放在Redis裡面的資料越來越多了,資料量大小似乎超過了1G,但是應用還可以正常執行,這是因為作業系統的可見記憶體並不受實體記憶體限制,而是虛擬記憶體,實體記憶體不夠用沒關係,作業系統會從硬碟上劃出一片空間用於構建虛擬記憶體,比如32位的作業系統的可見記憶體大小為2^32,而使用者空間的可見記憶體要小於2^32很多,大概是3G左右。好了,我們慶幸作業系統為我們做了這些,但是我們需要知道這背後的代價是不菲的,不合理的使用記憶體有可能發生頻繁的swap,頻繁swap的代價是慘痛的。

如何用

我們可以通過配置redis.conf中的maxmemory這個值來開啟記憶體淘汰功能,至於這個值有什麼意義,我們可以通過了解記憶體淘汰的過程來理解它的意義:

  1. 客戶端發起了需要申請更多記憶體的命令(如set)。
  2. Redis檢查記憶體使用情況,如果已使用的記憶體大於maxmemory則開始根據使用者配置的不同淘汰策略來淘汰記憶體(key),從而換取一定的記憶體。
  3. 如果上面都沒問題,則這個命令執行成功。
# maxmemory <bytes>

maxmemory為0的時候表示我們對Redis的記憶體使用沒有限制。

記憶體淘汰策略

記憶體淘汰只是Redis提供的一個功能,為了更好地實現這個功能,必須為不同的應用場景提供不同的策略,記憶體淘汰策略講的是為實現記憶體淘汰我們具體怎麼做,要解決的問題包括淘汰鍵空間如何選擇?在鍵空間中淘汰鍵如何選擇?

Redis提供了下面幾種淘汰策略供使用者選擇,其中預設的策略為noeviction策略:

  • noeviction:當記憶體使用達到閾值的時候,所有引起申請記憶體的命令會報錯。
  • allkeys-lru:在主鍵空間中,優先移除最近未使用的key。
  • allkeys-random:在主鍵空間中,隨機移除某個key。
  • volatile-random:在設定了過期時間的鍵空間中,隨機移除某個key。
  • volatile-ttl:在設定了過期時間的鍵空間中,具有更早過期時間的key優先移除。

這裡補充一下主鍵空間和設定了過期時間的鍵空間,舉個例子,假設我們有一批鍵儲存在Redis中,則有那麼一個雜湊表用於儲存這批鍵及其值,如果這批鍵中有一部分設定了過期時間,那麼這批鍵還會被儲存到另外一個雜湊表中,這個雜湊表中的值對應的是鍵被設定的過期時間。設定了過期時間的鍵空間為主鍵空間的子集。

如何選擇淘汰策略

我們瞭解了Redis大概提供了這麼幾種淘汰策略,那麼如何選擇呢?淘汰策略的選擇可以通過下面的配置指定:

# maxmemory-policy noeviction

但是這個值填什麼呢?為解決這個問題,我們需要了解我們的應用請求對於Redis中儲存的資料集的訪問方式以及我們的訴求是什麼。同時Redis也支援Runtime修改淘汰策略,這使得我們不需要重啟Redis例項而實時的調整記憶體淘汰策略。

下面看看幾種策略的適用場景:

  • allkeys-lru:如果我們的應用對快取的訪問符合冪律分佈(也就是存在相對熱點資料),或者我們不太清楚我們應用的快取訪問分佈狀況,我們可以選擇allkeys-lru策略。
  • allkeys-random:如果我們的應用對於快取key的訪問概率相等,則可以使用這個策略。
  • volatile-ttl:這種策略使得我們可以向Redis提示哪些key更適合被eviction。

另外,volatile-lru策略和volatile-random策略適合我們將一個Redis例項既應用於快取和又應用於持久化儲存的時候,然而我們也可以通過使用兩個Redis例項來達到相同的效果,值得一提的是將key設定過期時間實際上會消耗更多的記憶體,因此我們建議使用allkeys-lru策略從而更有效率的使用記憶體。

非精準的LRU

上面提到的LRU(Least Recently Used)策略,實際上Redis實現的LRU並不是可靠的LRU,也就是名義上我們使用LRU演算法淘汰鍵,但是實際上被淘汰的鍵並不一定是真正的最久沒用的,這裡涉及到一個權衡的問題,如果需要在全部鍵空間內搜尋最優解,則必然會增加系統的開銷,Redis是單執行緒的,也就是同一個例項在每一個時刻只能服務於一個客戶端,所以耗時的操作一定要謹慎。為了在一定成本內實現相對的LRU,早期的Redis版本是基於取樣的LRU,也就是放棄全部鍵空間內搜尋解改為取樣空間搜尋最優解。自從Redis3.0版本之後,Redis作者對於基於取樣的LRU進行了一些優化,目的是在一定的成本內讓結果更靠近真實的LRU。