redis提供了两种方式实现持久化，即RDB和AOF
RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是说通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。创建副本后，可以对其备份或者恢复，恢复时是将快照文件直接读到内存里
备份是如何执行的呢？
redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
RDB保存的文件在配置文件redis.conf中有配置，默认是dump.rdb
RDB保存策略在配置文件redis.conf中有配置
save 900 1 #在900秒之后，如果至少有1个key发生变化，redis就会创建快照
save 300 10 #在300秒之后，如果至少有10个key发生变化，redis就会创建快照
save 60 10000 #在60秒之后，如果至少有10000个key发生变化，redis就会创建快照也可以手动保存快照
save：只管保存，其他不管，全部阻塞
bgsave：按照保存策略自动保存
RDB其他相关配置
stop-writes-on-bgsave-error yes当Redis无法写入磁盘时，直接关闭Redis的写操作
rdbcompression yes进行RDB快照保存时，将文件压缩
rdbchecksum yes在存储快照后，使用CRC64算法进行数据校验，但这样做会增加性能消耗，如果需要获得最大的性能，可以关闭此功能
RDB的备份和恢复
备份：先通过config get dir 查询rdb文件的目录，将*.rdb的文件拷贝到其他地方
恢复：关闭Redis，把备份的文件拷贝到工作目录下，启动Redis，备份数据会直接加载
RDB优缺点
优点：节省磁盘空间，恢复速度快
缺点：备份数据庞大时，比较消耗性能；如果Redis宕机了，会丢失最后一次快照后的所有修改
AOF
以日志的形式来记录每个写操作，将Redis执行过的所有写指令都记录下来追加到日志文件之中，Redis在启动之初会读取该文件重新构建数据
默认情况下Redis没有开启AOF，需要手动开启，配置文件redis.conf中
appendonly yesAOF保存的文件名可以在配置文件redis.conf中配置，默认为
appendfilename "appendonly.aof"AOF的备份机制和性能与RDB不同，但备份和恢复的操作和RDB是一样的，都是通过拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统就可以自动加载。如果遇到AOF文件损坏，可以通过以下命令进行恢复
redis-check-aof --fix appendonly.aofRedis提供3种AOF同步方案
appendfsync always
appendfsync everysec
appendfsync no始终同步：每次Redis有数据修改发生时都会写入AOF文件
每秒同步：每秒记入AOF一次，如果宕机，本秒的数据可能会丢失
不主动进行同步：让操作系统决定何时需要同步
AOF采用文件追加方式，随着时间的推移，文件会越来越大，为了避免出现这种情况，Redis提供了重写机制，当AOF文件的大小超过所设定的阈值时，Redis会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用bgrewriteaof命令
AOF重写
AOF文件持续增长过大时，会fork出一条新进程来将文件重写，遍历新进程的内存中数据，每条记录有一条set语句，重写aof文件的操作并没有读取旧的aof文件，而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件，最后用新的aof文件替换旧的aof文件
系统载入时或者上次重写完成时，Redis会记录此时AOF文件大小，设为base_size，如果Redis的AOF当前大小>=base_size + base_size * 100%且当前大小>=64MB的情况下，Redis会对AOF进行重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mbAOF优缺点
优点：备份机制更稳健，丢失数据概率更低；可读的日志文本，通过操作AOF文件，可以处理误操作
缺点：比RDB占用更多的磁盘空间；恢复备份速度慢；每次读写都同步的话，有一定的性能压力
RDB与AOF两种持久化方案如何选择
官方推荐两个都启用，此时redis会优先选择AOF
如果对数据不敏感，可以单独选择RDB
不建议单独使用AOF，因为可能会出现Bug
如果只是用于缓存，可以都不使用
