如果使用Redis的時候，不合理使用內存，把什么東西都放在內存里面，又不設置過期時間，就會導致內存的堆積越來越大。根據28法則，除了20%的熱點數據之外，剩余的80%的非熱點或不怎么重要的數據都在占用內存空間，這時就要使用一種淘汰策略來釋放一些內存。Redis中提供了多種內存回收策略，當內存容量不足時，為了保證程序的運行，這時就不得不淘汰內存中的一些對 象，釋放這些對象占用的空間，那么選擇淘汰哪些對象呢？
在redis.conf 里面有個配置策略 maxmemory-policy ，它有幾個可選值：
noeviction： 默認的策略，即當內存使用達到閾值的時候，所有引起申請內存的命令都會報錯；
allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰 。
適用場景： 如果我們的應用對緩存的訪問都是相對熱點數據，就可以選擇這個策略；
allkeys-random：隨機移除某個key。
適合的場景：如果我們的應用對於緩存key的訪問概率相等，則可以使用這個策略。
從已經設置了過期時間的key中去選擇
volatile-random：從已設置過期時間的數據集（server.db[i].expires）中任意選擇數據淘汰。
volatile-lru：從已設置過期時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰。
volatile-ttl：從已設置過期時間的數據集（server.db[i].expires）中挑選將要過期的數據淘汰；適合場景：這種策略使我們可以向Redis提示哪些key更適合被淘汰，可以自己控制 。
那么怎樣保證Redis里面的數據都是熱點數據？
可以使用LRU的淘汰策略，選擇最近最少使用的數據全部淘汰掉，剩下的就是經常訪問的數據，都是熱點數據。
總結
實際上Redis實現的LRU並不是可靠的LRU，也就是名義上我們使用LRU算法淘汰內存數據，但是實際上被淘汰的鍵 並不一定是真正的最少使用的數據，這里就要權衡了，如果需要在所有的數據中搜索符合條件的數 據，那么一定會增加系統的開銷，Redis是單線程的，所以耗時的操作會謹慎一些。為了在一定成本內實現相對的 LRU，早期的Redis版本是基於采樣的LRU，也就是放棄了從所有數據中搜索解，改為采樣空間搜索優解。Redis3.0 版本之后，Redis作者對於基於采樣的LRU進行了一些優化，目的是在一定的成本范圍內讓結果更靠近真實的LRU。