Redis的RDB持久化和AOF持久化总结

RDB持久化

这个功能可以将Redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。

由于RDB文件是保存在磁盘里面的，所以即使Redis服务器进程退出，甚至运行Redis的服务器停机，只要存在RDB文件就可以还原数据库状态。

RDB文件的创建和载入

保存数据库状态生成一个RDB文件，这个文件由两个命令生成，一个是SAVE一个是BGSAVE。

• SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕，在阻塞期间服务器不能处理任何请求。
• BGSAVE命令会派生一个子进程，然后由子进程负责创建RDB文件，父进程（服务器进程）继续处理命令请求。

在BGSAVE执行过程中，客户端发送SAVE或者BGSAVE会被服务器拒绝，防止父子进程产生竞争条件。因为命令底层都是调用一个相同的函数。如果发送BGREWRITEAOF命令会延时，等待BGSAVE处理完后才会进行此命令的处理。为了性能考虑，如果同时执行会并发执行两个子进程同时对磁盘进行大量的I/O操作。

什么时候执行BGSAVE命令？

配置文件redis.conf中**SNAPSHOTTING（快照）**下save属性 eg：60s执行10000次修改

save 900 1
save 300 10
save 60 10000

其中任意一个条件被满足时，就会执行BGSAVE命令。

怎么判断是否满足条件？

时间事件serverCron会检查服务器中的dirty和lastsave属性，进行判断。

dirty:距离上次成功执行SAVE或者BGSAVE后服务器对数据库状态进行了多少次修改。

lastsave：记录了上一次成功执行SAVE或BGSAVE的UNIX时间戳。

RDB文件的载入工作时在服务器启动时自动执行的，在载入期间服务器会一直处于阻塞状态。

RDB的优缺点

优点：

1. RDB文件紧凑，体积小，网络传输速度快，适合全量复制。
2. 恢复速度比AOF快。
3. RDB相对于AOF来说，对性能的影响相对较小。

缺点：

1. 不能实时持久化可能会导致数据大量丢失。
2. 新老版RDB文件兼容性较差，文件不满足特定格式。
3. BGSAVE在fork操作时主进程会堵塞，子进程写数据也会带来I/O压力。

##RDB文件格式
REDIS|db_version|databases|EOF|check_sum

db_version代表RDB的版本号，兼容性较差就是应为版本号不一样。
databases代表数据库状态。
EOF是一个结束标志。
check_sum是通过前四项计算出来的特殊值用来验证RDB文件的完整性。

AOF持久化

是通过保存Redis服务器所执行的写命令来记录数据库状态的，会自动添加select命令来选择数据库。

AOF持久化的实现可以分为命令追加，文件写入，文件同步三个步骤。

命令追加：将被执行的命令追加到服务器的aof_buf缓冲区中。

写入与同步：Redis服务器进程实际是一个事件循环，每次结束一个循环前，会调用相关函数进行判断是否需要将缓冲区的内容写入和保存到AOF中，这个判断由服务器的配置文件中的appendfsync值来决定always、ererysrc、no三个等级判断。

always:总是同步
ererysrc:判断与上次同步时间间隔是否超过1s
no:写入后不同步
##安全
always 最安全但是最慢
everysrc 丢失1s的数据
no 不安全 由操作系统决定什么时候同步

操作系统通常将写入数据暂时保存在一个内存缓冲区中，等到缓冲区的空间被填满或者超过指定的时限之后，才真正地将缓冲区的数据写入到磁盘中。

由于AOF文件中的内容越来越多，文件越来越大，所以需要执行AOF重写（BGREWRITEAOF）

首先从数据库中读取键的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令。这就是AOF重写的原理（将多条命令产生的结果用一条命令表示）

AOF重写存在于子进程中，子进程进行重写会进行大量的写入操作，将长时间堵塞。

当AOF重写进行时，主进程会继续进行命令的处理，导致数据库状态被修改，和子进程重写后的状态不一样，为了解决这个问题，Redis设置了一个AOF重写缓冲区，在执行AOF重写时使用：

1. 执行客户端发来的命令
2. 将执行后的命令追加到AOF缓冲区中
3. 将执行后的命令追加到AOF重写缓冲区

当AOF重写完成后，会向父进程发送一个信号函数，父进程收到信号后会调用函数将AOF重写缓冲区的内容写入到AOF文件然后对旧的AOF文件进行覆盖。