redis持久化

在redis.conf中配置，rdb和aof不冲突，如果都配置了，那么两种持久化方式都会做

rbd快照：存储在dump.rdb二进制文件中

#save 60 1000 60s内有1000个键改动时候，保存一次数据集

可以通过客户端执行save和bgsave手动生成rdb快照文件并覆盖原有rdb快照文件

save是同步命令，bgsave是异步命令，bgsave会从redis主进程fork（fork()是linux函数）出一个子进程专门来生成rdb文件

aof：rdb快照方式不是非常耐久，如果redis因为某些原因宕机会导致最近数据的丢失，因此增加了aof这种耐久的持久化方式，可以将修改的每条指令记录到aof文件中

#appendonly yes 开启aof持久化，持久化文件生成到aof文件（以下策略只能选一种）

appendfsync always:每次有命令做一次持久化，性能较低

appendfsync everysecond:每秒做一次持久化，即把每一秒内的数据持久化到aof，这样故障时只丢失一秒钟的数据（官方推荐该持久化方式）

appendfsync no:从不持久化，交由操作系统处理，不太安全

aof重写：aof方式持久化文件在恢复数据过程中是根据指令来一条一条恢复，那么就存在很多无用的指令，比如

incr rcount--->1

incr rcount--->2

incr rcount--->3

这里对rcount做了3次叠加操作，那么aof恢复数据如果根据指令依次恢复，那么前面恢复1、2其实就是无用的操作，rcount只要根据最后一条指令恢复成3就好了，针对aof文件存在太多没用指令的情况，aof会定期根据内存的最新数据生成aof文件，即进行重写：

incr rcount--->1

incr rcount--->2

incr rcount--->3

aof重写配置如下：

#auto-aof-rewrite-min-size 64mb //aof文件至少要达到64mb才会自动重写，文件太小恢复速度本身就很快，重写的意思不太，所以这个参数一般不要设置太小

#auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%，则触发重写

当然aof也可以手动触发，客户端指令：bgrewriteaof

注意，aof重写redis会fork出一个子进程去做，所以对redis正常的命令不会有阻塞影响，如果既有rdb持久又有aof持久化，则会优先选择aof文件恢复数据，因为aof数据相对安全一些

rdb和aof比较：rbd由于是二进制快照文件，持久化文件较小，数据恢复速度快。但是弊端在于可能出现数据丢失。aof数据文件较大，恢复速度较慢，但是比较安全。

那么rdb和aof选择哪个？

redis4.0混合持久化（推荐该持久化方式，效率较高）：

通过配置开启：#aof-use-rdb-preamble yes，如果开启了混合持久化，aof在重写时，不再单纯将内存数据转换为resp命令写入aof文件，而是将重写这一刻之前的内存做rdb快照处理，并且将rbd快照内容和增量的aof修改内容数据的命令存在一起，都写入到新的aof文件，新的文件一开始不叫appendonly.aof，等到重写完新的aof文件后才会改名，原子覆盖原有的aof文件，完成新旧aof文件替换。所以在redis重启的时候，先加载rdb内容，在重放增量aof日志就可以完全替代之前的aof全量文件，所以重启效率大大提升。      简单而言，就是最新的指令会以aof格式写入，之前的旧指令以rbd格式写入。