出處：juejin.im/post/5d674ac2e51d4557ca7fdd70

小結(jié)：

本文主要包括三個部分。
如何通過文件或命令修改配置信息；
redis的6種內(nèi)存淘汰策略；
LRU和LFU算法的介紹及應(yīng)用。LRU表示最少使用，redis使用近似LRU算法，主要也是從性能上考慮，每次是隨機(jī)取出部分key，然后從里面淘汰掉最少使用的，3.0版本針對近似LRU做了優(yōu)化。LFU是4.0新增淘汰策略，根據(jù)訪問頻率進(jìn)行淘汰，能夠避免假熱點(diǎn)的情況。

Redis占用內(nèi)存大小

我們知道Redis是基于內(nèi)存的key-value數(shù)據(jù)庫，因為系統(tǒng)的內(nèi)存大小有限，所以我們在使用Redis的時候可以配置Redis能使用的最大的內(nèi)存大小。

1、通過配置文件配置

通過在Redis安裝目錄下面的redis.conf配置文件中添加以下配置設(shè)置內(nèi)存大小

//設(shè)置Redis最大占用內(nèi)存大小為100Mmaxmemory 100mb復(fù)制代碼

redis的配置文件不一定使用的是安裝目錄下面的redis.conf文件，啟動redis服務(wù)的時候是可以傳一個參數(shù)指定redis的配置文件的

2、通過命令修改

Redis支持運(yùn)行時通過命令動態(tài)修改內(nèi)存大小

//設(shè)置Redis最大占用內(nèi)存大小為100M127.0.0.1:6379> configsetmaxmemory 100mb//獲取設(shè)置的Redis能使用的最大內(nèi)存大小127.0.0.1:6379> config get maxmemory復(fù)制代碼

如果不設(shè)置最大內(nèi)存大小或者設(shè)置最大內(nèi)存大小為0，在64位操作系統(tǒng)下不限制內(nèi)存大小，在32位操作系統(tǒng)下最多使用3GB內(nèi)存

Redis的內(nèi)存淘汰

既然可以設(shè)置Redis最大占用內(nèi)存大小，那么配置的內(nèi)存就有用完的時候。那在內(nèi)存用完的時候，還繼續(xù)往Redis里面添加數(shù)據(jù)不就沒內(nèi)存可用了嗎？

實(shí)際上Redis定義了幾種策略用來處理這種情況：

noeviction(默認(rèn)策略)：對于寫請求不再提供服務(wù)，直接返回錯誤（DEL請求和部分特殊請求除外）

allkeys-lru：從所有key中使用LRU算法進(jìn)行淘汰

volatile-lru：從設(shè)置了過期時間的key中使用LRU算法進(jìn)行淘汰

allkeys-random：從所有key中隨機(jī)淘汰數(shù)據(jù)

volatile-random：從設(shè)置了過期時間的key中隨機(jī)淘汰

volatile-ttl：在設(shè)置了過期時間的key中，根據(jù)key的過期時間進(jìn)行淘汰，越早過期的越優(yōu)先被淘汰

當(dāng)使用volatile-lru、volatile-random、volatile-ttl這三種策略時，如果沒有key可以被淘汰，則和noeviction一樣返回錯誤

如何獲取及設(shè)置內(nèi)存淘汰策略

獲取當(dāng)前內(nèi)存淘汰策略：

127.0.0.1:6379> config get maxmemory-policy

通過配置文件設(shè)置淘汰策略（修改redis.conf文件）：

maxmemory-policy allkeys-lru

通過命令修改淘汰策略：

127.0.0.1:6379> configsetmaxmemory-policy allkeys-lru

LRU算法

什么是LRU?

上面說到了Redis可使用最大內(nèi)存使用完了，是可以使用LRU算法進(jìn)行內(nèi)存淘汰的，那么什么是LRU算法呢？

LRU(Least Recently Used)，即最近最少使用，是一種緩存置換算法。在使用內(nèi)存作為緩存的時候，緩存的大小一般是固定的。當(dāng)緩存被占滿，這個時候繼續(xù)往緩存里面添加數(shù)據(jù)，就需要淘汰一部分老的數(shù)據(jù)，釋放內(nèi)存空間用來存儲新的數(shù)據(jù)。這個時候就可以使用LRU算法了。其核心思想是：如果一個數(shù)據(jù)在最近一段時間沒有被用到，那么將來被使用到的可能性也很小，所以就可以被淘汰掉。

使用java實(shí)現(xiàn)一個簡單的LRU算法

```

public?classLRUCache{

????//容量

????private?int?capacity;

????//當(dāng)前有多少節(jié)點(diǎn)的統(tǒng)計

????private?int?count;

????//緩存節(jié)點(diǎn)

????private?Map<k,?Node<k,?v>>?nodeMap;

????private?Node<k,?v>?head;

????private?Node<k,?v>?tail;

????publicLRUCache(intcapacity){

????????if?(capacity?<?1)?{

????????????throw?new?IllegalArgumentException(String.valueOf(capacity));

????????}

????????this.capacity?=?capacity;

????????this.nodeMap?=?new?HashMap<>();

????????//初始化頭節(jié)點(diǎn)和尾節(jié)點(diǎn)，利用哨兵模式減少判斷頭結(jié)點(diǎn)和尾節(jié)點(diǎn)為空的代碼

????????Node?headNode?=?new?Node(null,?null);

????????Node?tailNode?=?new?Node(null,?null);

????????headNode.next?=?tailNode;

????????tailNode.pre?=?headNode;

????????this.head?=?headNode;

????????this.tail?=?tailNode;

????}

????publicvoidput(k?key,?v?value){

????????Node<k,?v>?node?=?nodeMap.get(key);

????????if?(node?==?null)?{

????????????if?(count?>=?capacity)?{

????????????????//先移除一個節(jié)點(diǎn)

????????????????removeNode();

????????????}

????????????node?=?new?Node<>(key,?value);

????????????//添加節(jié)點(diǎn)

????????????addNode(node);

????????}?else?{

????????????//移動節(jié)點(diǎn)到頭節(jié)點(diǎn)

????????????moveNodeToHead(node);

????????}

????}

????publicNodeget(k?key){

????????Node<k,?v>?node?=?nodeMap.get(key);

????????if?(node?!=?null)?{

????????????moveNodeToHead(node);

????????}

????????return?node;

????}

????privatevoidremoveNode(){

????????Node?node?=?tail.pre;

????????//從鏈表里面移除

????????removeFromList(node);

????????nodeMap.remove(node.key);

????????count--;

????}

????privatevoidremoveFromList(Node<k,?v>?node){

????????Node?pre?=?node.pre;

????????Node?next?=?node.next;

????????pre.next?=?next;

????????next.pre?=?pre;

????????node.next?=?null;

????????node.pre?=?null;

????}

????privatevoidaddNode(Node<k,?v>?node){

????????//添加節(jié)點(diǎn)到頭部

????????addToHead(node);

????????nodeMap.put(node.key,?node);

????????count++;

????}

????privatevoidaddToHead(Node<k,?v>?node){

????????Node?next?=?head.next;

????????next.pre?=?node;

????????node.next?=?next;

????????node.pre?=?head;

????????head.next?=?node;

????}

????publicvoidmoveNodeToHead(Node<k,?v>?node){

????????//從鏈表里面移除

????????removeFromList(node);

????????//添加節(jié)點(diǎn)到頭部

????????addToHead(node);

????}

????classNode{

????????k?key;

????????v?value;

????????Node?pre;

????????Node?next;

????????publicNode(k?key,?v?value){

????????????this.key?=?key;

????????????this.value?=?value;

????????}

????}

}

```

上面這段代碼實(shí)現(xiàn)了一個簡單的LUR算法，代碼很簡單，也加了注釋，仔細(xì)看一下很容易就看懂。

LRU在Redis中的實(shí)現(xiàn)

近似LRU算法

Redis使用的是近似LRU算法，它跟常規(guī)的LRU算法還不太一樣。近似LRU算法通過隨機(jī)采樣法淘汰數(shù)據(jù)，每次隨機(jī)出5（默認(rèn)）個key，從里面淘汰掉最近最少使用的key。

可以通過maxmemory-samples參數(shù)修改采樣數(shù)量：

例：maxmemory-samples 10

maxmenory-samples配置的越大，淘汰的結(jié)果越接近于嚴(yán)格的LRU算法

Redis為了實(shí)現(xiàn)近似LRU算法，給每個key增加了一個額外增加了一個24bit的字段，用來存儲該key最后一次被訪問的時間。

Redis3.0對近似LRU的優(yōu)化

Redis3.0對近似LRU算法進(jìn)行了一些優(yōu)化。新算法會維護(hù)一個候選池（大小為16），池中的數(shù)據(jù)根據(jù)訪問時間進(jìn)行排序，第一次隨機(jī)選取的key都會放入池中，隨后每次隨機(jī)選取的key只有在訪問時間小于池中最小的時間才會放入池中，直到候選池被放滿。當(dāng)放滿后，如果有新的key需要放入，則將池中最后訪問時間最大（最近被訪問）的移除。

當(dāng)需要淘汰的時候，則直接從池中選取最近訪問時間最小（最久沒被訪問）的key淘汰掉就行。

LRU算法的對比

我們可以通過一個實(shí)驗對比各LRU算法的準(zhǔn)確率，先往Redis里面添加一定數(shù)量的數(shù)據(jù)n，使Redis可用內(nèi)存用完，再往Redis里面添加n/2的新數(shù)據(jù)，這個時候就需要淘汰掉一部分的數(shù)據(jù)，如果按照嚴(yán)格的LRU算法，應(yīng)該淘汰掉的是最先加入的n/2的數(shù)據(jù)。生成如下各LRU算法的對比圖（圖片來源）：

你可以看到圖中有三種不同顏色的點(diǎn)：

淺灰色是被淘汰的數(shù)據(jù)

灰色是沒有被淘汰掉的老數(shù)據(jù)

綠色是新加入的數(shù)據(jù)

我們能看到Redis3.0采樣數(shù)是10生成的圖最接近于嚴(yán)格的LRU。而同樣使用5個采樣數(shù)，Redis3.0也要優(yōu)于Redis2.8。

?redis如何管理熱點(diǎn)數(shù)據(jù)

前面我們講述字符串對象時，提到了redisObject對象中存在一個lru屬性：

```

typedef?struct?redisObject?{

unsignedtype:4;//對象類型（4位=0.5字節(jié)）

unsigned?encoding:4;//編碼（4位=0.5字節(jié)）

unsigned?lru:LRU_BITS;//記錄對象最后一次被應(yīng)用程序訪問的時間（24位=3字節(jié)）

int refcount;//引用計數(shù)。等于0時表示可以被垃圾回收（32位=4字節(jié)）

void *ptr;//指向底層實(shí)際的數(shù)據(jù)存儲結(jié)構(gòu)，如：SDS等(8字節(jié))

}?robj;

```

lru屬性是創(chuàng)建對象的時候?qū)懭耄瑢ο蟊辉L問到時也會進(jìn)行更新。正常人的思路就是最后決定要不要刪除某一個鍵肯定是用當(dāng)前時間戳減去lru，差值最大的就優(yōu)先被刪除。但是Redis里面并不是這么做的，Redis中維護(hù)了一個全局屬性lru_clock，這個屬性是通過一個全局函數(shù)serverCron每隔100毫秒執(zhí)行一次來更新的，記錄的是當(dāng)前unix時間戳。

最后決定刪除的數(shù)據(jù)是通過lru_clock減去對象的lru屬性而得出的。那么為什么Redis要這么做呢？直接取全局時間不是更準(zhǔn)確嗎？

這是因為這么做可以避免每次更新對象的lru屬性的時候可以直接取全局屬性，而不需要去調(diào)用系統(tǒng)函數(shù)來獲取系統(tǒng)時間，從而提升效率（Redis當(dāng)中有很多這種細(xì)節(jié)考慮來提升性能，可以說是對性能盡可能的優(yōu)化到極致）。

不過這里還有一個問題，我們看到，redisObject對象中的lru屬性只有24位，24位只能存儲194天的時間戳大小，一旦超過194天之后就會重新從0開始計算，所以這時候就可能會出現(xiàn)redisObject對象中的lru屬性大于全局的lru_clock屬性的情況。

正因為如此，所以計算的時候也需要分為2種情況：

當(dāng)全局lruclock>lru，則使用lruclock-lru得到空閑時間。

當(dāng)全局lruclock

需要注意的是，這種計算方式并不能保證抽樣的數(shù)據(jù)中一定能刪除空閑時間最長的。這是因為首先超過194天還不被使用的情況很少，再次只有l(wèi)ruclock第2輪繼續(xù)超過lru屬性時，計算才會出問題。

比如對象A記錄的lru是1天，而lruclock第二輪都到10天了，這時候就會導(dǎo)致計算結(jié)果只有10-1=9天，實(shí)際上應(yīng)該是194+10-1=203天。但是這種情況可以說又是更少發(fā)生，所以說這種處理方式是可能存在刪除不準(zhǔn)確的情況，但是本身這種算法就是一種近似的算法，所以并不會有太大影響。

LFU算法

LFU算法是Redis4.0里面新加的一種淘汰策略。它的全稱是Least Frequently Used，它的核心思想是根據(jù)key的最近被訪問的頻率進(jìn)行淘汰，很少被訪問的優(yōu)先被淘汰，被訪問的多的則被留下來。

當(dāng)我們采用LFU回收策略時，lru屬性的高16位用來記錄訪問時間（last decrement time：ldt，單位為分鐘），低8位用來記錄訪問頻率（logistic counter：logc），簡稱counter。

訪問頻次遞增

LFU計數(shù)器每個鍵只有8位，它能表示的最大值是255，所以Redis使用的是一種基于概率的對數(shù)器來實(shí)現(xiàn)counter的遞增。r

給定一個舊的訪問頻次，當(dāng)一個鍵被訪問時，counter按以下方式遞增：

提取0和1之間的隨機(jī)數(shù)R。

counter- 初始值（默認(rèn)為5），得到一個基礎(chǔ)差值，如果這個差值小于0，則直接取0，為了方便計算，把這個差值記為baseval。

概率P計算公式為：1/(baseval * lfu_log_factor + 1)。

如果R < P時，頻次進(jìn)行遞增（counter++）。

公式中的lfu_log_factor稱之為對數(shù)因子，默認(rèn)是10，可以通過參數(shù)來進(jìn)行控制：

```

lfu_log_factor?10

```

下圖就是對數(shù)因子lfu_log_factor和頻次counter增長的關(guān)系圖：

可以看到，當(dāng)對數(shù)因子lfu_log_factor為100時，大概是10M（1000萬）次訪問才會將訪問counter增長到255，而默認(rèn)的10也能支持到1M（100萬）次訪問counter才能達(dá)到255上限，這在大部分場景都是足夠滿足需求的。

訪問頻次遞減

如果訪問頻次counter只是一直在遞增，那么遲早會全部都到255，也就是說counter一直遞增不能完全反應(yīng)一個key的熱度的，所以當(dāng)某一個key一段時間不被訪問之后，counter也需要對應(yīng)減少。

counter的減少速度由參數(shù)lfu-decay-time進(jìn)行控制，默認(rèn)是1，單位是分鐘。默認(rèn)值1表示：N分鐘內(nèi)沒有訪問，counter就要減N。

lfu-decay-time?1

具體算法如下：

獲取當(dāng)前時間戳，轉(zhuǎn)化為分鐘后取低16位（為了方便后續(xù)計算，這個值記為now）。

取出對象內(nèi)的lru屬性中的高16位（為了方便后續(xù)計算，這個值記為ldt）。

當(dāng)lru>now時，默認(rèn)為過了一個周期（16位，最大65535)，則取差值65535-ldt+now：當(dāng)lru<=now時，取差值now-ldt（為了方便后續(xù)計算，這個差值記為idle_time）。

取出配置文件中的lfu_decay_time值，然后計算：idle_time / lfu_decay_time（為了方便后續(xù)計算，這個值記為num_periods）。

最后將counter減少：counter - num_periods。

看起來這么復(fù)雜，其實(shí)計算公式就是一句話：取出當(dāng)前的時間戳和對象中的lru屬性進(jìn)行對比，計算出當(dāng)前多久沒有被訪問到，比如計算得到的結(jié)果是100分鐘沒有被訪問，然后再去除配置參數(shù)lfu_decay_time，如果這個配置默認(rèn)為1也即是100/1=100，代表100分鐘沒訪問，所以counter就減少100。

LFU算法能更好的表示一個key被訪問的熱度。假如你使用的是LRU算法，一個key很久沒有被訪問到，只剛剛是偶爾被訪問了一次，那么它就被認(rèn)為是熱點(diǎn)數(shù)據(jù)，不會被淘汰，而有些key將來是很有可能被訪問到的則被淘汰了。如果使用LFU算法則不會出現(xiàn)這種情況，因為使用一次并不會使一個key成為熱點(diǎn)數(shù)據(jù)。

LFU一共有兩種策略：

volatile-lfu：在設(shè)置了過期時間的key中使用LFU算法淘汰key

allkeys-lfu：在所有的key中使用LFU算法淘汰數(shù)據(jù)

設(shè)置使用這兩種淘汰策略跟前面講的一樣，不過要注意的一點(diǎn)是這兩周策略只能在Redis4.0及以上設(shè)置，如果在Redis4.0以下設(shè)置會報錯

參考鏈接：

[redis內(nèi)存耗盡會發(fā)生什么？](https://mp.weixin.qq.com/s?__biz=MzIyNDU2ODA4OQ==&mid=2247488487&idx=1&sn=dc0a98cb3e9883a701fc5778008427f9&chksm=e80da591df7a2c87a405a8d1acfbff318c3d5277d34f917d0dde926ad0433d0d0b05a1a5d955&scene=21#wechat_redirectn)