別再問(wèn)我Redis內(nèi)存滿了該怎么辦了

概述

Redis的文章，我之前寫過(guò)一篇關(guān)于「Redis的緩存的三大問(wèn)題」，累計(jì)閱讀也快800了，對(duì)于還只有3k左右的粉絲量，能夠達(dá)到這個(gè)閱讀量，已經(jīng)是比較難了。

這說(shuō)明那篇文章寫的還過(guò)得去，收到很多人的閱讀肯定，感興趣的看一下[看完這篇Redis緩存三大問(wèn)題，保你能和面試官互扯。]。

「三大緩存問(wèn)題」只是Redis的其中的一小部分的知識(shí)點(diǎn)，想要深入學(xué)習(xí)Redis還要學(xué)習(xí)比較多的知識(shí)點(diǎn)。

那么今天就帶來(lái)了一個(gè)面試常問(wèn)的一個(gè)問(wèn)題：「假如你的Redis內(nèi)存滿了怎么辦？」 長(zhǎng)期的把Redis作為緩存使用，總有一天會(huì)存滿的時(shí)候?qū)Π伞?/p>

這個(gè)面試題不慌呀，在Redis中有配置參數(shù)maxmemory可以「設(shè)置Redis內(nèi)存的大小」。

在Redis的配置文件redis.conf文件中，配置maxmemory的大小參數(shù)如下所示：

實(shí)際生產(chǎn)中肯定不是100mb的大小哈，不要給誤導(dǎo)了，這里我只是讓大家認(rèn)識(shí)這個(gè)參數(shù)，一般小的公司都是設(shè)置為3G左右的大小。

除了在配置文件中配置生效外，還可以通過(guò)命令行參數(shù)的形式，進(jìn)行配置，具體的配置命令行如下所示：

//獲取maxmemory配置參數(shù)的大小
127.0.0.1:6379> config get maxmemory
//設(shè)置maxmemory參數(shù)為100mb
127.0.0.1:6379> config set maxmemory 100mb

倘若實(shí)際的存儲(chǔ)中超出了Redis的配置參數(shù)的大小時(shí)，Redis中有「淘汰策略」，把「需要淘汰的key給淘汰掉，整理出干凈的一塊內(nèi)存給新的key值使用」。

接下來(lái)我們就詳細(xì)的聊一聊Redis中的淘汰策略，并且深入的理解每個(gè)淘汰策略的原理和應(yīng)用的場(chǎng)景。

淘汰策略

Redis提供了「6種的淘汰策略」，其中默認(rèn)的是noeviction，這6種淘汰策略如下：

1. noeviction( 「默認(rèn)策略」)：若是內(nèi)存的大小達(dá)到閥值的時(shí)候，所有申請(qǐng)內(nèi)存的指令都會(huì)報(bào)錯(cuò)。
2. allkeys-lru：所有key都是使用 「LRU算法」進(jìn)行淘汰。
3. volatile-lru：所有 「設(shè)置了過(guò)期時(shí)間的key使用LRU算法」進(jìn)行淘汰。
4. allkeys-random：所有的key使用 「隨機(jī)淘汰」的方式進(jìn)行淘汰。
5. volatile-random：所有 「設(shè)置了過(guò)期時(shí)間的key使用隨機(jī)淘汰」的方式進(jìn)行淘汰。
6. volatile-ttl：所有設(shè)置了過(guò)期時(shí)間的key 「根據(jù)過(guò)期時(shí)間進(jìn)行淘汰，越早過(guò)期就越快被淘汰」。

假如在Redis中的數(shù)據(jù)有「一部分是熱點(diǎn)數(shù)據(jù)，而剩下的數(shù)據(jù)是冷門數(shù)據(jù)」，或者「我們不太清楚我們應(yīng)用的緩存訪問(wèn)分布狀況」，這時(shí)可以使用allkeys-lru。

假如所有的數(shù)據(jù)訪問(wèn)的頻率大概一樣，就可以使用allkeys-random的淘汰策略。

假如要配置具體的淘汰策略，可以在redis.conf配置文件中配置，具體配置如下所示：

這只需要把注釋給打開(kāi)就可以，并且配置指定的策略方式，另一種的配置方式就是命令的方式進(jìn)行配置，具體的執(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種的淘汰策略方式的時(shí)候，說(shuō)到了LRU算法，「那么什么是LRU算法呢？」

LRU算法

LRU(Least Recently Used)即表示最近最少使用，也就是在最近的時(shí)間內(nèi)最少被訪問(wèn)的key，算法根據(jù)數(shù)據(jù)的歷史訪問(wèn)記錄來(lái)進(jìn)行淘汰數(shù)據(jù)。

它的核心的思想就是：「假如一個(gè)key值在最近很少被使用到，那么在將來(lái)也很少會(huì)被訪問(wèn)」。

實(shí)際上Redis實(shí)現(xiàn)的LRU并不是真正的LRU算法，也就是名義上我們使用LRU算法淘汰鍵，但是實(shí)際上被淘汰的鍵并不一定是真正的最久沒(méi)用的。

Redis使用的是近似的LRU算法，「通過(guò)隨機(jī)采集法淘汰key，每次都會(huì)隨機(jī)選出5個(gè)key，然后淘汰里面最近最少使用的key」。

這里的5個(gè)key只是默認(rèn)的個(gè)數(shù)，具體的個(gè)數(shù)也可以在配置文件中進(jìn)行配置，在配置文件中的配置如下圖所示：

當(dāng)近似LRU算法取值越大的時(shí)候就會(huì)越接近真實(shí)的LRU算法，可以這樣理解，因?yàn)?strong style="color: rgb(53, 148, 247);">「取值越大那么獲取的數(shù)據(jù)就越全，淘汰中的數(shù)據(jù)的就越接近最近最少使用的數(shù)據(jù)」。

那么為了實(shí)現(xiàn)根據(jù)時(shí)間實(shí)現(xiàn)LRU算法，Redis必須為每個(gè)key中額外的增加一個(gè)內(nèi)存空間用于存儲(chǔ)每個(gè)key的時(shí)間，大小是3字節(jié)。

在Redis 3.0中對(duì)近似的LRU算法做了一些優(yōu)化，Redis中會(huì)維護(hù)大小是16的一個(gè)候選池的內(nèi)存。

當(dāng)?shù)谝淮坞S機(jī)選取的采樣數(shù)據(jù)，數(shù)據(jù)都會(huì)被放進(jìn)候選池中，并且候選池中的數(shù)據(jù)會(huì)根據(jù)時(shí)間進(jìn)行排序。

當(dāng)?shù)诙我院筮x取的數(shù)據(jù)，只有「小于候選池內(nèi)的最小時(shí)間」的才會(huì)被放進(jìn)候選池中。

當(dāng)某一時(shí)刻候選池的數(shù)據(jù)滿了，那么時(shí)間最大的key就會(huì)被擠出候選池。當(dāng)執(zhí)行淘汰時(shí)，直接從候選池中選取最近訪問(wèn)時(shí)間最小的key進(jìn)行淘汰。

這樣做的目的就是選取出最近似符合最近最少被訪問(wèn)的key值，能夠正確的淘汰key值，因?yàn)殡S機(jī)選取的樣本中的最小時(shí)間可能不是真正意義上的最小時(shí)間。

但是LRU算法有一個(gè)弊端：就是假如一個(gè)key值在以前都沒(méi)有被訪問(wèn)到，然而最近一次被訪問(wèn)到了，那么就會(huì)認(rèn)為它是熱點(diǎn)數(shù)據(jù)，不會(huì)被淘汰。

然而有些數(shù)據(jù)以前經(jīng)常被訪問(wèn)到，只是最近的時(shí)間內(nèi)沒(méi)有被訪問(wèn)到，這樣就導(dǎo)致這些數(shù)據(jù)很可能被淘汰掉，這樣一來(lái)就會(huì)出現(xiàn)誤判而淘汰熱點(diǎn)數(shù)據(jù)。

于是在Redis 4.0的時(shí)候除了LRU算法，新加了一種LFU算法，「那么什么是LFU算法算法呢？」

LFU算法

LFU(Least Frequently Used)即表示最近頻繁被使用，也就是最近的時(shí)間段內(nèi)，頻繁被訪問(wèn)的key，它以最近的時(shí)間段的被訪問(wèn)次數(shù)的頻率作為一種判斷標(biāo)準(zhǔn)。

它的核心思想就是：根據(jù)key最近被訪問(wèn)的頻率進(jìn)行淘汰，比較少被訪問(wèn)的key優(yōu)先淘汰，反之則優(yōu)先保留。

LFU算法反映了一個(gè)key的熱度情況，不會(huì)因?yàn)長(zhǎng)RU算法的偶爾一次被訪問(wèn)被認(rèn)為是熱點(diǎn)數(shù)據(jù)。

在LFU算法中支持volatile-lfu策略和allkeys-lfu策略。

以上介紹了Redis的6種淘汰策略，這6種淘汰策略旨在告訴我們?cè)趺醋觯鞘裁磿r(shí)候做？這個(gè)還沒(méi)說(shuō)，下面我們就來(lái)詳細(xì)的了解Redis什么時(shí)候執(zhí)行淘汰策略。

刪除過(guò)期鍵策略

在Redis中有三種刪除的操作此策略，分別是：

1. 「定時(shí)刪除」：創(chuàng)建一個(gè)定時(shí)器，定時(shí)的執(zhí)行對(duì)key的刪除操作。
2. 「惰性刪除」：每次只有再訪問(wèn)key的時(shí)候，才會(huì)檢查key的過(guò)期時(shí)間，若是已經(jīng)過(guò)期了就執(zhí)行刪除。
3. 「定期刪除」：每隔一段時(shí)間，就會(huì)檢查刪除掉過(guò)期的key。

「定時(shí)刪除」對(duì)于「內(nèi)存來(lái)說(shuō)是友好的」，定時(shí)清理出干凈的空間，但是對(duì)于「cpu來(lái)說(shuō)并不是友好的」，程序需要維護(hù)一個(gè)定時(shí)器，這就會(huì)占用cpu資源。

「惰性的刪除」對(duì)于「cpu來(lái)說(shuō)是友好的」，cpu不需要維護(hù)其它額外的操作，但是對(duì)于「內(nèi)存來(lái)說(shuō)是不友好的」，因?yàn)橐怯行﹌ey一直沒(méi)有被訪問(wèn)到，就會(huì)一直占用著內(nèi)存。

定期刪除是上面兩種方案的折中方案**，每隔一段時(shí)間刪除過(guò)期的key，也就是根據(jù)具體的業(yè)務(wù)，合理的取一個(gè)時(shí)間定期的刪除key**。

通過(guò)「最合理控制刪除的時(shí)間間隔」來(lái)刪除key，減「少對(duì)cpu的資源的占用消耗」，使刪除操作合理化。

RDB和AOF 的淘汰處理

在Redis中持久化的方式有兩種RDB和AOF，具體這兩種詳細(xì)的持久化介紹，可以參考這一篇文章[面試造飛機(jī)系列：面對(duì)Redis持久化連環(huán)Call，你還頂?shù)米幔?/a>]。

在RDB中是以快照的形式獲取內(nèi)存中某一時(shí)間點(diǎn)的數(shù)據(jù)副本，在創(chuàng)建RDB文件的時(shí)候可以通過(guò)save和bgsave命令執(zhí)行創(chuàng)建RDB文件。

「這兩個(gè)命令都不會(huì)把過(guò)期的key保存到RDB文件中」，這樣也能達(dá)到刪除過(guò)期key的效果。

當(dāng)在啟動(dòng)Redis載入RDB文件的時(shí)候，Master不會(huì)把過(guò)期的key載入，而Slave會(huì)把過(guò)期的key載入。

在AOF模式下，Redis提供了Rewite的優(yōu)化措施，執(zhí)行的命令分別是REWRITEAOF和BGREWRITEAOF，「這兩個(gè)命令都不會(huì)把過(guò)期的key寫入到AOF文件中，也能刪除過(guò)期key」。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝