Redis内存满了怎么办？

长期把Redis做缓存用，总有一天Redis内存会满的，怎么处理呢？
​
在Redis的配置文件redis.conf文件中，配置maxmemory的大小参数如下所示：
​

maxmemory 100mb //一般公司给的内存大小都在3G往上

​
倘若实际的存储中超出了Redis的配置参数的大小时，Redis中有淘汰策略，把需要淘汰的key给淘汰掉，整理出干净的一块内存给新的key值使用。
​
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 noeviction   // 淘汰策略名字

​

LRU算法

​
LRU(Least Recently Used)即表示最近最少使用，也就是在最近的时间内最少被访问的key，算法根据数据的历史访问记录来进行淘汰数据。
​
它的核心的思想就是：假如一个key值在最近很少被使用到，那么在将来也很少会被访问。
​
实际上Redis实现的LRU并不是真正的LRU算法，也就是名义上我们使用LRU算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。
​
Redis使用的是近似的LRU算法，通过随机采集法淘汰key，每次都会随机选出5个key，然后淘汰里面最近最少使用的key。
​
这里的5个key只是默认的个数，具体的个数也可以在配置文件中进行配置，在配置文件中的配置如下图所示：
​

maxmemory-samples 5 // 个数

​
当近似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种有三种删除的操作此策略，分别是：
​

1. 定时删除：创建一个定时器，定时的执行对key的删除操作。
2. 惰性删除：每次只有再访问key的时候，才会检查key的过期时间，若是已经过期了就执行删除。
3. 定期删除：每隔一段时间，就会检查删除掉过期的key。
   ​
   定时删除对于内存来说是友好的，定时清理出干净的空间，但是对于cpu来说并不是友好的，程序需要维护一个定时器，这就会占用cpu资源。
   ​
   惰性的删除对于cpu来说是友好的，cpu不需要维护其它额外的操作，但是对于内存来说是不友好的，因为要是有些key一直没有被访问到，就会一直占用着内存。
   ​
   定期删除是上面两种方案的折中方案，每隔一段时间删除过期的key，也就是根据具体的业务，合理的取一个时间定期的删除key。
   ​
   通过最合理控制删除的时间间隔来删除key，减少对cpu的资源的占用消耗，使删除操作合理化。
   ​

RBD和AOF的淘汰处理

​
在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

​
RDB是一种快照存储持久化方式，具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb，而在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。
​
开启RBD持久化方式
​
开启RDB持久化方式很简单，客户端可以通过向Redis服务器发送save或bgsave命令让服务器生成rdb文件，或者通过服务器配置文件指定触发RDB条件。
​

1. save命令

​
save命令是一个同步操作。
​

# 同步数据到磁盘上
> save 

​

img

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

如果数据量太大，同步数据会执行很久，而这期间Redis服务器也无法接收其他请求，所以，最好不要在生产环境使用save命令。
​

2. bgsave

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

# 异步保存数据集到磁盘上
> bgsave

​
​
​

img

​
​
​
当客户端发服务发出bgsave命令时，Redis服务器主进程会forks一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。
​
所以，与save命令相比，Redis服务器在处理bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求，但forks子进程是同步的，所以forks子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
​

3. 服务器配置自动触发

​
除了通过客户端发送命令外，还有一种方式，就是在Redis配置文件中的save指定到达触发RDB持久化的条件，比如【多少秒内至少达到多少写操作】就开启RDB数据同步。
​
例如我们可以在配置文件redis.conf指定如下的选项：
​

# 900s内至少达到一条写命令
save 900 1
# 300s内至少达至10条写命令
save 300 10
# 60s内至少达到10000条写命令
save 60 10000

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

# 启动服务器加载配置文件
redis-server redis.conf

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

RDB文件

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

1. 生成临时rdb文件，并写入数据。
2. 完成数据写入，用临时文代替代正式rdb文件。
3. 删除原来的db文件。
   ​
   RDB默认生成的文件名为dump.rdb，当然，我可以通过配置文件进行更加详细配置，比如在单机下启动多个redis服务器进程时，可以通过端口号配置不同的rdb名称，如下所示：
   ​

# 是否压缩rdb文件
rdbcompression yes
​
# rdb文件的名称
dbfilename redis-6379.rdb
​
# rdb文件保存目录
dir ~/redis/

​

RDB的几个优点

​

1. 与AOF方式相比，通过rdb文件恢复数据比较快。
2. rdb文件非常紧凑，适合于数据备份。
3. 通过RDB进行数据备，由于使用子进程生成，所以对Redis服务器性能影响较小。
   ​

RDB的几个缺点

​

1. 如果服务器宕机的话，采用RDB的方式会造成某个时段内数据的丢失，比如我们设置10分钟同步一次或5分钟达到1000次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。
2. 使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求。
3. 使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存。
   ​

AOF

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

img

​

开启AOF持久化方式

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

# 开启aof机制
appendonly yes
​
# aof文件名
appendfilename "appendonly.aof"
​
# 写入策略,always表示每个写操作都保存到aof文件中,也可以是everysec或no
appendfsync always
​
# 默认不重写aof文件
no-appendfsync-on-rewrite no
​
# 保存目录
dir ~/redis/

​

三种写入策略

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

appendfsync always
# appendfsync everysec
# appendfsync no

​

1. always

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

2. everysec

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

3. no

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

AOF文件重写

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

incr num 1
incr num 2
incr num 3
incr num 4
incr num 5
incr num 6
...
incr num 100000

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

set num 100000

​

aof文件是一个二进制文件，并不是像上面的例子一样，直接保存每个命令，而使用Redis自己的格式，上面只是方便演示。
​

两种重写方式

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

# 默认不重写aof文件
no-appendfsync-on-rewrite no

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

# 让服务器异步重写追加aof文件命令
> bgrewriteaof

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

img

​

重写aof文件的好处

​

1. 压缩aof文件，减少磁盘占用量。
2. 将aof的命令压缩为最小命令集，加快了数据恢复的速度。
   ​

AOF文件损坏

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

1. 备份现在aof文件，以防万一。
2. 使用redis-check-aof命令修复aof文件，该命令格式如下：
   ​

# 修复aof日志文件
$ redis-check-aof -fix file.aof

​

1. 重启Redis服务器，加载已经修复的aof文件，恢复数据。
   ​

AOF的优点

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

AOF的缺点

​

1. AOF方式生成的日志文件太大，即使通过AFO重写，文件体积仍然很大。
2. 恢复数据的速度比RDB慢。
   ​

选择RDB还是AOF呢？

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

img

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