Redis的持久化

redis作为一个键值对内存数据库，数据都是存储在内存中，当程序发起请求时，查询等信息都是在缓存中，这样查询起来相比较直接从硬盘中进行查询，效率更快一些；

        但是，我们都知道，当数据存储在内存中时，只要服务器出现宕机等情况时，内存中的数据就会消失，不仅服务器宕机会造成数据消失，redis服务器进程退出后，内存中的数据也会消失

        所以如果说项目中一些数据存储在redis中时，如果出现数据丢失情况时，可能会对项目带来非常大的影响；        

        所以针对这个情况，redis提供了对持久化的支持，有两种方式，都是将数据从内存中保存在硬盘当中，使得数据可以持久化保存；

        Redis提供了RDB和AOF两种不同的数据持久化方式

1、RDB（快照）

        RDB是一种快照存储持久化方式，具体就是将Redis按照每分钟（每隔一段时间进行备份）将内存数据保存到硬盘的文件当中，下一次的备份，将覆盖上一次的备份文件；默认保存的文件名为dump.rdb，而在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。 RDB丢失数据的话，会丢失两个快照之间的数据；

RDB文件

生成RDB文件：

1. 生成临时rdb文件，并写入数据。
2. 完成数据写入，用临时文代替代正式rdb文件。
3. 删除原来的db文件。

RDB的几个优点

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

RDB的几个缺点

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

2、AOF

        与RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端对服务器的每一次写操作命令（就是将数据中的增删改的动作都记录文档中），并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾，在Redis服务器重启时，会加载并运行aof文件的命令，以达到恢复数据的目的。但是AOF如果出现文件丢失的话，他只会丢失最后一条的操作数据；

AOF文件重写

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

       AOF文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集；比如更新的语句，将对文件统一个ID进行执行的操作，只执行最后一个语句；

重写aof文件的好处

1. 压缩aof文件，减少磁盘占用量。

2. 将aof的命令压缩为最小命令集，加快了数据恢复的速度。

3. AOF如果出现丢失数据时，将只会丢失最后一条的数据，相比较RDB丢失数据相对比较少

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操作，会严重影响服务器性能，因此有时候不得不做出选择

过期策略指的是ttl到期时的处理策略，淘汰策略指的是内存满了的情况下的策略 

3、过期策略（TTL）

• 定期删除，Redis默认每隔100ms会从设置了过期时间的key中随机抽取一部分来检查是否过期,如果过期就删除。
• 惰性删除（有点像是懒加载），定期删除可能会导致很多设置了过期时间的key没有被及时删除，所以就有了惰性删除,即在查询这个key时，检查一下是否过期,如果过期就删除。

4、淘汰策略

        内存满后有什么策略，默认的：当内存不足以容纳新写入数据时，新写入操作会报错。

 

结合定期删除 + 惰性删除 Redis 实现了key的过期时间机制，但还是会有一些key会没有被定期删除掉，也没有被查询，就遗留在了内存中，当数据量大到一定程度后，会导致内存的堆积。这就涉及到了 内存淘汰机制。

当内存容量到达了上限或者 配置的maxmemory时，会触发 内存淘汰策略

Redis提供了几种策略供我们选择:

1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。

2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。

3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。

5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。

6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

总的来说,无论是 LRU LFU TTL 还是Random 都是几近算法来实现的,在可靠性和性能上做了一定的平衡。还是应该在业务中主动删除没有价值的数据，或者更新某些key的过期时间等来提高Redis的性能和空间，不能过分依赖于淘汰策略。