别再问我 Redis 内存满了该怎么办了

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [www.tuicool.com](https://www.tuicool.com/articles/Uv63qiu)

![](https://img1.tuicool.com/2ueM3ym.jpg!web)

`Redis` 的文章，我之前写过一篇关于 **「Redis 的缓存的三大问题」** ，累计阅读也快 800 了，对于还只有 3k 左右的粉丝量，能够达到这个阅读量，已经是比较难了。

这说明那篇文章写的还过得去，收到很多人的阅读肯定，感兴趣的看一下 [ [看完这篇 Redis 缓存三大问题，保你能和面试官互扯。](http://mp.weixin.qq.com/s?__biz=MzU1MzE4OTU0OQ==&mid=2247483977&idx=1&sn=e42c9aedb8bb1c914afa5f2f74324d1f&chksm=fbf7eb8bcc80629dac2c4074c393ca672915bab26864a277251883f1f6c2a6d96338dae3e5b0&scene=21#wechat_redirect) ]。

「三大缓存问题」只是 Redis 的其中的一小部分的知识点，想要深入学习 Redis 还要学习比较多的知识点。

那么今天就带来了一个面试常问的一个问题： **「假如你的 Redis 内存满了怎么办？」** 长期的把 Redis 作为缓存使用，总有一天会存满的时候对吧。

这个面试题不慌呀，在 Redis 中有配置参数 `maxmemory` 可以 **「设置 Redis 内存的大小」** 。

在 Redis 的配置文件 `redis.conf` 文件中，配置 `maxmemory` 的大小参数如下所示：

实际生产中肯定不是 `100mb` 的大小哈，不要给误导了，这里我只是让大家认识这个参数，一般小的公司都是设置为 `3G` 左右的大小。

除了在配置文件中配置生效外，还可以通过命令行参数的形式，进行配置，具体的配置命令行如下所示：

```
//获取maxmemory配置参数的大小127.0.0.1:6379> config get maxmemory//设置maxmemory参数为100mb127.0.0.1:6379> config set maxmemory 100mb
```

倘若实际的存储中超出了 Redis 的配置参数的大小时，Redis 中有 **「淘汰策略」** ，把 「需要淘汰的 key 给淘汰掉，整理出干净的一块内存给新的 key 值使用」 。

接下来我们就详细的聊一聊 Redis 中的淘汰策略，并且深入的理解每个淘汰策略的原理和应用的场景。

淘汰策略
----

Redis 提供了 **「6 种的淘汰策略」** ，其中默认的是 `noeviction` ，这 6 种淘汰策略如下：

1.  `noeviction` ( **「默认策略」** )：若是内存的大小达到阀值的时候，所有申请内存的指令都会报错。
    
2.  `allkeys-lru` ：所有 key 都是使用 **「LRU 算法」** 进行淘汰。
    
3.  `volatile-lru` ：所有 **「设置了过期时间的 key 使用 LRU 算法」** 进行淘汰。
    
4.  `allkeys-random` ：所有的 key 使用 **「随机淘汰」** 的方式进行淘汰。
    
5.  `volatile-random` ：所有 **「设置了过期时间的 key 使用随机淘汰」** 的方式进行淘汰。
    
6.  `volatile-ttl` ：所有设置了过期时间的 key **「根据过期时间进行淘汰，越早过期就越快被淘汰」** 。

假如在 Redis 中的数据有 **「一部分是热点数据，而剩下的数据是冷门数据」** ，或者 **「我们不太清楚我们应用的缓存访问分布状况」** ，这时可以使用 `allkeys-lru` 。

假如所有的数据访问的频率大概一样，就可以使用 `allkeys-random` 的淘汰策略。

假如要配置具体的淘汰策略，可以在 `redis.conf` 配置文件中配置，具体配置如下所示：

这只需要把注释给打开就可以，并且配置指定的策略方式，另一种的配置方式就是命令的方式进行配置，具体的执行命令如下所示：

```
// 获取maxmemory-policy配置127.0.0.1:6379> config get maxmemory-policy// 设置maxmemory-policy配置为allkeys-lru127.0.0.1:6379> config set maxmemory-policy allkeys-lru
```

在介绍 6 种的淘汰策略方式的时候，说到了 LRU 算法， **「那么什么是 LRU 算法呢？」**

LRU 算法
------

`LRU(Least Recently Used)` 即表示最近最少使用，也就是在最近的时间内最少被访问的 key，算法根据数据的历史访问记录来进行淘汰数据。

它的核心的思想就是： 「假如一个 key 值在最近很少被使用到，那么在将来也很少会被访问」 。

实际上 Redis 实现的 LRU 并不是真正的 LRU 算法，也就是名义上我们使用 LRU 算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。

Redis 使用的是近似的 LRU 算法， 「通过随机采集法淘汰 key，每次都会随机选出 5 个 key，然后淘汰里面最近最少使用的 key」 。

这里的 5 个 key 只是默认的个数，具体的个数也可以在配置文件中进行配置，在配置文件中的配置如下图所示：

当近似 LRU 算法取值越大的时候就会越接近真实的 LRU 算法，可以这样理解，因为 「取值越大那么获取的数据就越全，淘汰中的数据的就越接近最近最少使用的数据」 。

那么为了实现根据时间实现 LRU 算法，Redis 必须为每个 key 中额外的增加一个内存空间用于存储每个 key 的时间，大小是 3 字节。

在 Redis 3.0 中对近似的 LRU 算法做了一些优化，Redis 中会维护大小是 `16` 的一个候选池的内存。

当第一次随机选取的采样数据，数据都会被放进候选池中，并且候选池中的数据会根据时间进行排序。

当第二次以后选取的数据，只有 **「小于候选池内的最小时间」** 的才会被放进候选池中。

当某一时刻候选池的数据满了，那么时间最大的 key 就会被挤出候选池。当执行淘汰时，直接从候选池中选取最近访问时间最小的 key 进行淘汰。

这样做的目的就是选取出最近似符合最近最少被访问的 key 值，能够正确的淘汰 key 值，因为随机选取的样本中的最小时间可能不是真正意义上的最小时间。

但是 LRU 算法有一个弊端：就是假如一个 key 值在以前都没有被访问到，然而最近一次被访问到了，那么就会认为它是热点数据，不会被淘汰。

然而有些数据以前经常被访问到，只是最近的时间内没有被访问到，这样就导致这些数据很可能被淘汰掉，这样一来就会出现误判而淘汰热点数据。

于是在 Redis 4.0 的时候除了 LRU 算法，新加了一种 LFU 算法， **「那么什么是 LFU 算法算法呢？」**

LFU 算法
------

`LFU(Least Frequently Used)` 即表示最近频繁被使用，也就是最近的时间段内，频繁被访问的 key，它以最近的时间段的被访问次数的频率作为一种判断标准。

它的核心思想就是：根据 key 最近被访问的频率进行淘汰，比较少被访问的 key 优先淘汰，反之则优先保留。

LFU 算法反映了一个 key 的热度情况，不会因为 LRU 算法的偶尔一次被访问被认为是热点数据。

在 LFU 算法中支持 `volatile-lfu` 策略和 `allkeys-lfu` 策略。

以上介绍了 Redis 的 6 种淘汰策略，这 6 种淘汰策略旨在告诉我们怎么做，但是什么时候做？这个还没说，下面我们就来详细的了解 Redis 什么时候执行淘汰策略。

删除过期键策略
-------

在 Redis 中有三种删除的操作此策略，分别是：

1.  「定时删除」：创建一个定时器，定时的执行对 key 的删除操作。
    
2.  「惰性删除」：每次只有再访问 key 的时候，才会检查 key 的过期时间，若是已经过期了就执行删除。
    
3.  「定期删除」：每隔一段时间，就会检查删除掉过期的 key。

「定时删除」对于 **「内存来说是友好的」** ，定时清理出干净的空间，但是对于 **「cpu 来说并不是友好的」** ，程序需要维护一个定时器，这就会占用 cpu 资源。

「惰性的删除」对于 **「cpu 来说是友好的」** ，cpu 不需要维护其它额外的操作，但是对于 **「内存来说是不友好的」** ，因为要是有些 key 一直没有被访问到，就会一直占用着内存。

定期删除是上面两种方案的折中方案 **，每隔一段时间删除过期的 key，也就是根据具体的业务，合理的取一个时间定期的删除 key**。

通过 **「最合理控制删除的时间间隔」** 来删除 key，减 **「少对 cpu 的资源的占用消耗」** ，使删除操作合理化。

RDB 和 AOF 的淘汰处理
---------------

在 Redis 中持久化的方式有两种 `RDB` 和 `AOF` ，具体这两种详细的持久化介绍，可以参考这一篇文章 [ [面试造飞机系列：面对 Redis 持久化连环 Call，你还顶得住吗？](http://mp.weixin.qq.com/s?__biz=MzU1MzE4OTU0OQ==&mid=2247484021&idx=1&sn=4c228c705cfd524db3cf27425fde1ba0&chksm=fbf7ebb7cc8062a138b9baad194548983095806f8f15a82e1a95f18f19999c76d750aa91b93b&scene=21#wechat_redirect) ]。

在 RDB 中是以快照的形式获取内存中某一时间点的数据副本，在创建 RDB 文件的时候可以通过 `save` 和 `bgsave` 命令执行创建 RDB 文件。

「这两个命令都不会把过期的 key 保存到 RDB 文件中」，这样也能达到删除过期 key 的效果。

当在启动 Redis 载入 RDB 文件的时候， `Master` 不会把过期的 key 载入，而 `Slave` 会把过期的 key 载入。

在 AOF 模式下，Redis 提供了 Rewite 的优化措施，执行的命令分别是 `REWRITEAOF` 和 `BGREWRITEAOF` ， 「这两个命令都不会把过期的 key 写入到 AOF 文件中，也能删除过期 key」 。

```
特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

```

![](https://img1.tuicool.com/eEjEFnz.jpg!web)

```
长按订阅更多精彩▼

```

![](https://img0.tuicool.com/rEFzyej.jpg!web)

如有收获，点个在看，诚挚感谢