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內存淘汰機制，但願本文能給你們帶來必定的收穫和啓發。