RDB：Redis DataBase
在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork出一个子进程，先将数据集写入临时文件，写入成功后，再替换之间的文件，用二进制压缩存储。
为了写快照而暂停写操作，这肯定是不能接受的。所以这个时候，Redis就会借助操作系统提供的写时复制(Copy-On-Write)技术，在执行写快照的同时，正常处理写操作。
简单来说，bgsave子进程由主线程fork生成的，可以共享主线程的所有内存数据。bgsave子进程运行后，开始读取主线程的内存数据，并把他们写入RDB文件。此时，如果主线程对这些操作也是读操作(例如途中的A操作)，那么，主线程和bgsave子进程相互不会影响。但是，如果主线程要修改一块数据(例如途中的键值对C)，那么，这块数据就会被复制一份，生成该数据副本。然后bgsave子进程会把这个副本写入到RDB文件，而在这个过程中，主线程任然可以直接修改原来的数据。
优点：
整个redis数据库将只包含一个文件 dump.rdb，方便持久化
容灾性好，方便备份
性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化，使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能。
相对于数据集大时，比AOF启动效率更高。
缺点
数据安全性低。RDB时间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失，所以这种方式更适合数据要求不严谨的时候
由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至时一秒钟。
AOF：Append Only File
以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录。记录的是写后日志，因为redis没有语法检查功能，所以只能通过执行来判断是否正确。
三种同步策略
Always，同步写回：每个写命令执行完，立即同步地将日志写回磁盘
Everysec：每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓存区，每隔一秒把缓冲区中的内容写入磁盘。
No，操作系统控制写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
AOF重写
和AOF日志由主线程写回不同，重写过程是由后台子进程bgrewriteaof来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。
重写过程可以总结为 一个拷贝，两处日志
一个拷贝就是指，每次执行重写时，主线程fork出后台的bgrewriteaof子进程。此时fork会把主线程的内存拷贝一份给bgrewriteaof子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，计入重写日志。
两处日志又是什么呢？
因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一次日志就是指正在使用的AOF日志，Redis会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个AOF日志的操作仍然是齐全的，可以用于恢复。
而第二个日志，就是指新的AOF重做日志了。这个操作也会被记录到重写日志的缓冲区。这样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的AOF文件，以保证数据库最新状态的记录。此时就可以使用新的AOF文件代替旧文件。
优点
数据安全，redis采用三种同步策略，即每秒同步、每修改同步和操作系统控制同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，一旦系统出现宕机，那么丢失的也仅仅是这一秒的数据。而每修改同步，可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。
通过append模式写文件，即使中途服务器宕机也不会破坏已经存在的内容，可以通过redis-check-aof工具解决数据一致性问题。
AOF机制的rewrite模式。定期对AOF文件进行重写，达到压缩的目的。
缺点
AOF比RDB文件大，且恢复速度慢
数据集大的时候，比RDB启动效率低
运行效率没有RDB高
AOF文件比RDB更新频率高，优先使用AOF还原数据。
AOF比RDB更安全也更大
RDB性能比AOF好
如果两个都配置了，优先加载AOF