rdb其实就是一种快照持久化的方式，它会将Redis在某个时间点的所有的数据状态以二进制的方式保存到硬盘上的文件当中，它相对于aof文件会小很多，因为知识某个时间点的数据，当然，这就会导致它的实时性不够高，如果突然停机，那么会导致大量丢失数据，所以需要AOF来配合使用。

而AOF是一种追加日志的持久化方式， 在先执行完写操作命令后，然后把该命令以追加的方式写入文件尾。它会比rdb文件大很多，因为一直在记录命令嘛，所以由此引入了aof重写的一个机制。之后就是 Redis 重启时，会读取该文件记录的命令，然后逐一执行命令的方式来进行数据恢复。

通常这两个会结合来进行配置，先进行rdb数据恢复，然后再通过aof进行数据恢复。

先执行命令，再写日志------>【避免额外的检查开销、不会阻塞当前写操作命令的执行】

所以数据完整性上它其实是更可靠的持久化方式，因为它几乎可以保证每个写操作都被记录下来，并且在几乎不会发生数据丢失的情况。但是之所以说是几乎，其实是取决于AOF日志sync属性的配置的。

当Redis重启时，它可以重新执行这些写命令来恢复数据状态。但是就是因为它会将每个命令记录下来，所以导致它比RDB文件大太多了，而且如果一个key有多个写操作，那么AOF也会多次进行记录，但是只有最后一次写操作才有用嘛，所以就可以执行bgrewriteaof命令，让AOF文件执行重写功能，来达到用最少的命令达到相同效果。

而在使用持久化机制时，我们其实也可以选择同时使用RDB和AOF，也可以只使用其中一种。不过同时使用两种方式时，在Redis实例重启的时候，就可以使用RDB持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。

把RDB理解为一整个表全量的数据，AOF理解为每次操作的日志，服务器重启的时候先把表的数据全部搞进去，但是他可能不完整，你再回放一下日志，数据不就完整了嘛。

不过Redis本身的机制是 AOF持久化开启且存在AOF文件时，优先加载AOF文件；AOF关闭或者AOF文件不存在时，加载RDB文件；加载AOF/RDB文件成功后，Redis启动成功； AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。