概述

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

• volatile-lru ： 採用最近使用最少的淘汰策略， Redis 將回收那些超時的（僅僅是超時的)鍵值對 ， 也就是它只淘汰那些超時的鍵值對。
• allkeys-lru ： 採用淘汰最少使用的策略 ， Redis將對所有的（不僅僅是超時的）鍵值對採用最近使用最少的淘汰策略。
• volatile-random：採用隨機淘汰策略刪除超時的（僅僅是超時的）鍵值對
• allkeys-random ： 採用隨機、淘汰策略刪除所有的（不僅僅是超時的）鍵值對，這個策略不常用 。
• volatile-rtl： 採用刪除存活時間最短的鍵值對策略 。
• noeviction ： 根本就不淘汰任何鍵值對 ， 當記憶體己滿時 ， 如果做讀操作，例如 get 命令 ， 它將正常工作，而做寫操作，它將返回錯誤 。 也就是說 ， 當 Redis 採用這個策略記憶體達到最大的 時候 ， 它就只能讀而不能寫了。

Redis 在預設情況下會採用 noeviction 策略。換句話說，如果記憶體己滿 ， 則不再提供寫入操作 ， 而只提供讀取操作 。 顯然這往往並不能滿足我們的要求，因為對於網際網路系統而言 ， 常常會涉及數以百萬甚至更多的使用者 ， 所以往往需要設定回收策略。

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

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