Redis的RDB和AOF对比介绍

RDB的优缺点

RDB的优点：

· RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份， 并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

· Redis加载RDB恢复数据远远快于AOF的方式。

RDB的缺点：

· RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。

· RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

使用AOF

开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。

流程如下：

1）所有的写入命令会追加到aof_buf（缓冲区）中。

2）AOF缓冲区根据对应的策略向硬盘做同步操作。

3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。

下面介绍关于AOF的两个疑惑：

1）AOF为什么直接采用文本协议格式？可能的理由如下：

· 文本协议具有很好的兼容性。

· 开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销。

· 文本协议具有可读性，方便直接修改和处理。

2）AOF为什么把命令追加到aof_buf中？Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。先写入缓冲区aof_buf中，还有另一个好处，Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。

 重写机制

AOF重写过程可以手动触发和自动触发：

· 手动触发：直接调用bgrewriteaof命令。

· 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。

· auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。

· auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。

自 动 触 发 时 机 =aof_current_size>auto-aof-rewrite-min- size&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite- percentage

其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。

当触发AOF重写时，内部做了哪些事呢？

1）执行AOF重写请求。

如果当前进程正在执行AOF重写，请求不执行。如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行。

2）父进程执行fork创建子进程，开销等同于bgsave过程。

3.1 ）主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。

3.2 ）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应写命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。

4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。

5.1 ）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。

5.2 ）父进程把AOF重写缓冲区的数据写入到新的AOF文件。

5.3 ）使用新AOF文件替换老文件，完成AOF重写。