淘汰策略概述 redis作為緩存使用時，在添加新數據的同時自動清理舊的數據。這種行為在開發者社區眾所周知，也是流行的memcached系統的預設行為。 redis中使用的LRU淘汰演算法是一種近似LRU的演算法。 淘汰策略 針對淘汰策略，redis有一下幾種配置方案： 1、noeviction：當觸發內 ...
淘汰策略概述
redis作為緩存使用時，在添加新數據的同時自動清理舊的數據。這種行為在開發者社區眾所周知，也是流行的memcached系統的預設行為。
redis中使用的LRU淘汰演算法是一種近似LRU的演算法。
淘汰策略
針對淘汰策略，redis有一下幾種配置方案：
1、noeviction：當觸發記憶體閾值時，redis只讀不寫；
2、allkeys-lru：針對所有的key，執行LRU（最近最少使用）策略；
3、allkeys-lfu：針對所有的key，執行LFU（最低頻使用）策略；
4、volatile-lru：針對設置了過期時間的key，執行LRU（最近最少使用）策略；
5、volatile-lfu：針對設置了過期時間的key，執行LFU（最低頻使用）策略；
6、allkeys-random：針對所有key，進行隨機淘汰；
7、volatile-random：針對設置了過期時間的key，進行隨機淘汰；
8、volatile-ttl：針對設置了過期時間的key，淘汰剩餘過期時間最短的；
根據應用場景選擇合適的淘汰策略是非常重要的，我們可以在程式運行時實時重置淘汰策略，並使用Redis INFO輸出來監控緩存未命中和命中的數量，以優化設置。
根據以往使用慣例：
- 當你希望某些元素的子集被訪問的頻率高於其他元素，或者當你不知道怎麼選擇淘汰策略時，allkeys-lru策略是一個很好的選擇；
- 當你在迴圈訪問redis，且所有的key是被連續掃描時，或者你希望key過期時間均勻分佈時，allkeys-random策略是一個很好的選擇；
- 如果你希望基於key不同的TTL時間篩選出哪些key可被淘汰，volatile-ttl策略是一個很好的選擇；
還有一點是為key設置過期時間會占用記憶體，因此使用allkeys-lru這樣的策略會更節省記憶體，因為在記憶體壓力下不需要對key進行過期設置。
淘汰策略如何工作
淘汰過程如下：
- 客戶端執行一條指令，需要添加一批數據；
- redis檢測緩存閾值限制，如果超過閾值則執行淘汰策略；
- 執行指令等等；
因此在redis的使用過程中，我們可能不斷的超過記憶體閾值限制，然後執行淘汰策略再將記憶體恢復到閾值之下。
近似LRU演算法
redis lru演算法是一個近似lru演算法，這意味著針對整個key集合，redis在執行lru策略時可能不會很精準的淘汰掉最應該被淘汰的key，相反的是，redis會通過抽樣一小部分key，並淘汰採樣key中最該被淘汰的。 自redis3.0以來，該演算法得到了改善，能夠抽樣大批量的key進行淘汰，使其能夠更接近真實LRU演算法的行為。 redis lru演算法的重要之處在於可以通過更改樣本數量來調整演算法的精度，此參數由以下配置指令控制：maxmemory-samples 5
redis不使用真正的LRU實現的原因是它需要更多的記憶體。然而，對於使用Redis的應用程式，近似lru演算法實際上是與精確lru演算法差不多的。此圖將redis使用的LRU近似值與真實LRU進行了比較。
用給定數量的key填充了Redis伺服器（達到記憶體閾值）進行測試並生成了上面的圖。從第一個到最後一個訪問key。第一個key是使用LRU演算法淘汰的最佳候選key。之後再添加50%以上的key，以強制淘汰一半的舊key。
你可以在圖中看到三種點，形成了三個不同的區域：
- 淺灰色區域是被淘汰的對象
- 灰色區域是未被淘汰的對象
- 綠色區域是新加的對象
在理論LRU實現中（theoretical LRU），我們預計舊key集合中的前一半將會被淘汰，與之相反，redis lru演算法實現中，舊key集合中也只是會離散性的淘汰其中某些key。
正如您所看到的那樣，與Redis 2.8相比，Redis 3.0在同樣抽樣數為5個時做得更好，但是大多數最新增加的key仍然被Redis 2.8保留。在Redis 3.0中使用10的樣本大小，近似值非常接近Redis 3.0的理論性能。
在模擬中，我們發現使用冪律訪問模式（類似20%的key承擔了80%的訪問），真實LRU和Redis近似LRU之間的差異極小或根本不存在。
使用CONFIG SET maxmemory samples＜count＞命令在生產中使用不同的樣本大小值進行實驗非常簡單。
新的LFU模式
從redis4.0開始，可以在某些特定場景下使用低頻淘汰策略。在選用LFU策略後，redis會跟蹤key的訪問頻率，所以低頻的key將被淘汰。這意味著經常訪問的key有很大的機會一直留在記憶體中。
要配置LFU模式，可以使用以下策略：
- volatile-lfu：針對設置了過期時間的key，使用近似lfu淘汰；
- allkeys-lfu：針對所有key，使用近似lfu淘汰；
LFU近似於LRU：它使用一個稱為Morris的概率計數器來估計key訪問頻率，計數器中每個key只占用幾個bit，並且計數器功能附加衰減周期，這樣計數器統計的key訪問頻率就會隨著時間的推移而降低（如果一段時間內一個key訪問頻率低於計數器衰減速度，最終這個key會被淘汰）。直至某一刻，我們不再將一些key視為頻繁訪問的key，即使它們在過去是被頻繁訪問的，以便演算法能夠適應訪問模式的變化。
該信息的採樣方式與LRU（如本文檔前一節所述）選擇淘汰key的情況類似。
然而，與LRU不同的是，LFU具有某些可調參數：例如，如果一個頻繁key不再被訪問，那麼它的訪問頻率級別應該降低多少？還可以調整Morris計數器範圍，以更好地使演算法適應特定的場景。
預設情況下，Redis配置為：
- 在大約100萬次請求時讓計數器飽和；
- 每一分鐘使計數器衰減一次；
這些配置應該是合理的，並且經過了實驗測試，但用戶可能希望使用這些配置設置來選擇最佳值。
有關如何調整這些參數的說明，可以在源發行版的示例redis.conf文件中找到。簡而言之，它們是：
lfu-log-factor 10 lfu-decay-time 1
衰減時間是最明顯的一個，它是計數器在採樣時應該衰減的分鐘數。特殊值0表示：永遠不會衰減計數器。
計數器對數因數決定了使頻率計數器達到飽和需要的key命中次數，頻率計數器剛好在0-255範圍內。繫數越高，需要更多的訪問才能達到最大值；繫數越低，低頻訪問計數器的解析度越好，如下表所示：
