RDB：
有save和bgsave两种方式
- save:会使redis处于阻塞状态,直到RDB完成,才会继续响应其它的命令.对redis性能影响非常大.
- bgsave:在时间间隔内fork⼀个⼦进程将内存中的数据集快照写⼊磁盘，先将数据集写⼊临时⽂件，写⼊成功后，再替换之前的⽂件，用二进制压缩存储。redis只会在fork一个子进程的时候占用一点点时间.
RDB优点:
- 整个Redis数据库将只包含⼀个文件 dump.rdb,还是经过压缩的二进制文件，占用空间很小，方便持久化。
- 保存了 Redis 某个时间点的数据集，很适合用于做备份。
- 性能最大化，子进程来进行持久化，主进程不会进⾏任何 IO 操作，保证了 redis 的高性能 .
- 相对于数据集⼤时，比AOF 的启动效率更高。
RDB缺点：
数据安全性低。如果持久化的时候redis 发生故障，会丢失最后一次持久化的数据,所以这种方式更适合数据要求不高的时候.
fock子进程过程中redis也是不能执行操作的,所以进行RDB操作的时间间隔一定不能太短.而且,如果当数据集较大时，也可能会导致整个服务器停止服务⼏百毫秒，甚至是秒级。
AOF：
以日志的形式记录服务器所处理的每⼀个写、删除操作，查询操作不会记录，以文本的方式记录，不断追加,可以打开⽂件看到详细的操作记录 .
三种追加方式(fsync):
- everysec :每秒同步:异步完成,先将操作写入一个缓存,每秒从缓存同步到磁盘一次,效率高,但是可能丢失数据.
- always:每修改同步:每一次发生增删改都记录操作.数据安全性高,最多丢失一个操作.
- no:不同步,把操作写入缓存,由操作系统来决定什么时候写入磁盘.
AOF优点：
- AOF 比 RDB可靠。你可以设置不同的 fsync 策略：no、everysec 和 always。默认是 everysec，在这种配置下，redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。
- 通过 append 模式写件，即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等等），可以通过 redis-check-aof 工具修复这个问题。
- AOF 机制的 rewrite 模式。定期对AOF文件进行重写，以达到压缩的目的(比如有先有一个set age 21,后面又有一个set age 22,则前面哪个set重写后会被清楚).
AOF缺点：
- 相同的数据集，AOF 文件的大小一般会比 RDB 文件大，且恢复速度慢。
- 数据集⼤的时候，比rdb 启动效率低。
- 运行效率没有RDB高,AOF文件比RDB更新频率高，
总结：优先使用AOF还原数据，AOF比RDB更安全也更大，RDB性能比AOF好， 如果两个都配了优先加载AOF。
网友评论