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

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

一、Maxmemory設定指令

Maxmemory設定指令用於配置Redis的資料集使用指定量的記憶體。可以用redis 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資訊輸出。

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 實現。