前提
Redis持久化
redis是基于内存的，如果不想办法将数据保存在硬盘上，一旦redis重启(退出/故障)，内存的数据将会全部丢失。
Redis提供了两种持久化方法：
RDB(基于快照)，将某一时刻的所有数据保存到一个RDB文件中。AOF(append-only-file)，当Redis服务器执行写命令的时候，将执行的写命令保存到AOF文件中。
RDB
保存某个时间点的全量数据快照
手动触发
SAVE：阻塞Redis的服务器进程，知道RDB文件被创建完毕BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程，使用lastsave指令可以查看最近的备份时间- 自动触发
根据redis.conf配置里的save m n定时触发（用的是BGSAVE）
主从复制时，主节点自动触发
执行Debug Relaod
执行Shutdown且没有开启AOF持久化
注意：Redis服务器在启动的时候，如果发现有RDB文件，就会自动载入RDB文件(不需要人工干预)
RDB的优缺点
优点：
RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照，适合备份，全量复制等场景。
且加载RDB恢复数据远远快于AOF的方式。
缺点：
没办法做到实时持久化/秒级持久化，因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
RDB的相关配置
//在n秒内修改m条数据时创建RDB文件
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes //bgsave出错时停止写入
rdbcompression yes //压缩RDB文件
rdbchecksum yes //校验文件是否损坏AOF
与RDB不一样的是，AOF记录的是命令，而不是数据。
如何开启AOF?
只需在配置文件中将appendonly设置为yes即可。
AOF的工作流程：
1、所有的写入命令追加到aof_buf缓冲区中。
2、AOF会根据对应的策略向磁盘做同步操作。刷盘策略由appendfsync参数决定。
3、定期对AOF文件进行重写。重写策略由auto-aof-rewrite-percentage，auto-aof-rewrite-min-size两个参数决定。
appendfsync参数有如下取值：
appendfsync always # 每次有数据修改发生时都会写入AOF文件。
appendfsync everysec # 每秒钟同步一次，该策略为AOF的默认策略。
appendfsync no # 从不同步。高效但是数据不会被持久化。AOF重写
为什么要重写？
重写后可以加快节点启动时的加载时间
重写后的文件为什么可以变小？
进程内超时的数据不用再写入到AOF文件中
多条写命令可以合并为一个
重写条件
1、手动触发
直接调用bgrewriteaof命令
2、自动触发
先来看看有关参数：auto-aof-rewrite-min-size：执行AOF重写时，文件的最小体积，默认值为64MB。 auto-aof-rewrite-percentage：执行AOF重写时，当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。
只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写。
后台重写
Redis将AOF重写程序放到子进程里执行(BGREWRITEAOF命令)，像BGSAVE命令一样fork出一个子进程来完成重写AOF的操作，从而不会影响到主进程。
AOF后台重写是不会阻塞主进程接收请求的，新的写命令请求可能会导致当前数据库和重写后的AOF文件的数据不一致！
为了解决数据不一致的问题，Redis服务器设置了一个AOF重写缓冲区，当子进程完成重写后会发送信号让父进程将AOF重写缓冲区的数据写到新的AOF文件。
RDB和AOF比较
RDB和AOF并不互斥，它俩可以同时使用。
RDB的优点：载入时恢复数据快、文件体积小。
RDB的缺点：会一定程度上丢失数据(因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。)
AOF的优点：丢失数据少(默认配置只丢失1秒的数据)。
AOF的缺点：恢复数据相对较慢，文件体积大
如果Redis服务器同时开启了RDB和AOF持久化，服务器会优先使用AOF文件来还原数据(因为AOF更新频率比RDB更新频率要高，还原的数据更完善)
参考：从零单排学Redis
