redis怎么配置緩存清理

將 Redis 用作緩存時, 如果內存空間用滿, 就會自動驅逐老的數據。 默認情況下 memcached 就是這種方式, 大部分開發者都比較熟悉。

LRU是Redis唯一支持的回收算法. 本文詳細介紹用于限制最大內存使用量的 maxmemory 指令, 并深入講解 Redis 所使用的近似LRU算法。

maxmemory 配置指令

maxmemory 用于指定 Redis 能使用的最大內存。既可以在 redis.conf 文件中設置, 也可以在運行過程中通過 CONFIG SET 命令動態修改。

例如, 要設置 100MB 的內存限制, 可以在 redis.conf 文件中這樣配置：

maxmemory 100mb

將 maxmemory 設置為 0, 則表示不進行內存限制。當然, 對32位系統來說有一個隱性的限制條件: 最多 3GB 內存。

當內存使用達到最大限制時, 如果需要存儲新數據, 根據配置的策略(policies)的不同, Redis可能直接返回錯誤信息, 或者刪除部分老的數據。

驅逐策略

達到最大內存限制時(maxmemory), Redis 根據 maxmemory-policy 配置的策略, 來決定具體的行為。

當前版本,Redis 3.0 支持的策略包括:

noeviction: 不刪除策略, 達到最大內存限制時, 如果需要更多內存, 直接返回錯誤信息。 大多數寫命令都會導致占用更多的內存(有極少數會例外, 如 DEL )。

allkeys-lru: 所有key通用; 優先刪除最近最少使用(less recently used ,LRU) 的 key。

volatile-lru: 只限于設置了 expire 的部分; 優先刪除最近最少使用(less recently used ,LRU) 的 key。

allkeys-random: 所有key通用; 隨機刪除一部分 key。

volatile-random: 只限于設置了 expire 的部分; 隨機刪除一部分 key。

volatile-ttl: 只限于設置了 expire 的部分; 優先刪除剩余時間(time to live,TTL) 短的key。

如果沒有設置 expire 的key, 不滿足先決條件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行為, 和 noeviction(不刪除) 基本上一致。

您需要根據系統的特征, 來選擇合適的驅逐策略。 當然, 在運行過程中也可以通過命令動態設置驅逐策略, 并通過 INFO 命令監控緩存的 miss 和 hit, 來進行調優。

一般來說:

如果分為熱數據與冷數據, 推薦使用 allkeys-lru 策略。 也就是, 其中一部分key經常被讀寫. 如果不確定具體的業務特征, 那么 allkeys-lru 是一個很好的選擇。

如果需要循環讀寫所有的key, 或者各個key的訪問頻率差不多, 可以使用 allkeys-random 策略, 即讀寫所有元素的概率差不多。

假如要讓 Redis 根據 TTL 來篩選需要刪除的key, 請使用 volatile-ttl 策略。

volatile-lru 和 volatile-random 策略主要應用場景是: 既有緩存,又有持久key的實例中。 一般來說, 像這類場景, 應該使用兩個單獨的 Redis 實例。

值得一提的是, 設置 expire 會消耗額外的內存, 所以使用 allkeys-lru 策略, 可以更高效地利用內存, 因為這樣就可以不再設置過期時間了。

驅逐的內部實現

驅逐過程可以這樣理解:

客戶端執行一個命令, 導致 Redis 中的數據增加,占用更多內存。

Redis 檢查內存使用量, 如果超出 maxmemory 限制, 根據策略清除部分 key。

繼續執行下一條命令, 以此類推。

在這個過程中, 內存使用量會不斷地達到 limit 值, 然后超過, 然后刪除部分 key, 使用量又下降到 limit 值之下。

如果某個命令導致大量內存占用(比如通過新key保存一個很大的set), 在一段時間內, 可能內存的使用量會明顯超過 maxmemory 限制。

近似LRU算法

Redis 使用的并不是完全LRU算法。自動驅逐的 key , 并不一定是最滿足LRU特征的那個. 而是通過近似LRU算法, 抽取少量的 key 樣本, 然后刪除其中訪問時間最古老的那個key。

驅逐算法, 從 Redis 3.0 開始得到了巨大的優化, 使用 pool(池子) 來作為候選. 這大大提升了算法效率, 也更接近于真實的LRU算法。

在 Redis 的 LRU 算法中, 可以通過設置樣本(sample)的數量來調優算法精度。 通過以下指令配置:

maxmemory-samples 5

為什么不使用完全LRU實現? 原因是為了節省內存。但 Redis 的行為和LRU基本上是等價的. 下面是 Redis LRU 與完全LRU算法的一個行為對比圖。

測試過程中, 依次從第一個 key 開始訪問, 所以最前面的 key 才是最佳的驅逐對象。

從圖中可以看到三種類型的點, 構成了三個不同的條帶。

淺灰色部分表示被驅逐的對象。

灰色部分表示 “未被驅逐” 的對象。

綠色部分表示后面加入的對象。

在純粹的LRU算法實現中, 前半部分舊的key被釋放了。而 Redis 的 LRU 算法只是將時間較長的 key 較大概率地(probabilistically)釋放了。

如你所見, Redis 3.0 中, 5樣本的效果比 Redis 2.8 要好很多。 當然, Redis 2.8 也不錯,最后訪問的key基本上都還留在內存中. 在 Redis 3.0 中使用 10 樣本時, 已經非常接近純粹的LRU算法了。

注意,LRU只是用來預測將來可能會繼續訪問某個key的一個概率模型. 此外,如果數據訪問的情況符合冪律分布(power law), 那么對于大部分的請求來說, LRU都會表現良好。

在模擬中, 我們發現, 如果使用冪律方式訪問, 純粹的LRU和Redis的結果差別非常, 甚至看不出來。

當然也可以將樣本數量提高到10, 以額外消耗一些CPU為代價, 使得結果更接近于真實的LRU, 并通過 cache miss 統計信息來判斷差異。

設置樣本大小很容易, 使用命令 CONFIG SET maxmemory-samples <count> 即可

以上就是redis在哪里配置緩存清理策略的詳細內容，更多請關注億速云其它相關文章！