Redis-17Redis内存回收策略
文章目錄
- 概述
- maxmemory-policy 參數(shù)
- 主動(dòng)清理策略
- 【針對(duì)設(shè)置了過(guò)期時(shí)間的key做處理】
- 【 針對(duì)所有的key做處理】
- 【 不處理 （默認(rèn)）】
- 策略選擇
- maxmemory-sample
概述
Redi s 也會(huì)因?yàn)閮?nèi)存不足而產(chǎn)生錯(cuò)誤 ， 也可能因?yàn)榛厥者^(guò)久而導(dǎo)致系統(tǒng)長(zhǎng)期的停頓，因此掌握?qǐng)?zhí)行回收策略十分有必要。在 Redis 的配置文件中，當(dāng) Redis 的內(nèi)存達(dá)到規(guī)定的最大值時(shí)，允許配置 6 種策略中的一種進(jìn)行淘汰鍵值，并且將一些鍵值對(duì)進(jìn)行回收。
maxmemory-policy 參數(shù)
# Set a memory usage limit to the specified amount of bytes. # When the memory limit is reached Redis will try to remove keys # according to the eviction policy selected (see maxmemory-policy). # # If Redis can't remove keys according to the policy, or if the policy is # set to 'noeviction', Redis will start to reply with errors to commands # that would use more memory, like SET, LPUSH, and so on, and will continue # to reply to read-only commands like GET. # # This option is usually useful when using Redis as an LRU or LFU cache, or to # set a hard memory limit for an instance (using the 'noeviction' policy). # # WARNING: If you have slaves attached to an instance with maxmemory on, # the size of the output buffers needed to feed the slaves are subtracted # from the used memory count, so that network problems / resyncs will # not trigger a loop where keys are evicted, and in turn the output # buffer of slaves is full with DELs of keys evicted triggering the deletion # of more keys, and so forth until the database is completely emptied. # # In short... if you have slaves attached it is suggested that you set a lower # limit for maxmemory so that there is some free RAM on the system for slave # output buffers (but this is not needed if the policy is 'noeviction'). # # maxmemory <bytes># MAXMEMORY POLICY: how Redis will select what to remove when maxmemory # is reached. You can select among five behaviors: # # volatile-lru -> Evict using approximated LRU among the keys with an expire set. # allkeys-lru -> Evict any key using approximated LRU. # volatile-lfu -> Evict using approximated LFU among the keys with an expire set. # allkeys-lfu -> Evict any key using approximated LFU. # volatile-random -> Remove a random key among the ones with an expire set. # allkeys-random -> Remove a random key, any key. # volatile-ttl -> Remove the key with the nearest expire time (minor TTL) # noeviction -> Don't evict anything, just return an error on write operations. # # LRU means Least Recently Used # LFU means Least Frequently Used # # Both LRU, LFU and volatile-ttl are implemented using approximated # randomized algorithms. # # Note: with any of the above policies, Redis will return an error on write # operations, when there are no suitable keys for eviction. # # At the date of writing these commands are: set setnx setex append # incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd # sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby # zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby # getset mset msetnx exec sort # # The default is: # # maxmemory-policy noeviction主動(dòng)清理策略
主動(dòng)清理策略在Redis 4.0 之前一共實(shí)現(xiàn)了 6 種內(nèi)存淘汰策略，在 4.0 之后，又增加了 2 種策略，總共8種：
【針對(duì)設(shè)置了過(guò)期時(shí)間的key做處理】
- volatile-ttl：在篩選時(shí)，會(huì)針對(duì)設(shè)置了過(guò)期時(shí)間的鍵值對(duì)，根據(jù)過(guò)期時(shí)間的先后進(jìn)行刪除，越早過(guò)期的越先被刪除。
- volatile-random：就像它的名稱一樣，在設(shè)置了過(guò)期時(shí)間的鍵值對(duì)中，進(jìn)行隨機(jī)刪除。
- volatile-lru：會(huì)使用 LRU 算法篩選設(shè)置了過(guò)期時(shí)間的鍵值對(duì)刪除。
- volatile-lfu：會(huì)使用 LFU 算法篩選設(shè)置了過(guò)期時(shí)間的鍵值對(duì)刪除
【 針對(duì)所有的key做處理】
- allkeys-random：從所有鍵值對(duì)中隨機(jī)選擇并刪除數(shù)據(jù)。
- allkeys-lru：使用 LRU 算法在所有數(shù)據(jù)中進(jìn)行篩選刪除。
- allkeys-lfu：使用 LFU 算法在所有數(shù)據(jù)中進(jìn)行篩選刪除。
【 不處理 （默認(rèn)）】
noeviction：不會(huì)剔除任何數(shù)據(jù)，拒絕所有寫(xiě)入操作并返回客戶端錯(cuò)誤信息"(error) OOM command not allowed when used memory"，此時(shí)Redis只響應(yīng)讀操作。
Redis 在默認(rèn)情況下會(huì)采用 noeviction 策略。換句話說(shuō)，如果內(nèi)存己滿 ， 則不再提供寫(xiě)入操作 ， 而只提供讀取操作 。 顯然這往往并不能滿足我們的要求，因?yàn)閷?duì)于互聯(lián)網(wǎng)系統(tǒng)而言 ， 常常會(huì)涉及數(shù)以百萬(wàn)甚至更多的用戶 ， 所以往往需要設(shè)置回收策略。
策略選擇
LRU 算法（Least Recently Used，最近最少使用）：淘汰很久沒(méi)被訪問(wèn)過(guò)的數(shù)據(jù)，以最近一次訪問(wèn)時(shí)間作為參考
LFU 算法（Least Frequently Used，最不經(jīng)常使用）：淘汰最近一段時(shí)間被訪問(wèn)次數(shù)最少的數(shù)據(jù)，以次數(shù)作為參考
需要指出的是 ： LRU 算法或者 TTL 算法都是不是很精確算法，而是一個(gè)近似的算法。 Redis 不會(huì)通過(guò)對(duì)全部的鍵值對(duì)進(jìn)行比較來(lái)確定最精確的時(shí)間值，從而確定刪除哪個(gè)鍵值對(duì) ， 因?yàn)檫@將消耗太多的時(shí)間 ， 導(dǎo)致回收垃圾執(zhí)行的時(shí)間太長(zhǎng) ， 造成服務(wù)停頓.
當(dāng)存在熱點(diǎn)數(shù)據(jù)時(shí)，LRU的效率很好，但偶發(fā)性的、周期性的批量操作會(huì)導(dǎo)致LRU命中率急劇下降，緩存污染情況比較嚴(yán)重。這時(shí)使用LFU可能更好點(diǎn)
根據(jù)自身業(yè)務(wù)類(lèi)型，配置好maxmemory-policy(默認(rèn)是noeviction)，推薦使用volatile-lru。
maxmemory-sample
而在Redis 的默認(rèn)配置文件中 ， 存在著參數(shù) maxmemory-sample
# LRU, LFU and minimal TTL algorithms are not precise algorithms but approximated # algorithms (in order to save memory), so you can tune it for speed or # accuracy. For default Redis will check five keys and pick the one that was # used less recently, you can change the sample size using the following # configuration directive. # # The default of 5 produces good enough results. 10 Approximates very closely # true LRU but costs more CPU. 3 is faster but not very accurate. # # maxmemory-samples 5當(dāng)設(shè)置 maxmemory-samples越大，則 Redis 刪除的就越精確，但是與此同時(shí)帶來(lái)不利的是， Redis 也就需要花更多的時(shí)去計(jì)算匹配更為精確的值 。
回收超時(shí)策略的缺點(diǎn)是必須指明超時(shí)的鍵值對(duì) ，這會(huì)給程序開(kāi)發(fā)帶來(lái)一些設(shè)置超時(shí)的代碼，無(wú)疑增加了開(kāi)發(fā)者的工作量。
對(duì)所有的鍵值對(duì)進(jìn)行回收，有可能把正在使用的鍵值對(duì)刪掉，增加了存儲(chǔ)的不穩(wěn)定性。
對(duì)于垃圾回收的策略，還需要注意的是回收的時(shí)間，因?yàn)樵?Redis 對(duì)垃圾的回收期間， 會(huì)造成系統(tǒng)緩慢。
因此，控制其回收時(shí)間有一定好處，只是這個(gè)時(shí)間不能過(guò)短或過(guò)長(zhǎng)。過(guò)短則會(huì)造成回收次數(shù)過(guò)于頻繁，過(guò)長(zhǎng)則導(dǎo)致系統(tǒng)單次垃圾回收停頓時(shí)間過(guò)長(zhǎng)，都不利于系統(tǒng)的穩(wěn)定性，這些都需要設(shè)計(jì)者在實(shí)際的工作中進(jìn)行思考 。
如果不設(shè)置最大內(nèi)存，當(dāng) Redis 內(nèi)存超出物理內(nèi)存限制時(shí)，內(nèi)存的數(shù)據(jù)會(huì)開(kāi)始和磁盤(pán)產(chǎn)生頻繁的交換 (swap)，會(huì)讓 Redis 的性能急劇下降。
總結(jié)
以上是生活随笔為你收集整理的Redis-17Redis内存回收策略的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Redis-16Redis备份(持久化)
- 下一篇： Redis-18Redis主从同步