Redis內存回收策略

 

若是使用Redis的時候，不合理使用內存，把什麼東西都放在內存裏面，又不設置過時時間，就會致使內存的堆積愈來愈大。根據28法則，除了20%的熱點數據以外，剩餘的80%的非熱點或不怎麼重要的數據都在佔用內存空間，這時就要使用一種淘汰策略來釋放一些內存。Redis中提供了多種內存回收策略，當內存容量不足時，爲了保證程序的運行，這時就不得不淘汰內存中的一些對 象，釋放這些對象佔用的空間，那麼選擇淘汰哪些對象呢？
在redis.conf 裏面有個配置策略 maxmemory-policy ，它有幾個可選值：

noeviction： 默認的策略，即當內存使用達到閾值的時候，全部引發申請內存的命令都會報錯；
allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰 。
適用場景： 若是咱們的應用對緩存的訪問都是相對熱點數據，就能夠選擇這個策略；
allkeys-random：隨機移除某個key。
適合的場景：若是咱們的應用對於緩存key的訪問機率相等，則可使用這個策略。

從已經設置了過時時間的key中去選擇
volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰。
volatile-lru：從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰。
volatile-ttl：從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰；適合場景：這種策略使咱們能夠向Redis提示哪些key更適合被淘汰，能夠本身控制 。

那麼怎樣保證Redis裏面的數據都是熱點數據？
可使用LRU的淘汰策略，選擇最近最少使用的數據所有淘汰掉，剩下的就是常常訪問的數據，都是熱點數據。

總結
實際上Redis實現的LRU並非可靠的LRU，也就是名義上咱們使用LRU算法淘汰內存數據，可是實際上被淘汰的鍵 並不必定是真正的最少使用的數據，這裏就要權衡了，若是須要在全部的數據中搜索符合條件的數 據，那麼必定會增長系統的開銷，Redis是單線程的，因此耗時的操做會謹慎一些。爲了在必定成本內實現相對的 LRU，早期的Redis版本是基於採樣的LRU，也就是放棄了從全部數據中搜索解，改成採樣空間搜索優解。Redis3.0 版本以後，Redis做者對於基於採樣的LRU進行了一些優化，目的是在必定的成本範圍內讓結果更靠近真實的LRU。