redis之持久化

redis持久化：

redis的持久化一般有两种方式，一个是快照，也就是常说的RDB持久化，另一个就是AOF持久化，两则之间的差别其实挺大，希望看完本篇文章后您能找到合适你的方法。

方式一：快照snapshot：保存这一时刻的数据状态，这是默认开启快照，由于保存的文件是以.rdb形式结尾的文件，因此这种方式也称之为RDB持久化方式。

快照生成方式：1.客户端方式：BGSAVE和SAVE指令

2.服务器配置自动触发

1.客户端方式：

BGSAVE方式：在redis-cli客户端直接输入命令：BGSAVE。客户端可以使用BGSAVE命令来创建一个快照，当接收到客户端的BGSAVE命令时，redis会调用fork’来创建一个子进程，然后子进程负责将快照写入磁盘中，而父进程则继续处理命令请求。

在刚开始的时候，父子进程贡献相同内存，直到父进程或子进程对内存进行了写操作之后，对被写入的内存的共享才会结束服务，子进程是不会进行写操作的，这样就保证了在没有客户端请求的时候能够最大速度的处理子线程，如果有客户端请求的时候父进程才会用很小一部分请求去处理客户端请求，

SAVE方式：在redis-cli客户端直接输入命令：SAVE，接收到SAVE命令的redis服务器在快照创建完毕之前将不再响应任何其他的命令，SAVE命令并不常用，使用SAVE命令在快照创建完毕之前，redis处于阻塞状态，无法对外服务。

2.服务器方式：

在redis.conf配置中是默认开启BGSAVE快照的，只要满足任何一项都会生效RDB持久化：

1
2
3

save 900 1  ：如果十五分钟内有一个key发生变化，那么就十五分钟执行一次BGSAVE
save 300 10 ：如果五分钟内有十个key发生变化，那么就五分钟执行一次
save 60 1000 ：如果一分钟内有一万个key发生变化，那么一分钟就执行一次

服务器接收到客户端shutdown指令的时候，会执行一个save命令，阻塞所有的客户端，不再执行客户端执行发送的任何命令，并且在save命令执行完毕之后关闭服务器。

对应可调整的配置文件：

dbfilename dump.rdb  :生成的快照的文件名
dir ./r  :生成快照的保存目录，默认是基于redis脚本的根目录，可以在docker启动一个镜像的时候指定
rdbchecksum yes  ：导入rdb恢复数据时，是否检验rdb的完整性
rdbcompression yes  ： 导出的rdb文件是否压缩

注意：RDB快照方式存在隐患，如果客户端刚刚加入新的数据，但是还没有达到快照生成的条件，这个时候突然断点，将会导致数据直接丢失，也就是快照间隔问题。

优势：1) RDB文件相比AOF占用的空间更小，恢复数据的速度更快；

2) 如果创建RDB文件时出现了错误，Redis不会将它用于替换原来的文件，所以出错的时不会影响到之前保存的版本；

3) 通过合理的配置可以放redis每隔一段时间就保存一次数据库副本，可以很方便的将数据还原到特定的时间点

缺点: 1) 如果硬件、系统、Redis三者其中之一出现问题而崩溃，Redis会丢失全部数据，保留下来的数据只有上一个时间点创建的快照。如果数据对于应用程序来说非常重要，那么出现错误时的损失会非常大；

2) fork子进程占用的内存随着数据库中数据的增加而增加，耗费的时间也会越来越多

方式二：AOF append only file：将所有redis写命令记录到日志文件中，调用AOF时，会重写执行所有的写操作，以实现数据数据持久的绝对安全，

1.修改配置文件

1 2	appendonly yes ：开启AOF持久化，也可以在docker run的时候指定 appendfilename "appendonly.aof" :修改指定生成的文件名称

2.生成的appendonly.aof的文件和dump.rdb位于同一位置，我的为docker映射下的data文件夹里面

3.日志追加频率

always[谨慎使用]
说明：每个redis写命令都要同步写入磁盘，严重降低redis速度
everysec[推荐]
说明：每秒执行一次同步显示的将多个写命令同步到磁盘
no[不推荐]
说明：由操作系统决定何时同步

4.问题：AOF的持久化文件会变得越来越大

5.AOF重写：用来在一定程度上减小AOF文件的体积

6.触发重写的方式

在客户端输入：BGREWRITEAOF
服务器配置方式自动触发：
auto-aof-rewrite-percentage 100  ：一次后重写要求的体积的百分比
auto-aof-rewrite-min-size 64mb  ：初始化文件体积大小
解释：在开启AOF持久化的情况下，当AOF文件体积大于64M，会做一次重写，而第二次重写时要求AOF文件的体积比上一次重写之后体积大了至少一倍(100%)时，会自动触发，如果重写过于频繁，auto-aof-rewrite-percentage设置得更大
64M重写后可能变成20M，第二次重写就以20M为起始，当文件体积达到40M的时候才会触发重写，重写后可能变成18M，第三次重写就以18M为起始，当文件体积达到36M的时候触发重写，一直持续下去，

7.重写原理

重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，替换原有的文件这点和快照有点类似。

a.redis调用fork，现在有父子两个进程，子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
b.父进程继续处理client请求，除了把写命令写入到原来的AOF文件中，同时把收到的写命令缓存起来，这样就能保证如果子进程重写失败的话也不会出问题
c.当子进程把快照内容以写命令的方式写入临时文件后，子进程发信号通知父进程，然后父进程把缓存的写命令也写入到临时文件
d.现在父进程可以使用临时文件替换老的AOF文件，并重命名，后面收到的写命令也开始往新的AOF文件中追加

8.一张看视频的时候截的重写分析图

redis两重持久化方案的总结：

具体使用哪种持久化方案取决于用户的数据和应用决定，其实小孩子才做选择，我是大人，所以我都要QAQ。