redis怎么配置緩存清理

將 Redis 用作緩存時, 如果內(nèi)存空間用滿, 就會自動驅(qū)逐老的數(shù)據(jù)。 默認(rèn)情況下 memcached 就是這種方式, 大部分開發(fā)者都比較熟悉。

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

maxmemory 配置指令

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

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

maxmemory 100mb

將 maxmemory 設(shè)置為 0, 則表示不進(jìn)行內(nèi)存限制。當(dāng)然, 對32位系統(tǒng)來說有一個隱性的限制條件: 最多 3GB 內(nèi)存。

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

驅(qū)逐策略

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

當(dāng)前版本,Redis 3.0 支持的策略包括:

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

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

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

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

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

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

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

您需要根據(jù)系統(tǒng)的特征, 來選擇合適的驅(qū)逐策略。 當(dāng)然, 在運行過程中也可以通過命令動態(tài)設(shè)置驅(qū)逐策略, 并通過 INFO 命令監(jiān)控緩存的 miss 和 hit, 來進(jìn)行調(diào)優(yōu)。

一般來說:

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

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

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

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

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

驅(qū)逐的內(nèi)部實現(xiàn)

驅(qū)逐過程可以這樣理解:

客戶端執(zhí)行一個命令, 導(dǎo)致 Redis 中的數(shù)據(jù)增加,占用更多內(nèi)存。

Redis 檢查內(nèi)存使用量, 如果超出 maxmemory 限制, 根據(jù)策略清除部分 key。

繼續(xù)執(zhí)行下一條命令, 以此類推。

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

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

近似LRU算法

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

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

在 Redis 的 LRU 算法中, 可以通過設(shè)置樣本(sample)的數(shù)量來調(diào)優(yōu)算法精度。 通過以下指令配置:

maxmemory-samples 5

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

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

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

淺灰色部分表示被驅(qū)逐的對象。

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

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

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

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

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

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

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

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

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