RDB
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘(默认是 dump.rdb)。
默认持久化机制，就是将内存中的数据以快照的方式写入二进制文件dump.rbd中。
触发快照的条件
1.自己配置快照规则
save <second> <exchanges>
second 秒内，key的修改数量大于exchanges时，执行快照
save的关系是或的关系，都满足
默认文件名为 dump.rdb
默认路劲为配置文件下的当前路径
获取配置文件中的快照规则 config get save
添加新规则，服务器重启后失效，config set save "second exchanges"
2.save或bgsave
save：执行内存的数据同步到磁盘的操作，这个操作会阻塞客户端的请求。（不要轻易执行，数据量大，阻塞时间差）
bgsave：在后台异步执行快照操作，这个操作不会阻塞客户端的请求。
3.执行flushall
清除内存中的所有数据，只要快照规则不为空，那么redis就会执行快照。
4.执行复制的时候（集群）
快照的实现原理
redis会使用fork函数复制一份当前进程的副本（子进程）
父进程继续处理客户端请求。
fork进程负责把内存的数据同步到磁盘的临时文件，当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
缺点：由于子进程是复制父进程，两个内存大小相同的redis进程在系统上运行，会造成内存使用率大幅增加。
使用rdb的优缺点
优点：
1.只包含一个dump.rdb文件，方便备份移动。
2.rdb回复大数据集的速度比aof快。
3.rdb可以最大化redis性能，因为是子进程去处理保存工作，父进程无需执行io操作。
缺点：
1.rbd的规则是单位时间内改变多少个键，才会触发，而在为改变之前，一旦服务器故障，就会丢失几分钟的数据
2.当数据量大时,fork子进程会非常耗时，会造成服务器在某毫秒或长达一秒的时间停止处理客户端。并且子进程和父进程两个进程会消耗更多的内存。
AOF
redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。
如何配置
appendonly 改为yes
appendfilename：保存的文件名
当修改了值后，可以看到生成了新的文件appendonly.aof
vim appendonly.aof文件，可以看到每条记录都被写入aof文件中
同步磁盘数据出现的问题
redis每次更新数据时，aof机制都会将命令写入aof文件中。
但是实际上由于操作系统的缓存机制，数据并没有实时写到磁盘，而是先写入磁盘的缓冲区，再通过硬盘缓存机制刷新保存到文件中。
这样就可能回出现数据丢失。
配置同步策略
appendfsync always：每次收到命令就立刻强制写入磁盘，最慢，但是完全持久化，不推荐使用
appendfsync everysec：每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
appendfsync no ：完全依赖os，性能最好，持久化没保障。
每一秒都将命令写入文件中，aof文件越来越大，并且很多语句会出现多余，所以引入了重写策略。
重写策略（优化aof文件）
auto-aof-rewrite-percentage 100 ：当aof文件大小超过上一次aof文件大小的百分之多少会重写。如果之前没重写过，以启动时aof文件大小为准。
auto-aof-rewrite-min-size 64mb ：限制允许重写最小aof文件大小，也就是文件大小小于64mb，不需要进行优化。
重写的实现原理
1.redis调用fork函数，复制一个子线程
2.父进程继续处理client请求，将请求追加到aof文件，同时收到的命令缓存起来，这样保证子进程重写失败不会出问题。
3.子进程根据内存中的数据快照，往临时文件中写入重建数据库状态的命令
4.当子进程将快照的命令写入临时文件后，通知父进程，然后父进程把缓存的写命令也写入临时文件
5.当父进程写完后，将临时文件替换老的aof文件，后续命令往新的aof文件中追加
aof文件的修复
1.先复制原有的aof cp appendonly.aof appendonly.aof.bak
2.执行 redis-check-aof --fix appendonly.aof 完成修复
aof的优缺点
优点：
1.aof的同步策略，可以让aof安全性变的非常高，并且使用每秒同步一次，redis依然可以保证很好的性能，就算发生故障，也最多只丢失一秒的数据。
2.aof采用末尾追加的方式写入文件，即便出现问题，aof-check-aof也可以修复文件。同时aof提供了重写策略，来优化aof文件
3.aof有序保存了对数据库执行写的操作，以redis协议数据保存，易于读和解析，并且不小心执行了flushall，也可以移除aof文件末尾的flushall命令，恢复之前的状态。
缺点：
1.对于相同的数据集来说，aof文件体积大于rdb文件的体积。
2.因为采用了同步策略，aof的速度相比rdb还是要慢一些。
两种持久化的策略可以同时使用，也可以使用其中的一种，如果同时使用的时候，那么Redis重启时，会优先使用aof文件来还原数据。