文章目錄

• 概述
• maxmemory-policy 參數
• 主動清理策略
• • 【針對設置了過期時間的key做處理】
  • 【 針對所有的key做處理】
  • 【 不處理 （默認）】
• 策略選擇
• maxmemory-sample

概述

Redi s 也會因為內存不足而產生錯誤 ， 也可能因為回收過久而導致系統長期的停頓，因此掌握執行回收策略十分有必要。在 Redis 的配置文件中，當 Redis 的內存達到規定的最大值時，允許配置 6 種策略中的一種進行淘汰鍵值，并且將一些鍵值對進行回收。

---

maxmemory-policy 參數

# 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

---

主動清理策略

主動清理策略在Redis 4.0 之前一共實現了 6 種內存淘汰策略，在 4.0 之后，又增加了 2 種策略，總共8種：

【針對設置了過期時間的key做處理】

• volatile-ttl：在篩選時，會針對設置了過期時間的鍵值對，根據過期時間的先后進行刪除，越早過期的越先被刪除。
• volatile-random：就像它的名稱一樣，在設置了過期時間的鍵值對中，進行隨機刪除。
• volatile-lru：會使用 LRU 算法篩選設置了過期時間的鍵值對刪除。
• volatile-lfu：會使用 LFU 算法篩選設置了過期時間的鍵值對刪除

---

【 針對所有的key做處理】

• allkeys-random：從所有鍵值對中隨機選擇并刪除數據。
• allkeys-lru：使用 LRU 算法在所有數據中進行篩選刪除。
• allkeys-lfu：使用 LFU 算法在所有數據中進行篩選刪除。

---

【 不處理 （默認）】

noeviction：不會剔除任何數據，拒絕所有寫入操作并返回客戶端錯誤信息"(error) OOM command not allowed when used memory"，此時Redis只響應讀操作。

Redis 在默認情況下會采用 noeviction 策略。換句話說，如果內存己滿 ， 則不再提供寫入操作 ， 而只提供讀取操作 。 顯然這往往并不能滿足我們的要求，因為對于互聯網系統而言 ， 常常會涉及數以百萬甚至更多的用戶 ， 所以往往需要設置回收策略。

---

策略選擇

LRU 算法（Least Recently Used，最近最少使用）：淘汰很久沒被訪問過的數據，以最近一次訪問時間作為參考

LFU 算法（Least Frequently Used，最不經常使用）：淘汰最近一段時間被訪問次數最少的數據，以次數作為參考

需要指出的是 ： LRU 算法或者 TTL 算法都是不是很精確算法，而是一個近似的算法。 Redis 不會通過對全部的鍵值對進行比較來確定最精確的時間值，從而確定刪除哪個鍵值對 ， 因為這將消耗太多的時間 ， 導致回收垃圾執行的時間太長 ， 造成服務停頓.

當存在熱點數據時，LRU的效率很好，但偶發性的、周期性的批量操作會導致LRU命中率急劇下降，緩存污染情況比較嚴重。這時使用LFU可能更好點

根據自身業務類型，配置好maxmemory-policy(默認是noeviction)，推薦使用volatile-lru。

---

maxmemory-sample

而在Redis 的默認配置文件中 ， 存在著參數 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

當設置 maxmemory-samples越大，則 Redis 刪除的就越精確，但是與此同時帶來不利的是， Redis 也就需要花更多的時去計算匹配更為精確的值 。

回收超時策略的缺點是必須指明超時的鍵值對 ，這會給程序開發帶來一些設置超時的代碼，無疑增加了開發者的工作量。

對所有的鍵值對進行回收，有可能把正在使用的鍵值對刪掉，增加了存儲的不穩定性。

對于垃圾回收的策略，還需要注意的是回收的時間，因為在 Redis 對垃圾的回收期間， 會造成系統緩慢。

因此，控制其回收時間有一定好處，只是這個時間不能過短或過長。過短則會造成回收次數過于頻繁，過長則導致系統單次垃圾回收停頓時間過長，都不利于系統的穩定性，這些都需要設計者在實際的工作中進行思考 。

如果不設置最大內存，當 Redis 內存超出物理內存限制時，內存的數據會開始和磁盤產生頻繁的交換 (swap)，會讓 Redis 的性能急劇下降。

總結

以上是生活随笔為你收集整理的Redis-17Redis内存回收策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。