Redis之key的淘汰策略

^^ITBOY^^發表於2023-01-19

淘汰策略概述

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範圍內。係數越高,需要更多的訪問才能達到最大值;係數越低,低頻訪問計數器的解析度越好,如下表所示:

 

 

相關文章