（1）RDB快照是一次全量备份，当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
（2）fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑；同时子进程写入的时候主进程不能进行任何的IO操作。
（3）由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
AOF持久化RDB的持久化是全量备份，每次备份都比较耗时，有时候我们可以用一种更加高效的方式：AOF。AOF工作机制就是将每次写入操作写入日志，redis会将每一个收到的写命令都通过write函数追加到文件中，通俗的理解就是日志记录，在每次恢复的时候重新执行一次日志文件中的写入操作就可以了。
AOF的方式虽然高效，但同时带来了另一个问题：持久化文件会变的越来越大。为了压缩aof的持久化文件，redis提供了bgrewriteaof命令，将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
AOF的配置参数如下：
名称 内容appendfsync 同步的机制：Always，表示实时同步，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好；everysec，表示每秒同步，异步操作，如果一秒内宕机，有数据丢失；no，表示不同步
no-appendfsync-on-rewrite 重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
auto-aof-rewrite-min-size 设置重写的基准值
auto-aof-rewrite-percentage 设置重写的基准值百分比
优劣势
优势：
（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。
劣势：
（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大，恢复速度慢于RDB。