关于Redis中的RDB和AOF策略

对于RDB和AOF的理解与补充

Redis中的数据持久化策略（RDB）

Redis是一个内存数据库，所有的数据都直接保存在内存中，那么，一旦Redis进程异常退出，或服务器本身异常宕机，存储在redis中的数据就会凭空消失

Redis作为一个优秀的中间件，必定时拥有自己的持久化数据备份机制的，redis中主要有两种持久化策略用于将存储在内存中的数据备份到磁盘上，并且在服务器重启时进行备份文件重载。

RDB 和 AOF 是 Redis 内部的两种数据持久化策略，这是两种不同的持久化策略，一种是基于内存快照，一种是基于操作日志，那么本篇就先来讲讲 RDB 这种基于内存快照的持久化策略。

一、什么是 RDB 持久化策略

RDB（redis database），快照持久化策略。RDB 是 redis 默认的持久化策略，你可以打开 redis.conf，默认会看到这三条配置。

save 900 1            900秒内执行一次set操作 则持久化1次  
save 300 10           300秒内执行10次set操作,则持久化1次
save 60 10000         60秒内执行10000次set操作,则持久化1次

RDB又分为两种，一种是同步的，调用save命令可触发redis进行RDB文件生成备份，但是这个是一个同步命令，在备份完成之前，redis服务器不响应客户端任何请求，另一种是异步的，调用bgsave命令，redis服务器fork一个子进程进行RDB文件备份生成，与此同时，主进程依然可以响应客户端请求。

显然，异步的 RDB 生成策略才是主流，除了某些特殊情况，相信不会有人会在生产环境中用 save 命令阻塞 redis 服务来生成 RDB 文件的。

save 和 bgsave，这两个命令需要我们手动的在客户端发送请求才能触发，我们叫做主动触发。

1、save 配置

save配置是一个非常重要的配置。它配置了 redis 服务器在什么情况下自动触发 bgsave 异步 RDB 备份文件生成。

基本语法格式：save <seconds> <changes>

当 redis 数据库在 秒内，数据库中的 keys 发生了 次变化，那么就会触发 bgsave 命令的调用。

2、dbfilename 配置

dbfilename 配置项决定了生成的 RDB 文件名称，默认配置为 dump.rdb。

名称：dbfilename dump.rdb
3、rdbcompression 配置

rdbcompression 配置的是 rdb 文件中压缩启用配置，基本语法格式：rdbcompression yes(|no)

4、stop-writes-on-bgsave-error 配置

stop-writes-on-bgsave-error 配置了，如果进行 RDB 备份文件生成过程中，遭遇错误，是否停止 redis 提供写服务，以警示用户 RDB 备份异常，默认是开启状态。

5、dir 配置

dir 配置的是 rdb 文件存放的目录，默认是当前目录。dir ./

6、rdbchecksum 配置

rdbchecksum 配置 redis 是否使用 CRC64 校验算法校验 RDB 文件是否发生损坏，默认开启状态，如果你需要提升性能，可以选择性关闭。

rdbchecksum yes(|no)

AOF是redis中的另一种数据持久化策略，它基于操作日志，也是一个很优秀的持久化策略

 一、什么是 AOF 持久化策略

AOF即append only file 当redis采用这种数据持久化策略的时候，每当redis服务器收到一条更新命令时，操作结束后会将这条命令添加到aof内存缓冲区，特定的时间下刷新缓冲区到磁盘文件中，也就是我们的aof文件

默认的 redis 启动配置文件中，会有这么两条配置：

 appendonly 指定 redis 是否启用 AOF 持久化策略，appendfilename 指明生成的 AOF 文件名称。

edis.conf 中还有 appendfsync 这么一条配置，它指明 AOF 文件的写入频率，即便 linux 中文件 IO 使用的高效的 epoll，但每收到一条更新命令就进行一次文件 IO，未免也太低效，况且也没必要。

appendfsync 的配置项有以下三种值可选：

• always：每一次系统 serverCorn 函数调用就刷新一次缓存区
• everysec：每秒执行一次磁盘写入，期间所有的命令都会存储在 aof 缓存区
• no：不做控制，任由操作系统决定什么时候刷新缓冲区

redis 默认配置是 everysec，即每秒刷新一次缓存区。

二、AOF 重写

随着redis服务器运行时间的持续，生成的aof文件只会越来越大，redis 提供 AOF 重写策略帮助优化和压缩 aof 文件。

三、RDB 与 AOF

RDB基于内存快照，有两种方式save和bgsave，前者会阻塞redis服务，后者是异步fork子进程不影响主进程提供服务，大部分情况，我们会通过配置时间间隔触发RDB文件写入，RDB文件中国保存的是redis内存中所有的数据一份快照

优点是：

1.相同的数据量下，rdb文件要小于aof文件，且恢复速度要快于aof

2.rdb文件中是整个数据的完整的备份快照，数据存储紧凑即便不同版本的redis，也能顺利恢复

3.整个rdb持久化，只需要fork一个子进程进行持久化，父进程依然可以提供服务，效率最大化

缺点是：
1.容易丢失数据，即便配置了事件时间触发备份，也至少丢失一秒数据

2.如果数据量太大，fork子进程的时候会阻塞毫秒级别时间

AOF是基于命令操作日志，每条更新命令都会被刷到缓存区，然后在特定的时间节点被写入apf磁盘文件

优点是：

1.相较于RDB，AOF数据可靠性更强，最多丢失一秒数据

2.数据库容错率变好，一些误操作可以通过直接改aof文件进行回退

缺点是：

1.AOF文件通常较大且恢复效率比不上RDB，不适合做数据备份

总的来说，AOF 策略会使数据稳定性更高，具有更完整的数据备份，RDB 恢复效率高适合做灾难恢复，建议生产环境上两者都开启。