當 Redis 內存超出物理內存限制時，內存的數據會開始和磁盤產生頻繁的交換 (swap)。交換會讓 Redis 的性能急劇降低，對於訪問量比較頻繁的 Redis 來講，這樣龜速的存取效率基本上等於不可用。算法
在生產環境中咱們是不容許 Redis 出現交換行爲的，爲了限制最大使用內存，Redis 提供了配置參數 maxmemory 來限制內存超出指望大小。緩存
當實際內存超出 maxmemory 時，Redis 提供了幾種可選策略 (maxmemory-policy) 來讓用戶本身決定該如何騰出新的空間以繼續提供讀寫服務。dom
noeviction 不會繼續服務寫請求 (DEL 請求能夠繼續服務)，讀請求能夠繼續進行。這樣能夠保證不會丟失數據，可是會讓線上的業務不能持續進行。這是默認的淘汰策略。性能
volatile-lru 嘗試淘汰設置了過時時間的 key，最少使用的 key 優先被淘汰。沒有設置過時時間的 key 不會被淘汰，這樣能夠保證須要持久化的數據不會忽然丟失。淘汰最近最少使用的key對象
volatile-ttl 跟上面同樣，除了淘汰的策略不是 LRU，而是 key 的剩餘壽命 ttl 的值，ttl 越小越優先被淘汰。內存
volatile-random 跟上面同樣，不過淘汰的 key 是過時 key 集合中隨機的 key。淘汰隨機的key數據io
allkeys-lru 區別於 volatile-lru，這個策略要淘汰的 key 對象是全體的 key 集合，而不僅是過時的 key 集合。這意味着沒有設置過時時間的 key 也會被淘汰。效率
allkeys-random 跟上面同樣，不過淘汰的策略是隨機的 key。配置
volatile-xxx 策略只會針對帶過時時間的 key 進行淘汰，allkeys-xxx 策略會對全部的 key 進行淘汰。若是你只是拿 Redis 作緩存，那應該使用 allkeys-xxx，客戶端寫緩存時沒必要攜帶過時時間。若是你還想同時使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，這樣能夠保留沒有設置過時時間的 key，它們是永久的 key 不會被 LRU 算法淘汰。請求
設置緩存的最大內存+ 淘汰策略:
maxmemory <bytes> maxmemory-policy noeviction