RDB和AOF都是对服务器中所有数据库而言的，和redisDb一样，是在redisServer结构体下的同一层级。
RDB
由于redis是内存型数据库，所以当服务器进程意外终止时，数据库中保存的信息将不会存在（比如使用redis管理会话信息的系统，当redis服务器宕机会导致所有用户的会话信息丢失，导致重新登陆或者其他的问题），为了防止这一问题，redis引入了RDB持久化，将数据库状态信息保存在硬盘中，从而实现redis服务器宕机后能够从硬盘中自动恢复大部分数据。 RDB可以手动通过指令创建，也可以通过配置使redis服务器定期自动更新RDB文件。
1. 手动创建
手动创建可以使用BGSAVE和SAVE两个命令，他们之间的区别在于前者是通过fork一个子进程来创建RDB文件，不会导致redis服务器阻塞从而不能处理任何请求，需要注意的是，RDB持久化命令只能有单例执行，不能同时执行两个持久化命令，否则会被服务器拒绝。
2.自动创建
在save选项中配置如下信息：
save 60 100 这样表示在60秒内如果进行了100次改动则进行持久化，save配置可以配置多行，多个持久化配置之间的关系是只要满足其中的一个那么就进行持久化。
redis的这个保存参数很值得借鉴，我们可以同时实现对低频和高频操作的持久化。
redis服务器通过维护一个dirty计数器和lastsave来记录某个时间段内修改了多少次，这两个参数和redisDb结构体在同一层级，因此可以知道记录的是整个redis所有的数据库的修改。redis会自动维护一个时间差，每次检查时都会将之前的时间差和现在的时间相加从而判断是否达到了配置中指定的时间长度，如果达到则判断dirty是否达到指定次数，两者都达到则进行一次RDB持久化操作，同时将dirty值重置为0。
AOF文件
AOF是通过保存服务器收到的命令来记录数据库的状态，通过将命令追加到文件中，在服务器启动时在创建一个伪客户端从AOF文件中读取命令从而实现恢复服务器状态。
AOF文件的写入配置有appendfsync选项来决定，当设置为always时，服务器都会将缓冲区中的指令写入到AOF文件中，同事同步AOF文件，效率最低但是最安全；设置为everysec时，服务器同样是每个事件循环时会将缓冲区中的内容写入到AOF文件中，但是是每隔一秒才会同步AOF文件，牺牲了一定的数据可用性，提高性能，比较折中的方案；设置为no时，该模式速度最快，但是由于服务器不会主动去同步AOF文件，由操作系统来控制AOF文件的同步，所以可能会有很多条指令被保存在了系统缓存中，当服务器宕机时，这种方案损失的数据也是最多的。
AOF通过存指令来实现服务器状态的恢复也是有一定的弊端的，比如，可能多条指令同时对一个键进行了更新，但是最后这个键对应的数据被改来改去还是原来的样子，这样就会导致AOF文件中存了很多不必要的指令。
为了解决这个问题，redis采用了AOF文件重写，当开启AOF重写时，服务器会再创建一个AOF重写缓冲区来保存执行的指令，然后经过分析后，合并无效的指令写入到新的AOF文件中。
