別再問我Redis內(nèi)存滿了該怎么辦了
概述
Redis的文章，我之前寫過一篇關(guān)于「Redis的緩存的三大問題」，累計閱讀也快800了，對于還只有3k左右的粉絲量，能夠達到這個閱讀量，已經(jīng)是比較難了。
這說明那篇文章寫的還過得去，收到很多人的閱讀肯定，感興趣的看一下[看完這篇Redis緩存三大問題，保你能和面試官互扯。]。
「三大緩存問題」只是Redis的其中的一小部分的知識點，想要深入學習Redis還要學習比較多的知識點。
那么今天就帶來了一個面試常問的一個問題：「假如你的Redis內(nèi)存滿了怎么辦？」 長期的把Redis作為緩存使用，總有一天會存滿的時候?qū)Π伞?/p>
這個面試題不慌呀，在Redis中有配置參數(shù)maxmemory可以「設(shè)置Redis內(nèi)存的大小」。
在Redis的配置文件redis.conf文件中，配置maxmemory的大小參數(shù)如下所示：
實際生產(chǎn)中肯定不是100mb的大小哈，不要給誤導(dǎo)了，這里我只是讓大家認識這個參數(shù)，一般小的公司都是設(shè)置為3G左右的大小。
除了在配置文件中配置生效外，還可以通過命令行參數(shù)的形式，進行配置，具體的配置命令行如下所示：
//獲取maxmemory配置參數(shù)的大小
127.0.0.1:6379> config get maxmemory
//設(shè)置maxmemory參數(shù)為100mb
127.0.0.1:6379> config set maxmemory 100mb
倘若實際的存儲中超出了Redis的配置參數(shù)的大小時，Redis中有「淘汰策略」，把「需要淘汰的key給淘汰掉，整理出干凈的一塊內(nèi)存給新的key值使用」。
接下來我們就詳細的聊一聊Redis中的淘汰策略，并且深入的理解每個淘汰策略的原理和應(yīng)用的場景。
淘汰策略
Redis提供了「6種的淘汰策略」，其中默認的是noeviction，這6種淘汰策略如下：
-
noeviction( 「默認策略」)：若是內(nèi)存的大小達到閥值的時候，所有申請內(nèi)存的指令都會報錯。 -
allkeys-lru：所有key都是使用 「LRU算法」進行淘汰。 -
volatile-lru：所有 「設(shè)置了過期時間的key使用LRU算法」進行淘汰。 -
allkeys-random：所有的key使用 「隨機淘汰」的方式進行淘汰。 -
volatile-random：所有 「設(shè)置了過期時間的key使用隨機淘汰」的方式進行淘汰。 -
volatile-ttl：所有設(shè)置了過期時間的key 「根據(jù)過期時間進行淘汰，越早過期就越快被淘汰」。
假如在Redis中的數(shù)據(jù)有「一部分是熱點數(shù)據(jù)，而剩下的數(shù)據(jù)是冷門數(shù)據(jù)」，或者「我們不太清楚我們應(yīng)用的緩存訪問分布狀況」，這時可以使用allkeys-lru。
假如所有的數(shù)據(jù)訪問的頻率大概一樣，就可以使用allkeys-random的淘汰策略。
假如要配置具體的淘汰策略，可以在redis.conf配置文件中配置，具體配置如下所示：
這只需要把注釋給打開就可以，并且配置指定的策略方式，另一種的配置方式就是命令的方式進行配置，具體的執(zhí)行命令如下所示：
// 獲取maxmemory-policy配置
127.0.0.1:6379> config get maxmemory-policy
// 設(shè)置maxmemory-policy配置為allkeys-lru
127.0.0.1:6379> config set maxmemory-policy allkeys-lru
在介紹6種的淘汰策略方式的時候，說到了LRU算法，「那么什么是LRU算法呢？」
LRU算法
LRU(Least Recently Used)即表示最近最少使用，也就是在最近的時間內(nèi)最少被訪問的key，算法根據(jù)數(shù)據(jù)的歷史訪問記錄來進行淘汰數(shù)據(jù)。
它的核心的思想就是：「假如一個key值在最近很少被使用到，那么在將來也很少會被訪問」。
實際上Redis實現(xiàn)的LRU并不是真正的LRU算法，也就是名義上我們使用LRU算法淘汰鍵，但是實際上被淘汰的鍵并不一定是真正的最久沒用的。
Redis使用的是近似的LRU算法，「通過隨機采集法淘汰key，每次都會隨機選出5個key，然后淘汰里面最近最少使用的key」。
這里的5個key只是默認的個數(shù)，具體的個數(shù)也可以在配置文件中進行配置，在配置文件中的配置如下圖所示：
當近似LRU算法取值越大的時候就會越接近真實的LRU算法，可以這樣理解，因為「取值越大那么獲取的數(shù)據(jù)就越全，淘汰中的數(shù)據(jù)的就越接近最近最少使用的數(shù)據(jù)」。
那么為了實現(xiàn)根據(jù)時間實現(xiàn)LRU算法，Redis必須為每個key中額外的增加一個內(nèi)存空間用于存儲每個key的時間，大小是3字節(jié)。
在Redis 3.0中對近似的LRU算法做了一些優(yōu)化，Redis中會維護大小是16的一個候選池的內(nèi)存。
當?shù)谝淮坞S機選取的采樣數(shù)據(jù)，數(shù)據(jù)都會被放進候選池中，并且候選池中的數(shù)據(jù)會根據(jù)時間進行排序。
當?shù)诙我院筮x取的數(shù)據(jù)，只有「小于候選池內(nèi)的最小時間」的才會被放進候選池中。
當某一時刻候選池的數(shù)據(jù)滿了，那么時間最大的key就會被擠出候選池。當執(zhí)行淘汰時，直接從候選池中選取最近訪問時間最小的key進行淘汰。
這樣做的目的就是選取出最近似符合最近最少被訪問的key值，能夠正確的淘汰key值，因為隨機選取的樣本中的最小時間可能不是真正意義上的最小時間。
但是LRU算法有一個弊端：就是假如一個key值在以前都沒有被訪問到，然而最近一次被訪問到了，那么就會認為它是熱點數(shù)據(jù)，不會被淘汰。
然而有些數(shù)據(jù)以前經(jīng)常被訪問到，只是最近的時間內(nèi)沒有被訪問到，這樣就導(dǎo)致這些數(shù)據(jù)很可能被淘汰掉，這樣一來就會出現(xiàn)誤判而淘汰熱點數(shù)據(jù)。
于是在Redis 4.0的時候除了LRU算法，新加了一種LFU算法，「那么什么是LFU算法算法呢？」
LFU算法
LFU(Least Frequently Used)即表示最近頻繁被使用，也就是最近的時間段內(nèi)，頻繁被訪問的key，它以最近的時間段的被訪問次數(shù)的頻率作為一種判斷標準。
它的核心思想就是：根據(jù)key最近被訪問的頻率進行淘汰，比較少被訪問的key優(yōu)先淘汰，反之則優(yōu)先保留。
LFU算法反映了一個key的熱度情況，不會因為LRU算法的偶爾一次被訪問被認為是熱點數(shù)據(jù)。
在LFU算法中支持volatile-lfu策略和allkeys-lfu策略。
以上介紹了Redis的6種淘汰策略，這6種淘汰策略旨在告訴我們怎么做，但是什么時候做？這個還沒說，下面我們就來詳細的了解Redis什么時候執(zhí)行淘汰策略。
刪除過期鍵策略
在Redis中有三種刪除的操作此策略，分別是：
-
「定時刪除」：創(chuàng)建一個定時器，定時的執(zhí)行對key的刪除操作。 -
「惰性刪除」：每次只有再訪問key的時候，才會檢查key的過期時間，若是已經(jīng)過期了就執(zhí)行刪除。 -
「定期刪除」：每隔一段時間，就會檢查刪除掉過期的key。
「定時刪除」對于「內(nèi)存來說是友好的」，定時清理出干凈的空間，但是對于「cpu來說并不是友好的」，程序需要維護一個定時器，這就會占用cpu資源。
「惰性的刪除」對于「cpu來說是友好的」，cpu不需要維護其它額外的操作，但是對于「內(nèi)存來說是不友好的」，因為要是有些key一直沒有被訪問到，就會一直占用著內(nèi)存。
定期刪除是上面兩種方案的折中方案**，每隔一段時間刪除過期的key，也就是根據(jù)具體的業(yè)務(wù)，合理的取一個時間定期的刪除key**。
通過「最合理控制刪除的時間間隔」來刪除key，減「少對cpu的資源的占用消耗」，使刪除操作合理化。
RDB和AOF 的淘汰處理
在Redis中持久化的方式有兩種RDB和AOF，具體這兩種詳細的持久化介紹，可以參考這一篇文章[面試造飛機系列：面對Redis持久化連環(huán)Call，你還頂?shù)米幔?/a>]。
在RDB中是以快照的形式獲取內(nèi)存中某一時間點的數(shù)據(jù)副本，在創(chuàng)建RDB文件的時候可以通過save和bgsave命令執(zhí)行創(chuàng)建RDB文件。
「這兩個命令都不會把過期的key保存到RDB文件中」，這樣也能達到刪除過期key的效果。
當在啟動Redis載入RDB文件的時候，Master不會把過期的key載入，而Slave會把過期的key載入。
在AOF模式下，Redis提供了Rewite的優(yōu)化措施，執(zhí)行的命令分別是REWRITEAOF和BGREWRITEAOF，「這兩個命令都不會把過期的key寫入到AOF文件中，也能刪除過期key」。
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝
免責聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
