Redis持久化：RDB和AOF的区别

一、基本理解

RDB：存储所有数据

AOF：存储所有命令行

二、RDB和AOF的介绍

RDB和AOF都会创建(fork)出一个子进程来实现功能。

1.RDB(Redis DataBase)

可以根据设定的条件来备份所有的数据，例如满足下面条件时进行备份：

save 900 1 # 900秒（15分钟）内有1个写入

save 300 10 # 300秒（5分钟）内有10个写入

save 60 10000 # 60秒（1分钟）内有10000个写入
但这样可能会丢失几分钟的数据，所以引出了AOF。

2.AOF(Append Only File)

AOF文件：

记录所有执行的写入命令到AOF文件中，但肯定不能每执行一条写入命令就记录到文件中，那会严重拖垮性能，于是会准备一个缓冲区，区别于这个缓冲区，操作系统也有一个缓冲区，所以我们需要通过刷新来保证正常写入，可以根据设定的参数来写入并刷新AOF文件，参数如下：

always: 每个事件周期都同步刷新一次
everysec: 每一秒都同步刷新一次
no: 我只管写，让操作系统自己决定什么时候真正写入

AOF重写：

在AOF文件过大时会对这些命令进行AOF重写，去掉无用的命令，以达到简化命令缩小文件体积的效果。例如：
RPUSH name_list ‘高等数学’
RPUSH name_list ‘离散数学’
RPUSH name_list ‘大学物理’
可以合并成一条搞定：
RPUSH name_list ‘高等数学’ ‘离散数学’ ‘大学物理’

AOF重写缓冲区：

如果子进程在压缩重写过程中，AOF文件有了新的写入，那么新的写入会进入缓冲区，重写结束后，缓冲区中的命令会被写入到新的AOF文件中

三、RDB和AOF的区别

1.RDB（Redis DataBase）

原理：
RDB持久化是通过创建数据集的快照（snapshot）在特定时间点保存数据的。
快照生成是在Redis在后台子进程中完成的，父进程会继续处理客户端请求。
默认情况下，Redis会在特定的间隔内，根据写入数据的频次（如1分钟内至少达到N个key修改），自动生成RDB文件。
优点：
效率高：RDB快照生成对性能影响小，尤其是在恢复大数据集时，RDB方式相比AOF的重放日志速度要快很多。
数据压缩：RDB文件是压缩的二进制格式，所以相比原始的数据集会占用更少的磁盘空间。
适合备份：可以非常方便地将数据集的快照保持在安全的硬盘上，适合灾难恢复。
资源占用较少：相比AOF，RDB在其它时间点占用的系统资源更少，尤其是在数据改动不频繁时。
缺点：
数据丢失：因为是时间点快照，所以在RDB最后一次保存后和故障发生前的数据更新将会丢失，丢失的数据可能会更多。
可能占用大量内存：在保存RDB文件时，如果数据集很大，Redis的复制操作可能会占用与现有数据集几乎同样大小的内存。
频繁写盘：在高频更新数据的场景下，RDB持久化可能会因为频繁的保存数据到硬盘造成磁盘IO压力。

2.AOF（Append Only File）

原理：
AOF持久化是通过保存Redis服务器所处理的每一个写命令来记录数据变化的。
这些命令将被追加到AOF文件的末尾，Redis重启时通过重放这些命令来恢复原始的数据集。
Redis允许你选择不同的fsync策略，例如：每个写命令（fsync=always）、每秒（fsync=everysec）或者不同步（fsync=no）。
优点：
数据完整性好：可以做到近乎实时的数据备份，数据丢失几率小。
可读性强：AOF文件由一系列的文本命令组成，方便理解和分析。
更健壮：AOF中使用了一种被称为append的操作，在使得数据更加安全方面比RDB要高。
缺点：
占用空间大：由于记录了所有的写操作，AOF文件的大小通常会大于RDB文件。
恢复慢：相比于RDB的二进制方式，AOF在恢复大数据集时需要更长的时间，因为需要重新执行所有的写命令。
性能开销：尽管可以配置多种fsync策略减少对性能的影响，但持续的IO操作，特别是fsync设置为always的情况下，会对性能产生影响。

四、总结

为了结合两者的优势而规避他们的缺点，Redis通常建议同时开启RDB和AOF。

使用AOF来提供数据完整性保护，而RDB则提供性能及数据恢复速度的优势。

同时开启时，数据恢复首先会尝试使用AOF文件，因为它更完整，如果AOF无法使用，再回退到RDB恢复。