RDB 就像数据库的全量备份
AOF 就像数据库的binlog日志 第一次是全量？后面所有操作都会写记录，直到被重写
同时启用时 它会优先使用 AOF 文件来还原数据集
lnmp默认打开RDB，关闭AOF
RDB
快照原理
Redis 在持久化时会调用 glibc 的函数fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段。这时你可以将父子进程想像成一个连体婴儿，共享身体。这是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。
随着父进程修改操作的持续进行，越来越多的共享页面被分离出来，内存就会持续增长。
子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。save 900 1：含义是
距离上次备份900秒时，如果redis数据发生了至少1次变化，则执行bgsave；save m n ：下面两条同时满足才执行。
每隔100ms判断一次：
（1）当前时间-lastsave > m
（2）修改键数量 >= n
在指定的时间间隔内生成数据集的快照。
默认配置
save 900 1
#900秒后1个键及以上被改动时， 自动保存一次数据集 900秒统计一次？
save 300 10
#300秒后10个键及以上被改动时， 自动保存一次数据集 300秒统计一次？
save 60 10000
#60秒后10000个键及以上被改动时， 自动保存一次数据集 60秒统计一次？
save
当客户端向Redis server发送save命令请求进行持久化时，由于Redis是用一个主线程来处理所有,
save命令会阻塞Redis server处理其他客户端的请求，直到数据同步完成。
bgsave
bgsave是异步执行的，当执行bgsave命令之后，Redis主进程会fork 一个子进程将数据保存到rdb文件中，同步完数据之后，对原有文件进行替换，然后通知主进程表示同步完成。
AOF
- 记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。
- 第一次从内存中写入文件，然后追加，然后再重写？
配置
appendonly no
#是否打开 aof日志功能
appendfsync always
#每1个命令,都立即同步到aof. 安全,速度慢
appendfsync everysec
#折衷方案,每秒写1次
appendfsync no
#写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快,
no-appendfsync-on-rewrite yes:
#正在导出rdb快照的过程中,要不要停止同步aof
auto-aof-rewrite-percentage 100
#aof文件大小比起上次重写时的大小,增长率100%时,重写
auto-aof-rewrite-min-size 64mb
#aof文件,至少超过64M时,重写
appendfilename /var/dir/appendonly.aof
#文件的路径寸
Redis如何实现重写？
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
AOF重写机制
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,如果Redis的AOF当前大小>= base_size +base_size*100%。
(默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。
错误修复
redis-check-aof --fix appendonly.aof
甚至可以自己通过vim修改aof文件 不过不建议这样搞
同时使用AOF和RDB
Redis重启时， 它会优先使用 AOF 文件来还原数据集。
RDB和AOF优缺点
rdb持久化：故障数据丢失比aof严重，但是服务重启恢复数据快；
aof持久化：故障数据丢失较rdb少，但是服务启动时恢复数据慢，因为要把aof文件中指令执行一遍。
使用rdb还是aof持久化，在于你的业务场景对数据丢失承受能力和服务启动时数据恢复快慢来决定。
但是，普通要求下，建议使用rdb快照备份。UK主要用作缓存所以主要用的RDB方式能够接受缓存丢失等
Redis 4.0 混合持久化
Redis 4.0 带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。
于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。
