您好,登錄后才能下訂單哦!
這篇文章主要講解了“Redis緩存的淘汰策略是什么”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“Redis緩存的淘汰策略是什么”吧!
Redis(Remote Dictionary Server ),即遠程字典服務,是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫,并提供多種語言的API。【相關推薦:Redis視頻教程】
它具備以下的特征:
基于內存運行,具備高性能的特點
支持分布式,理論上可以無限拓展
key-value 存儲結構,查詢高效
提供多種開發語言 API, 容易和現有的業務系統集成。
通常在業務系統種用作分布式緩存,集中式 Session 存儲, 分布式鎖等運用場景。
不管是本地緩存還是分布式緩存,為了保證較高性能,都是使用內存來保存數據,由于成本和內存限制,當存儲的數據超過緩存容量時,需要對緩存的數據進行剔除。 一般的剔除策略有 FIFO 淘汰最早數據、LRU 剔除最近最少使用、和 LFU 剔除最近使用頻率最低的數據幾種策略。
在生產環境中我們是不允許 redis 出現 swap 行為的。所以一般會限制最大的使用內存,redis 提供了配置參數 maxmemory 來規定最大的使用內存。
以下配置均為合法:
maxmemory 1000KB maxmemory 100MB maxmemory 1GB maxmemory 0 # 表示不做限制,一般不會用
redis.conf 配置文件如下
volatile-lru 設定超時時間的數據中,刪除最不常用的數據;
allkeys-lru 查詢所有的key 中最不常使用的數據進行刪除,這是應用最廣泛的策略;
volatile-random 在已經設定了超時的數據中隨機刪除;
allkeys-random 查詢所有的 key 之后隨機刪除;
volatile-ttl 查詢全部設定超時時間的數據,追后馬上排序,將馬上將要過期的數據進行刪除操作;
noeviction (默認) 如果設置為該屬性,則不會進行刪除操作,如果內存溢出則報錯返回;
volatile-lfu 從所有配置了過期的時間的鍵中驅逐使用頻率最少的鍵;
allkeys-lfu 從所有鍵中驅逐使用頻率最少的鍵;
LRU 算法
Redis LRU 算法不是一個精確的實現。這意味著 Redis 無法選擇最佳的驅逐候選者,即過去訪問次數最多的訪問。相反,它會嘗試運行 LRU 算法的近似值,方法是對少量密鑰進行采樣,然后逐出采樣密鑰中最好的(具有最早訪問時間)的密鑰。
然而,從 Redis 3.0 開始,該算法得到了改進,也可以選擇一些好的候選者進行驅逐。這提高了算法的性能,使其能夠更接近真實 LRU 算法的行為。
Redis LRU 算法的重要之處在于,您可以通過更改樣本數量來調整算法的精度,以檢查每次驅逐。此參數由以下配置指令控制:
maxmemory-samples 5
Redis 之所以不使用真正的 LRU 實現,是因為它需要更多的內存。然而,對于使用 Redis 的應用程序,近似值實際上是等效的。下面是Redis使用的LRU近似與真實LRU的對比圖。
生成上述圖表的測試使用給定數量的鍵填充了 Redis 服務器。從第一個到最后一個訪問密鑰,因此第一個密鑰是使用 LRU 算法驅逐的最佳候選者。后來又添加了 50% 的密鑰,以強制驅逐一半的舊密鑰。
您可以在圖中看到三種點,形成三個不同的帶。
淺灰色帶是被驅逐的對象。
灰色帶是未被驅逐的對象。
綠色帶是添加的對象。
在理論上的 LRU 實現中,我們預計在舊密鑰中,前半部分將過期。Redis LRU 算法只會在概率上使舊密鑰過期。
LRU 只是一個模型,用于預測給定密鑰在未來被訪問的可能性。此外,如果您的數據訪問模式非常類似于冪律,則大多數訪問將位于 LRU 近似算法能夠很好處理的鍵集中。
缺點:可能會存在一定時間內大量的冷數數據被訪問產生大量的熱點數據
LFU 算法
從 Redis 4.0 開始,可以使用新的最不常用驅逐模式。這種模式在某些情況下可能會更好(提供更好的命中率/未命中率),因為使用 LFU Redis 會嘗試跟蹤項目的訪問頻率,因此很少使用的項目會被驅逐,而經常使用的項目有更高的機會留在記憶中。
如果您認為在 LRU,最近訪問過但實際上幾乎從未被請求過的項目不會過期,因此風險是驅逐將來有更高機會被請求的密鑰。LFU 沒有這個問題,一般應該更好地適應不同的訪問模式。
配置LFU模式,可以使用以下策略:
volatile-lfu 在具有過期集的鍵中使用近似 LFU 驅逐。
allkeys-lfu 使用近似 LFU 驅逐任何密鑰。
LFU 類似于 LRU:它使用一個概率計數器,稱為莫里斯計數器,以便僅使用每個對象的幾位來估計對象訪問頻率,并結合衰減周期,以便計數器隨著時間的推移而減少:在某些時候,我們不再希望將密鑰視為經常訪問的密鑰,即使它們過去是這樣,以便算法可以適應訪問模式的轉變。
這些信息的采樣與 LRU 發生的情況類似(如本文檔的前一部分所述),以便選擇驅逐的候選人。
然而,與 LRU 不同的是,LFU 具有某些可調參數:例如,如果不再訪問頻繁項,它的排名應該以多快的速度降低?還可以調整 Morris 計數器范圍,以便更好地使算法適應特定用例。
默認情況下,Redis 4.0 配置為:
在大約一百萬個請求時使計數器飽和。
每一分鐘衰減一次計數器。
這些應該是合理的值并經過實驗測試,但用戶可能希望使用這些配置設置以選擇最佳值。
有關如何調整這些參數的說明可以redis.conf在源代碼分發的示例文件中找到,但簡單地說,它們是:
lfu-log-factor 10 lfu-decay-time 1
衰減時間是顯而易見的,它是計數器應該衰減的分鐘數,當采樣并發現它比該值更舊時。一個特殊值0意味著:每次掃描時總是衰減計數器,很少有用。
計數器對數因子會改變需要多少次命中才能使頻率計數器飽和,這恰好在 0-255 的范圍內。系數越高,需要越多的訪問以達到最大值。根據下表,系數越低,低訪問計數器的分辨率越好:
+--------+------------+------------+------------+------------+------------+ | 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 | +--------+------------+------------+------------+------------+------------+
淘汰最近一段時間被訪問次數最少的數據,以次數作為參考。
缺點:
1. 最近加入的數據常常容易被剔除,因為其起始方法次數比較少,
2. 如果頻率時間度量為 1 個小時,則平均一天每個小時內訪問頻率 1000 的熱點數據可能會被 2個小時的一段時間訪問的頻率為 1001 的數據剔除掉。可能會出現一些臨界值的數據。
建議:了解Redis 的淘汰策略之后,在平時使用盡量主動設置/更新 key 的 expire 時間主動剔除不活躍的舊數據, 有助于提升查詢性能
感謝各位的閱讀,以上就是“Redis緩存的淘汰策略是什么”的內容了,經過本文的學習后,相信大家對Redis緩存的淘汰策略是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。