redis持久化之rdb和aof（redis持久化rdb和aof区别）

一、rdb持久化

1.rdb触发条件

手动触发：save和bgsave，其中save命令为阻塞命令，会阻塞当前的Redis服务器，造成服务不可用，直到RDB过程完成

自动触发：redis.conf文件里相关配置如下：

1)save m n：代表Redis服务器在m秒内数据存在n次修改时，自动触发rdb。这个参数比较关键。

2)stop-writes-on-bgsave-error：如果是yes，当bgsave命令失败时Redis将停止写入操作。

3)rdbcompression：是否对RDB文件进行压缩，但是在LZF压缩消耗更多CPU

4)rdbchecksum：是否对RDB文件进程校验

5)dbfilename：配置文件名称，默认dump.rdb

6)dir：配置rdb文件存放的路劲，这个参数比较重要。

2.rdb的基本流程

1)redis执行bgsave命令，Redis判断当前存在正在进行执行的子进程，如RDB/AOF子进程，存在bgsave命令直接返回

2)fork出子进程，fork操作中Redis父进程会阻塞

3)fork完成返回, redis-server可继续提供服务，响应其他命令

4)子进程进程对内存数据生成快照rdb文件

5)子进程通知父进程快照文件已经生成完成

3.rdb文件分析工具

可以使用redis-rdb-tools来分析rdb快照文件，该工具可以把rdb快照文件生成json文件

4.rdb持久化优缺点

RDB持久化方式的优点：非常适合全量备份；恢复速度比AOF快

RDB持久化方式的缺点：RDB方式没有办法做到实时持久化；

二、aof持久化

RDB持久化方式不能提供强一致性，如果Redis进程崩溃，那么两次RDB快照生成之间的数据也会随之丢失。那么AOF的出现很好的解决了数据持久化的实时性，AOF以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令来恢复数据。AOF会先把命令追加在AOF缓冲区，然后根据对应策略写入硬盘（appendfsync）

1.触发条件

手动触发：使用bgrewriteaof命令

自动触发：redis.conf相关配置如下

1)appendonly：是否打开AOF持久化功能

2)appendfilename：AOF文件名称

3)appendfsync：同步频率

4)auto-aof-rewrite-min-size：如果文件大小小于此值不会触发AOF，默认64MB

5)auto-aof-rewrite-percentage：Redis记录最近的一次AOF操作的文件大小，如果当前AOF文件大小增长超过这个百分比则触发一次重写，默认100

关于appendfsync参数的可配置值，说明如下：

1）always：命令写入aof缓冲区后，每一次写入都需要同步，直到写入磁盘（阻塞，系统调用fsync）结束后返回。显然和Redis高性能背道而驰，不建议配置

2）everysec：命令写入aof缓冲区后，在写入系统缓冲区直接返回（系统调用write），然后有专门线程每秒执行写入磁盘（阻塞，系统调用fsync）后返回

3）no：命令写入aof缓冲区后，在写入系统缓冲区直接返回（系统调用write）。之后写入磁盘（阻塞，系统调用fsync）的操作由操作系统负责，通常最长30s

2.AOF执行流程

1）所有的写入命令追加到aof缓冲区

2）AOF缓冲区根据对应appendfsync配置向硬盘做同步操作

3）定期对AOF文件进行重写

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

3.AOF追加阻塞分析

1）主线程负责AOF缓冲区

2）AOF线程负责每秒一次同步磁盘操作,并记录最近一次同步时间.

3）主线程对比AOF同步时间，如果距离上次同步时间在两秒内,主线程直接返回。如果距离上次同步时间超过两秒(意识是现在还在同步),主线程将会被阻塞, 直到同步完成。

通过命令info persistence观察aof_delayed_fsync结果，可以目前获取该redis已经追加阻塞的次数

4.AOF为何会存在文件变小？

1）多条写入命令可以合并成一条

2）重写后AOF文件只保留最终数据的写入命令

5.AOF优缺点

AOF持久化方式的优点：最多丢失1-2s内的数据（最多丢失2s数据，因为AOF追加阻塞）

AOF持久化方式的缺点：AOF文件比RDB文件大；可能导致追加阻塞

备注：正是由于AOF追加刷盘时会存在阻塞，所以推荐主从架构模式下，由备启用AOF。