Redis也会因为内存不足而产生错误 ， 也可能因为回收过久而导致系统长期的停顿，因此掌握执行回收策略十分有必要。在 Redis 的配置文件中，当 Redis 的内存达到规定的最大值时，允许配置 6 种策略中的一种进行淘汰键值，并且将一些键值对进行回收。
maxmemory-policy 参数 主动清理策略主动清理策略在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
当设置 maxmemory-samples越大，则 Redis 删除的就越精确，但是与此同时带来不利的是， Redis 也就需要花更多的时去计算匹配更为精确的值 。
回收超时策略的缺点是必须指明超时的键值对 ，这会给程序开发带来一些设置超时的代码，无疑增加了开发者的工作量。
对所有的键值对进行回收，有可能把正在使用的键值对删掉，增加了存储的不稳定性。
对于垃圾回收的策略，还需要注意的是回收的时间，因为在 Redis 对垃圾的回收期间， 会造成系统缓慢。
因此，控制其回收时间有一定好处，只是这个时间不能过短或过长。过短则会造成回收次数过于频繁，过长则导致系统单次垃圾回收停顿时间过长，都不利于系统的稳定性，这些都需要设计者在实际的工作中进行思考 。
如果不设置最大内存，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)，会让 Redis 的性能急剧下降。
到此这篇关于 Redis内存回收策略的文章就介绍到这了,更多相关 Redis内存回收内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
