當用Redis作為一個LRU存儲時，有些時候是比較方便的，在你增添新的數據時會自動驅逐舊的數據。這種行為在開發者論壇是非常有名的，因為這是流行的memcached系統的默認行為。

LRU實際上只是支持驅逐的方式之一。這頁包含更多一般的Redis maxmemory指令的話題用于限制內存使用到一個定額，同時它也深入的涵蓋了Redis所使用的LRU算法，實際上是精確LRU的近似值。

一、Maxmemory設置指令

Maxmemory設置指令用于配置Redis的數據集使用指定量的內存?？梢杂胷edis conf.file設置指令,或者可以在稍晚的時候在運行時間用config set命令。

例如，為了設置內存局限于100百萬字節，下列指令可在redis.conf file內使用。設置maxmemory到零使得沒有內存限制。這是64位系統的默認行為，而32位系統使用3GB內隱記憶極限。

maxmemory 100mb

當達到指定量的內存后，就可以選擇不同的行為，稱為策略。Redis可以返回錯誤的指令，導致使用更多的內存，或者為了每次增加新的數據后返回指定的內存，它可以驅逐一些舊的數據。

二、驅逐策略

當到達maxmemory極限時，使用maxmemory-策略配置指令來執行具體的Redis動作。

以下策略可以使用：

1、noeviction：達到內存限額后返回錯誤，客戶嘗試可以導致更多內存使用的命令（大部分寫命令，但DEL和一些例外）

2、allkeys-lru：為了給新增加的數據騰出空間，驅逐鍵先試圖移除一部分最近使用較少的（LRC）。

3、volatile-lru：為了給新增加的數據騰出空間，驅逐鍵先試圖移除一部分最近使用較少的（LRC），但只限于過期設置鍵。

4、allkeys-random: 為了給新增加的數據騰出空間，驅逐任意鍵。

5、volatile-random: 為了給新增加的數據騰出空間，驅逐任意鍵，但只限于有過期設置的驅逐鍵。

6、volatile-ttl: 為了給新增加的數據騰出空間，驅逐鍵只有秘鑰過期設置，并且首先嘗試縮短存活時間的驅逐鍵。

如果沒有秘鑰去驅逐匹配先決條件，策略volatile-lru, volatile-random 和volatile-ttl行為很像noeviction。

那么根據你應用的訪問模式選擇正確的驅逐策略是很重要的。然而在應用運行時你可以在運行時間重新設置策略，并且監控緩存缺失的數量并為了調整你的設置點擊Redis信息輸出。

三、近似LRU算法

Redis的LRU算法不是準確的實現。也就是說Redis沒有為逐出選擇 最好的候選人 ，也就是沒有選擇過去最后被訪問離現在最久的。反而 是去執行一個 近似LRU的算法，通過抽樣少量的key，并且逐出抽樣中最后被訪問離現在最久的key（最老的訪問時間）。

在Redis 3.0（目前的測試版），算法被改進了，使用了一個逐出最佳候選池。改進了算法的性能，使它更加近似真正LRU算法。

算法中，關于逐出檢測的樣品數量，你可以自己去調整。配置參數是：

maxmemory-samples 5

Redis沒有使用真正實現LRU算是的原因是，因為消耗更多的內存。然而對于使用Redis的應用來說，事實上是等價的。下面是Redis的LRU算法和真正LRU算法的比較：

給出配置數量的key生成上面的圖表。key從第一行到最后一行被訪問，那么第一個key是LRU算法中最好的逐出候選者。之后有50%的key被添加，那么一半的舊key被逐出。

在上圖中你可以看見3個明顯的區別：

1、淺灰色帶是被逐出的對象。

2、灰色帶是沒有被逐出的對象。

3、綠色帶是被添加的對象。

LRU理論實現是在所有的舊key中前一半被逐出。Redis使用的是近似過期的key被逐出。

如你所見，3.0的工作比2.8更好，然而在2.8版本中，大多數最新訪問對象的仍然保留。在3.0使用樣品為10 時，性能非常接近理論上的LRU算法。

注意：LRU僅僅是一個預測模式，給出的key很可能在未來被訪問。此外，如果你的數據訪問模式類似于冪律（線性的），大多數key都可能被訪問那么這個LRU算法的處理就是非常好的。

在實戰中 ，我們發現使用冪律（線性的）的訪問模式，在真正的LRU算法和Redis的LRU算法之間差異很小或者不存在差異。

你可以提升樣品大小配置到10，它將接近真正的LRU算法，并且有不同錯過率，但是要消耗更多的CPU。

在調試時使用不同的樣品大小去調試非常簡單，使用命令CONFIG SET maxmemory-samples 實現。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。