RDB和AOF

​ Redis有两种持久化方式，RDB和AOF。

RDB

​ 该功能可以将某个时间点上的数据库状态保存到一个RDB文件中。RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态。服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止。

​ RDB有手动触发和自动触发两种方式。手动触发可以使用bgsave命令，使用bgsave命令后，Redis会执行fork创建子进程完成RDB过程。自动触发则是需要配置save相关的配置，如“save m n”，表示m秒内数据集存在n次修改时，自动触发bgsave。

RDB的优缺点

​ 优点：RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照，非常适合用于备份，全量复制等场景。比如每6小时执行bgsave备份，并将RDB文件拷贝到远程机器或者文件系统中，用于灾难恢复。Redis加载RDB恢复数据远远快于AOF方式。

​ 缺点：没有办法做到实时持久化/秒级持久化。bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

另外值得一提的是，因为AOF文件的更新频率通常比RDB文件的更新频率高，所以：

​ 如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态。

​ 只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。

AOF

​ AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的，就跟记流水一样，一条一条的记录命令到文件中。AOF持久化保存数据库状态的方法是将服务器执行的SET、SADD、RPUSH三个命令保存到AOF文件中。被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的，因为Redis的命令请求协议是纯文本格式。

AOF文件过大怎么办？

​ AOF重写。

​ AOF持久化是通过保存被执行的写命令来记录数据库状态的，所以随着服务器运行时间的流逝，AOF文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的AOF文件很可能对Redis服务器、甚至整个宿主计算机造成影响，并且AOF文件的体积越大，使用AOF文件来进行数据还原所需的时间就越多。

​ 为了解决AOF文件体积膨胀的问题，Redis提供了AOF文件重写（rewrite）功能。通过该功能，Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个AOF文件所保存的数据库状态相同，但新AOF文件不会包含任何浪费空间的冗余命令，所以新AOF文件的体积通常会比旧AOF文件的体积要小得多。

​ AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作，这个功能是通过读取服务器当前的数据库状态来实现的。就是遍历数据库，获取Redis所有类型的键，再拼成一条命令去记录键值对，代替之前记录这个键值对的多条命令。

​ Redis会将AOF重写程序放到子进程里执行，但是使用子进程也有一个问题需要解决，因为子进程在进行AOF重写期间，服务器进程还需要继续处理命令请求，而新的命令可能会对现有的数据库状态进行修改，从而使得服务器当前的数据库状态和重写后的AOF文件所保存的数据库状态不一致。

Redis是怎么处理这个问题的呢？

​ 为了解决这种数据不一致问题，Redis服务器设置了一个AOF重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当Redis服务器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区。