Redis持久化
RDB快照
redis内存数据库快照保存到dump.rdb二进制文件中。
RDB快照文件体积小，因为进行过压缩，是一个二进制文件，且RDB文件直接恢复即可，恢复速度很快。
在redis.conf配置文件中有关于rdb持久化方式的频率策略：
这里比如 save 60 10000代表的是60s内至少有10000个键被改动时，会自动生成并保存一个RDB快照文件。
可以手动执行RDB快照文件的生成，执行save命令或者bgsave命令即可。
save和bgsave命令
简单来说，save是主线程去写RDB内存快照文件的，而bgsave是fork一个子进程，用子进程去写RDB快照文件，不阻塞主线程去执行客户端发来的命令。（当然bgsave fork子进程的时候是阻塞的）。redis在触发生成RDB时是bgsave的方式。
bgsave的写时复制机制
bgsave是利用COW（copy on write）这个机制来fork一个子进程去执行生成RDB持久化文件，redis本身还可以继续执行命令。子进程运行之后，会读取redis进程的内存数据，写入RDB文件。这时如果主线程还执行写数据命令，那么也会对修改的数据复制一份副本，bgsave子进程会将这个副本数据写入RDB文件。
RDB缺点
- 虽然恢复速度很快，但是生成快照文件间隔之间redis挂了，那么这时没持久化到RDB文件的数据就会丢失。也就是RDB快照可能丢数据。
AOF持久化 （append only file)
AOF持久化机制，将修改的每一条指令记录进文件appendonly.aof中（先写入到buffer，再定时去fsync刷入磁盘）。当数据恢复时，会按照AOF文件中的写数据命令执行，来重建数据。
这种AOF文件因为存放原生写命令，所以文件会比较大，且恢复时要执行Redis写命令，所以恢复速度比较慢。（相对于RDB快照恢复）当然，这种持久化方式数据安全性更高，因为可以设置fsync的频率，默认是每秒去将aof文件fsync到磁盘中，数据安全性比RDB更高。
AOF重写
AOF文件中可能有比较多的没用指令，比如自增五次，那么可以重写为set key 5即可，redis会定期根据内存最新数据进行aof重写，来压缩下AOF文件。
AOF重写是和bgsave类似，是fork一个子进程去执行AOF文件的重写，不会阻塞其他客户端请求redis。
RDB和AOF的比较
Redis4.0之后的混合持久化方式
Redis 4.0之后提供了混合持久化方式。1
2-- 开启redis 混合持久化方式
# aof‐use‐rdb‐preamble yes
如果开启了混合持久化，那AOF在重写的时候，不再单纯去压缩无用的命令，会对此刻内存做RDB快照处理，并将此过程中新的写的命令追加到AOF文件，来生成新的AOF文件，覆盖原来的AOF文件。
这样redis在恢复时，可以先根据RDB快照文件去恢复（速度快、体积小），然后再重放后面增量的写命令（数据安全），效率和安全都得到了保障。