RDB和AOF

RDB：

rdb就是在指定的时间间隔把内存中的数据集快照写入磁盘。

Redis会单独fork一个子进程来进行持久化，会先将数据写入一个临时文件，待持久化过程结束后，再用这个临时文件替换上次持久化好的文件。

对应产⽣的数据⽂件为 dump.rdb

优点：

1.性能最大化。对于 Redis 的服务进程而言，在开始持久化时，它唯一需要做的只是 fork 出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行 IO 操作了。也就是说，RDB 对 Redis 对外提供的读写服务，影响非常小，可以让 Redis 保持高性能。

2.性能最大化。对于 Redis 的服务进程而言，在开始持久化时，它唯一需要做的只是 fork 出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行 IO 操作了。也就是说，RDB 对 Redis 对外提供的读写服务，影响非常小，可以让 Redis 保持高性能。

3.非常适合冷备份，对于灾难恢复而言，RDB 是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

缺点：

因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。所以，RDB 实际场景下，需要和 AOF 一起使用。

AOF：

aof是以日志的形式来记录每一个写操作（增量状态），将redis执行过的所有写指令记录下来，读操作不记录，只许追加文件但不可以改写文件。

具体的流程的话就是，

客户端的请求写命令，append追加到我AOF的缓冲区内；

aof缓冲区根据aof持久化策略[always/everysec/no]将操作同步到aof磁盘文件中；

aof文件大小超过重写策略或者手动重写的时候，会对aof进行rewrite重写，压缩aof文件容量；

redis服务重启的时候会重新reload加载aof文件中的写操作以达到数据恢复的目的。

优点：

1.数据安全，三种同步策略：每秒同步、每修改同步、不同步，一旦数据据宕机，每秒同步也只丢失一秒的数据，。

2.aof中的rewirte机制，定期对aof进行重写，达到压缩的目的。

3.通过append模式写文件，即使中途服务器宕机也不会已存在的内容，可以通过redis-check-aof工具解决数据一致性的问题。

缺点：

1.aof比起rdb占用更大的磁盘空间。

2.每一次读写都需要同步，带来了一定的性能压力。

3.备份恢复速度慢。

区别：

AOF文件比RDB更新频率高，优先使用AOF还原数据，AOF安全更大。

RDB性能比AOF性能好。

如果两个都配置了，优先使用AOF。