RDB
RDB是一种条件触发的备份机制。达到一定的条件时，将当前内存数据生成一个快照备份(dump文件)到硬盘中。
开启自动RDB
比如 save 30 100，表示30秒钟有100个key被修改，则持久化一次。
我们可以配置多种组合，例如：
save 60 1000 #60秒内1000个key被修改
save 90 1500 #90秒内1500个key被修改
手动RDB
执行bgsave指令即可
AOF
AOF是一种指令追加式的备份机制。每次做写操作时，则在指定的aof文件中，追加当前执行的指令。
开启AOF
通过appendonly yes开启AOF
需要注意的是，AOF提供了3种追加指令的备份机制：
appendfsync always：每次有写操作的命令，都追加到AOF文件。特点是会比较慢，但是胜在数据安全。
appendfsync everysec：每秒备份一次，足够快，最多只会丢失1秒的数据。
appendfsync no：不主动备份，由操作系统调度，性能最优。
这3种机制，一般推荐appendfsync everysec。
AOF重写
在恢复数据时，AOF会根据aof文件中的指令依次恢复。如果指令比较多时候，恢复起来会比较慢。Redis提供了一个AOF重写的功能，来重写指令。
比如
incr num
incr num
incr num
最终的num是3，AOF重写后，指令会变成
set num 3
开启AOF重写
手动触发
通过客户端执行BGREWRITEAOF指令触发
自动触发
auto‐aof‐rewrite‐min‐size 100mb #aof文件至少要达到100M才会自动重写
auto‐aof‐rewrite‐percentage 100 #比如上次100M发生了一次重写，这次增长到了200M则再次触发重写，这里配置100是指100%，是百分比
通过上面两种持久化方式的对比可以看出两种持久化方式都有一定的短板。如果使用RDB，存在丢失数据的风险。如果使用AOF，宕机后重启重置缓存耗时会比较久，那么有没有一种办法能避免这两块短板呢？
混合持久化
在Redis4.0中，提供了一种混合持久化的方式，可以解决上面两种方式的不足。
开启混合持久化后，在AOF重写时，不再仅仅将写指令追加到AOF中，而是先将当前内存中的数据做RDB处理，之后的写操作还是用指令追加的方式，最后合并为aof文件。发生aof重写后的文件结构大概为：RDB快照数据+写指令，如下：
所以在宕机后重启时，先加载RDB的内容，再依次加载写指令。即提升了加载的效率，又保证了数据的完整性。
开启混合持久化
aof‐use‐rdb‐preamble yes #注意必须先开启AOF
思考
Redis是单线程的，那么在RDB和AOF重写时，是否会阻塞客户端的指令呢？
答案是不会。因为在RDB和AOF重写时，Redis会由操作系统Fork一个子进程来执行，所以不会影响客户端的操作。
那么问题来了，在子进程执行期间，又有新的写指令传给Redis，那么Redis如何保证数据的一致性呢？这里就涉及到了AOF重写缓冲区。
开启AOF后，收到请客户端的指令后，Redis主线程会做如下两件事：
1.执行客户端发送的指令
2.写指令追加到AOF文件
如果当前正在进行AOF重写，那么Redis还会再把写指令追加到AOF重写缓冲区，从而避免了数据不一致的情况。
最后多说两句
其实所谓的AOF重写并不准确，因为其不会读取aof文件重写。其机制是以当前Redis中的数据为准，进行数据指令备份的一种方式，准确的说应该是AOF"覆写"。