將 Redis 用作緩存時, 如果內(nèi)存空間用滿, 就會自動驅(qū)逐老的數(shù)據(jù)。 默認情況下 memcached 就是這種方式, 大部分開發(fā)者都比較熟悉。
創(chuàng)新互聯(lián)建站專注于茫崖企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站開發(fā)。茫崖網(wǎng)站建設(shè)公司,為茫崖等地區(qū)提供建站服務(wù)。全流程定制制作,專業(yè)設(shè)計,全程項目跟蹤,創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)LRU是Redis唯一支持的回收算法. 本文詳細介紹用于限制大內(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, 則表示不進行內(nèi)存限制。當然, 對32位系統(tǒng)來說有一個隱性的限制條件: 最多 3GB 內(nèi)存。
當內(nèi)存使用達到大限制時, 如果需要存儲新數(shù)據(jù), 根據(jù)配置的策略(policies)的不同, Redis可能直接返回錯誤信息, 或者刪除部分老的數(shù)據(jù)。
驅(qū)逐策略
達到大內(nèi)存限制時(maxmemory), Redis 根據(jù) maxmemory-policy 配置的策略, 來決定具體的行為。
當前版本,Redis 3.0 支持的策略包括:
noeviction: 不刪除策略, 達到大內(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ū)逐策略。 當然, 在運行過程中也可以通過命令動態(tài)設(shè)置驅(qū)逐策略, 并通過 INFO 命令監(jiān)控緩存的 miss 和 hit, 來進行調(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)存使用量會不斷地達到 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 要好很多。 當然, 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é)果差別非常, 甚至看不出來。
當然也可以將樣本數(shù)量提高到10, 以額外消耗一些CPU為代價, 使得結(jié)果更接近于真實的LRU, 并通過 cache miss 統(tǒng)計信息來判斷差異。
設(shè)置樣本大小很容易, 使用命令 CONFIG SET maxmemory-samples <count> 即可
以上就是redis在哪里配置緩存清理策略的詳細內(nèi)容,更多請關(guān)注創(chuàng)新互聯(lián)網(wǎng)站制作公司其它相關(guān)文章!
文章標題:redis怎么配置緩存清理-創(chuàng)新互聯(lián)
分享鏈接:http://aaarwkj.com/article2/jsdoc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站設(shè)計、軟件開發(fā)、網(wǎng)站設(shè)計公司、營銷型網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站營銷
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)