Redis 記憶體淘汰機制

摘要

Redis是一款優秀的、開源的記憶體資料庫，我在閱讀Redis源碼實作的過程中，時時刻刻能感受到Redis作者為更好地使用記憶體而費盡各種心思，例如最明顯的是對于同一種資料結構在不同應用場景下提供了基于不同底層編碼的實作（如壓縮清單、跳躍表等）。今天我們暫時放下對Redis不同資料結構的探讨，來一起看看Redis提供的另一種機制——記憶體淘汰機制。

探初衷

Redis記憶體淘汰指的是使用者存儲的一些鍵被可以被Redis主動地從執行個體中删除，進而産生讀miss的情況，那麼Redis為什麼要有這種功能？這就是我們需要探究的設計初衷。Redis最常見的兩種應用場景為緩存和持久存儲，首先要明确的一個問題是記憶體淘汰政策更适合于那種場景？是持久存儲還是緩存？這個問題很顯然的我就不回答了。

假設我們有一個Redis伺服器，伺服器實體記憶體大小為1G的，我們需要存在Redis中的資料量很小，這看起來似乎足夠用很長時間了，随着業務量的增長，我們放在Redis裡面的資料越來越多了，資料量大小似乎超過了1G，但是應用還可以正常運作，這是因為作業系統的可見記憶體并不受實體記憶體限制，而是虛拟記憶體，實體記憶體不夠用沒關系，作業系統會從硬碟上劃出一片空間用于建構虛拟記憶體，比如32位的作業系統的可見記憶體大小為

2^32

，而使用者空間的可見記憶體要小于

2^32

很多，大概是3G左右。好了，我們慶幸作業系統為我們做了這些，但是我們需要知道這背後的代價是不菲的，不合理的使用記憶體有可能發生頻繁的swap，頻繁swap的代價是慘痛的。是以回過頭來看，作為有追求的程式員，我們還是要小心翼翼地使用好每塊記憶體，把使用者代碼能解決的問題盡量不要抛給作業系統解決。

說到這裡，對于這個“初衷”我們似乎尋到了一個聽起來蠻有道理的解釋，記憶體的淘汰機制的初衷是為了更好地使用記憶體，用一定的緩存miss來換取記憶體的使用效率。

如何用

作為Redis使用者，我使用Redis提供的這個特性呢？看看下面配置

# maxmemory <bytes>
           

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

• 用戶端發起了需要申請更多記憶體的指令（如set）。
• Redis檢查記憶體使用情況，如果已使用的記憶體大于maxmemory則開始根據使用者配置的不同淘汰政策來淘汰記憶體（key），進而換取一定的記憶體。

• 如果上面都沒問題，則這個指令執行成功。

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

記憶體淘汰政策

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

Redis提供了下面幾種淘汰政策供使用者選擇，其中預設的政策為noeviction政策：

• noeviction：當記憶體使用達到門檻值的時候，所有引起申請記憶體的指令會報錯。
• allkeys-lru：在主鍵空間中，優先移除最近未使用的key。
• volatile-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。

總結

本文的内容主要還是問題驅動的，為介紹Redis記憶體淘汰機制，本文從問題出發，通過解決什麼是Redis記憶體淘汰機制？Redis記憶體淘汰機制應用場景是什麼？初衷是什麼？我們怎麼開啟這個功能？我們可配哪些淘汰政策？淘汰政策如何選擇？等問題來談Redis記憶體淘汰機制，希望本文能給大家帶來一定的收獲和啟發。

在計算機設計中，實際上任何事情都要涉及權衡。——《現代作業系統》

Redis 記憶體淘汰機制