一、Redis内存满了怎么办

长期把Redis做缓存用，总有一天Redis内存会满的，怎么处理呢？

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

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

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

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(Least Frequently Used)即表示近频繁被使用，也就是近的时间段内，频繁被访问的key，它以近的时间段的被访问次数的频率作为一种判断标准。

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

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

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

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

在Redis中持久化的方式有两种 RDB和 AOF

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

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

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

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

RDB是一种快照存储持久化方式，具体就是将 Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为 dump.rdb，而在 Redis服务器启动时，会重新加载 dump.rdb文件的数据到内存当中恢复数据。

开启 RDB持久化方式很简单，客户端可以通过向 Redis服务器发送 save或 bgsave命令让服务器生成 rdb文件，或者通过服务器配置文件指定触发 RDB条件。

当客户端向服务器发送 save命令请求进行持久化时，服务器会阻塞 save命令之后的其他客户端的请求，直到数据同步完成。

与 save命令不同， bgsave命令是一个异步*作。

当客户端发服务发出 bgsave命令时， Redis服务器主进程会 forks一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。

所以，与 save命令相比， Redis服务器在处理 bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求，但 forks子进程是同步的，所以 forks子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。

除了通过客户端发送命令外，还有一种方式，就是在 Redis配置文件中的 save指定到达触发RDB持久化的条件，比如【多少秒内至少达到多少写*作】就开启 RDB数据同步。

例如我们可以在配置文件redis.conf指定如下的选项：

之后在启动服务器时加载配置文件。

这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。

介绍了三种让服务器生成rdb文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：

Redis的另外一个持久化方式： AOF(Append-only file)。

与 RDB存储某个时刻的快照不同， AOF持久化方式会记录客户端对服务器的每一次写*作命令，并将这些写*作以 Redis协议追加保存到以后缀为 aof文件末尾，在Redis服务器重启时，会加载并运行 aof文件的命令，以达到恢复数据的目的。

Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的redis.conf文件：

在上面的配置文件中，我们可以通过 appendfsync选项指定写入策略,有三个选项

客户端的每一个写*作都保存到 aof文件当，这种策略很安全，但是每个写请注都有IO*作，所以也很慢。

appendfsync的默认写入策略，每秒写入一次 aof文件，因此，多可能会丢失1s的数据。

Redis服务器不负责写入 aof，而是交由*作系统来处理什么时候写入 aof文件。更快，但也是不安全的选择，不推荐使用。

AOF将客户端的每一个写*作都追加到 aof文件末尾，比如对一个key多次执行incr命令，这时候， aof保存每一次命令到aof文件中，aof文件会变得非常大。

aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的少命令集，比如上面的例子中那么多条命令，可以重写为：

通过在redis.conf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写，这种方式会在每次fsync时都重写，影响服务器性能，因此默认值为no，不推荐使用。

客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。

AOF重写方式也是异步*作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理，如下所示：

在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。

AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。

我们可以从几个方面对比一下RDB与AOF,在应用时，要根本自己的实际需求，选择RDB或者AOF，其实，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO*作，会严重影响服务器性能，因此有时候不得不做出选择。

当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。

二、Redis内存满了会怎么样

通过在Redis安装目录下面的redis.conf配置文件中添加以下配置设置内存大小

redis的配置文件不一定使用的是安装目录下面的redis.conf文件，启动redis服务的时候是可以传一个参数指定redis的配置文件的

Redis支持运行时通过命令动态修改内存大小

既然可以设置Redis大占用内存大小，那么配置的内存就有用完的时候。那在内存用完的时候，还继续往Redis里面添加数据不就没内存可用了吗？

实际上Redis定义了几种策略用来处理这种情况：

当使用volatile-lru、volatile-random、volatile-ttl这三种策略时，如果没有key可以被淘汰，则和noeviction一样返回错误

通过配置文件设置淘汰策略（修改redis.conf文件）：

Redis使用的是近似LRU算法，它跟常规的LRU算法还不太一样。近似LRU算法通过随机采样法淘汰数据，每次随机出5（默认）个key，从里面淘汰掉近少使用的key。

可以通过maxmemory-samples参数修改采样数量：

maxmenory-samples配置的越大，淘汰的结果越接近于严格的LRU算法

Redis为了实现近似LRU算法，给每个key增加了一个额外增加了一个24**t的字段，用来存储该key后一次被访问的时间。

Redis3.0对近似LRU算法进行了一些优化。新算**维护一个候选池（大小为16），池中的数据根据访问时间进行排序，第一次随机选取的key都会放入池中，随后每次随机选取的key只有在访问时间小于池中小的时间才会放入池中，直到候选池被放满。当放满后，如果有新的key需要放入，则将池中后访问时间大（近被访问）的移除。

当需要淘汰的时候，则直接从池中选取近访问时间小（久没被访问）的key淘汰掉就行。

三、Redis内存配置和淘汰策略

1.在redis安装目录下找到redis.conf，打开找到如下行：

其中的maxmemory<bytes>即为大内存配置项，默认是注释掉的会采用默认的大内存大小：在64位*作系统下不限制内存大小，在32位*作系统下多使用3GB。

这里结果为0表示未手动指定过大内存，采用默认的大内存。

一般推荐Redis设置内存为大物理内存的四分之三。

1.在配置文件redis.conf中指定maxmemory参数，例如，如果大内存是200M，则在配置文件中添加 maxmemory 209751200；

2.通过命令 config set maxmemory 209751200设置，注意，这里如果是通过命令行设置的大内存大小，在配置文件redis.conf中并不会添加 maxmemory 209751200这一行内容。

当Redis达到大的可用内存时，再向其中存入数据则会报OOM，因此，要避免无限制存入数据导致OOM，则需要采用合适的内存淘汰策略。

在讨论Redis的内存淘汰策略之前，我们要先对Redis中过期键的删除机制有个大体的了解；实际上，过期键的删除策略有三种，每种策略下过期键的删除时机均不同。

所谓定时删除，就是在设置键的过期时间的同时，创建一个定时器，让定时器在键的过期时间来临时，立即删除对键的删除*作。其能够对过期键进行立即删除，对内存是友好的，但是因为要维护定时器，对cpu是不友好的。

所谓惰性删除，就是放任过期键不管，但每次获取键时，都检查取得的键是否过期，如果过期的话，就删除该键。如果没有过期，就返回该键。惰性删除对cpu友好，但是由于其无法主动删除过期键，当过期键大量积聚时会占用很大内存，对内存不友好。

所谓定期删除，是前两种删除策略的一种折中。会每隔一段时间执行一次删除过期键*作，并通过限制*作执行的时长和频率来减少删除*作对cpu时间的影响。

定期删除会周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度，其特点为：

a）CPU占用设置有峰值，检测频度可自定义设置。

b）内存压力有限，长期占用内存的冷数据会被持续清理。

总结下来，定期删除会周期性抽查存储空间（随机抽查、重点抽查）。

定期删除的难点在于如何确定产出*作执行的时长和频率，如果删除*作执行的太过频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将CPU时间过多的消耗在删除键上面。如果删除*作执行的太少，或者执行的时间太短，定期删除策略又会和惰性删除策略一样，出现内存浪费的情况。因此，必须合理的设置定期删除策略的执行时长和执行频率。

定期删除在一定程度上是一种合理有效的过期键删除策略，但是由于其在执行时长和执行频度的局限性，必须要有另一种机制（策略）确保内存能够获得回收，因此，就需要引入内存淘汰策略。

在redis.conf中指出内存淘汰策略有有以下八种：

1. volatile-lru：从已设置过期时间的key中挑选近少使用的数据淘汰；

2. allkeys-lru：从全部key中挑选近少使用的数据淘汰；

3. volatile-lfu：从已设置过期时间的key中挑选使用频率低的数据淘汰；

4. allkeys-lfu：从全部key中挑选使用频率低的数据淘汰；

5. volatile-random：从已设置过期时间的key中任意选择数据淘汰；

6. allkeys-random：从全部key中任意选择数据淘汰

7. volatile-ttl：从已设置过期时间的key中挑选将要过期的数据淘汰；

8. no-enviction：禁止驱逐数据，这也是默认策略。当内存不足以容纳新入数据时，新写入*作就会报错。