Redis的持久化方式
Redis有两种持久化方式：RDB和AOF
- RDB 是将Redis的内存数据生成一份快照保存在dump.rdb二进制文件中
- AOF是将每一次执行的修改命令都以追加写入的方式写入appendonly.aof文件中
RDB是redis的默认持久化方式，可以配置持久化策略：save N M，表示N秒内至少M个改动则会触发一次RDB操作，RDB持久化的时候不会阻塞Redis的读写请求，因为Redis从主线程中fock出一个子线程bgsave，可以共享主线程中的数据，当读取redis内存数据时，主线程的读请求不受影响，当写请求时，会借助写时复制技术，将该写请求会操作的数据拷贝一份出来写入dump.rdb，这样主线程可以继续处理写请求
RDB的优缺点：
优点：
dump.rdb是二进制文件，可以很快用于数据恢复
缺点：
- 如果redis宕机的话，会丢失上一次RDB同步到宕机之间的数据
- RDB 需要将内存的数据都写入到dump.rdb，如果频繁执行的话，开销比较大，影响性能
AOF是同步地将修改写入到appendonly.aof，能最大限度地减少数据丢失的风险，为什么说是最大限度而不是完全避免呢？先看ROF的刷盘策略：
- appendfsync always 每次执行命令都刷盘
- appendfsync everysec 每秒刷盘一次
- appendfsync no 由系统决定什么时候刷盘
当修改命令写入到文件缓存后，需要将缓存刷到磁盘才能真正完成持久化，所以如果刷盘策略不是第一种，则可能丢失短时间内的数据。
AOF重写，因为ROF持久化的是命令而不是具体数据，所以可能有一些命令是重复的，redis有一个机制称为bgrewriteof，用于生成新的aof文件。
比起RDB，ROF还是有一个缺点，就是重放命令来恢复数据效率太低了，Redis 4.0版本为了解决这个问题，提供了混合持久化方案：
在AOF重写时，执行一次RDB，加上增量AOF一起写入到appendonly.aof，这样在恢复数据时，就可以先将RDB恢复，再重放AOF，重启效率提高。