一起聊聊Redis緩存的淘汰策略

redis 緩存有哪些淘汰策略？本篇文章就來和大家一起聊聊redis緩存的淘汰策略，介紹緩存策略設置建議，希望對大家有所幫助！

redis（Remote Dictionary Server )，即遠程字典服務，是一個開源的使用ANSI c語言編寫、支持網(wǎng)絡、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫，并提供多種語言的API。【相關推薦：redis】

它具備以下的特征：

• 基于內(nèi)存運行，具備高性能的特點
• 支持分布式，理論上可以無限拓展
• key-value 存儲結(jié)構(gòu)，查詢高效
• 提供多種開發(fā)語言 API， 容易和現(xiàn)有的業(yè)務系統(tǒng)集成。

通常在業(yè)務系統(tǒng)種用作分布式緩存，集中式 Session 存儲， 分布式鎖等運用場景。

不管是本地緩存還是分布式緩存，為了保證較高性能，都是使用內(nèi)存來保存數(shù)據(jù)，由于成本和內(nèi)存限制，當存儲的數(shù)據(jù)超過緩存容量時，需要對緩存的數(shù)據(jù)進行剔除。 一般的剔除策略有 FIFO 淘汰最早數(shù)據(jù)、LRU 剔除最近最少使用、和 LFU 剔除最近使用頻率最低的數(shù)據(jù)幾種策略。

Redis 緩存淘汰策略觸發(fā)

在生產(chǎn)環(huán)境中我們是不允許 redis 出現(xiàn) swap 行為的。所以一般會限制最大的使用內(nèi)存，redis 提供了配置參數(shù) maxmemory 來規(guī)定最大的使用內(nèi)存。

以下配置均為合法：

maxmemory?1000KB? maxmemory?100MB? maxmemory?1GB? maxmemory?0??#?表示不做限制，一般不會用

redis.conf 配置文件如下

8 種 Redis 緩存策略

• volatile-lru 設定超時時間的數(shù)據(jù)中，刪除最不常用的數(shù)據(jù)；

• allkeys-lru 查詢所有的key 中最不常使用的數(shù)據(jù)進行刪除，這是應用最廣泛的策略；

• volatile-random 在已經(jīng)設定了超時的數(shù)據(jù)中隨機刪除；
• allkeys-random 查詢所有的 key 之后隨機刪除；
• volatile-ttl 查詢?nèi)吭O定超時時間的數(shù)據(jù)，追后馬上排序，將馬上將要過期的數(shù)據(jù)進行刪除操作；
• noeviction (默認) 如果設置為該屬性，則不會進行刪除操作，如果內(nèi)存溢出則報錯返回；

• volatile-lfu 從所有配置了過期的時間的鍵中驅(qū)逐使用頻率最少的鍵；

• allkeys-lfu 從所有鍵中驅(qū)逐使用頻率最少的鍵；

Redis 種的 LRU 與 LFU 算法

LRU 算法

Redis LRU 算法不是一個精確的實現(xiàn)。這意味著 Redis 無法選擇最佳的驅(qū)逐候選者，即過去訪問次數(shù)最多的訪問。相反，它會嘗試運行 LRU 算法的近似值，方法是對少量密鑰進行采樣，然后逐出采樣密鑰中最好的（具有最早訪問時間）的密鑰。

然而，從 Redis 3.0 開始，該算法得到了改進，也可以選擇一些好的候選者進行驅(qū)逐。這提高了算法的性能，使其能夠更接近真實 LRU 算法的行為。

Redis LRU 算法的重要之處在于，您可以通過更改樣本數(shù)量來調(diào)整算法的精度，以檢查每次驅(qū)逐。此參數(shù)由以下配置指令控制：

maxmemory-samples?5

Redis 之所以不使用真正的 LRU 實現(xiàn)，是因為它需要更多的內(nèi)存。然而，對于使用 Redis 的應用程序，近似值實際上是等效的。下面是Redis使用的LRU近似與真實LRU的對比圖。

生成上述圖表的測試使用給定數(shù)量的鍵填充了 Redis 服務器。從第一個到最后一個訪問密鑰，因此第一個密鑰是使用 LRU 算法驅(qū)逐的最佳候選者。后來又添加了 50% 的密鑰，以強制驅(qū)逐一半的舊密鑰。

您可以在圖中看到三種點，形成三個不同的帶。

• 淺灰色帶是被驅(qū)逐的對象。
• 灰色帶是未被驅(qū)逐的對象。

• 綠色帶是添加的對象。

在理論上的 LRU 實現(xiàn)中，我們預計在舊密鑰中，前半部分將過期。Redis LRU 算法只會在概率上使舊密鑰過期。

LRU 只是一個模型，用于預測給定密鑰在未來被訪問的可能性。此外，如果您的數(shù)據(jù)訪問模式非常類似于冪律，則大多數(shù)訪問將位于 LRU 近似算法能夠很好處理的鍵集中。

缺點：可能會存在一定時間內(nèi)大量的冷數(shù)數(shù)據(jù)被訪問產(chǎn)生大量的熱點數(shù)據(jù)

LFU 算法

從 Redis 4.0 開始，可以使用新的redis。這種模式在某些情況下可能會更好（提供更好的命中率/未命中率），因為使用 LFU Redis 會嘗試跟蹤項目的訪問頻率，因此很少使用的項目會被驅(qū)逐，而經(jīng)常使用的項目有更高的機會留在記憶中。

如果您認為在 LRU，最近訪問過但實際上幾乎從未被請求過的項目不會過期，因此風險是驅(qū)逐將來有更高機會被請求的密鑰。LFU 沒有這個問題，一般應該更好地適應不同的訪問模式。

配置LFU模式，可以使用以下策略：

• volatile-lfu 在具有過期集的鍵中使用近似 LFU 驅(qū)逐。
• allkeys-lfu 使用近似 LFU 驅(qū)逐任何密鑰。

LFU 類似于 LRU：它使用一個概率計數(shù)器，稱為redis，以便僅使用每個對象的幾位來估計對象訪問頻率，并結(jié)合衰減周期，以便計數(shù)器隨著時間的推移而減少：在某些時候，我們不再希望將密鑰視為經(jīng)常訪問的密鑰，即使它們過去是這樣，以便算法可以適應訪問模式的轉(zhuǎn)變。

這些信息的采樣與 LRU 發(fā)生的情況類似（如本文檔的前一部分所述），以便選擇驅(qū)逐的候選人。

然而，與 LRU 不同的是，LFU 具有某些可調(diào)參數(shù)：例如，如果不再訪問頻繁項，它的排名應該以多快的速度降低？還可以調(diào)整 Morris 計數(shù)器范圍，以便更好地使算法適應特定用例。

默認情況下，Redis 4.0 配置為：

• 在大約一百萬個請求時使計數(shù)器飽和。
• 每一分鐘衰減一次計數(shù)器。

這些應該是合理的值并經(jīng)過實驗測試，但用戶可能希望使用這些配置設置以選擇最佳值。

有關如何調(diào)整這些參數(shù)的說明可以redis.conf在源代碼分發(fā)的示例文件中找到，但簡單地說，它們是：

lfu-log-factor?10? lfu-decay-time?1

衰減時間是顯而易見的，它是計數(shù)器應該衰減的分鐘數(shù)，當采樣并發(fā)現(xiàn)它比該值更舊時。一個特殊值0意味著：每次掃描時總是衰減計數(shù)器，很少有用。

計數(shù)器對數(shù)因子會改變需要多少次命中才能使頻率計數(shù)器飽和，這恰好在 0-255 的范圍內(nèi)。系數(shù)越高，需要越多的訪問以達到最大值。根據(jù)下表，系數(shù)越低，低訪問計數(shù)器的分辨率越好：

+--------+------------+------------+------------+------------+------------+ |?factor?|?100?hits???|?1000?hits??|?100K?hits??|?1M?hits????|?10M?hits???| +--------+------------+------------+------------+------------+------------+ |?0??????|?104????????|?255????????|?255????????|?255????????|?255????????| +--------+------------+------------+------------+------------+------------+ |?1??????|?18?????????|?49?????????|?255????????|?255????????|?255????????| +--------+------------+------------+------------+------------+------------+ |?10?????|?10?????????|?18?????????|?142????????|?255????????|?255????????| +--------+------------+------------+------------+------------+------------+ |?100????|?8??????????|?11?????????|?49?????????|?143????????|?255????????| +--------+------------+------------+------------+------------+------------+

淘汰最近一段時間被訪問次數(shù)最少的數(shù)據(jù)，以次數(shù)作為參考。

缺點：

1. 最近加入的數(shù)據(jù)常常容易被剔除，因為其起始方法次數(shù)比較少，

2. 如果頻率時間度量為 1 個小時，則平均一天每個小時內(nèi)訪問頻率 1000 的熱點數(shù)據(jù)可能會被 2個小時的一段時間訪問的頻率為 1001 的數(shù)據(jù)剔除掉。可能會出現(xiàn)一些臨界值的數(shù)據(jù)。

緩存策略設置建議

建議：了解Redis 的淘汰策略之后，在平時使用盡量主動設置/更新 key 的 expire 時間主動剔除不活躍的舊數(shù)據(jù)， 有助于提升查詢性能

更多編程相關知識，請訪問：redis！！