redis配置文件的持久化（详细对比）

一、redis持久化方式

Redis 提供了两种持久化方式，一种是基于快照形式的 RDB，另一种是基于日志形式的 AOF，每种方式都有自己的优缺点。

1.1、RDB持久化的概述

• RDB 基于内存快照，是 Redis 默认开启的持久化方式，并不需要我们单独开启。

• RDB 有两种持久化方式：手动触发 和 自动触发，手动触发使用以下两个命令：

  • save：会阻塞当前 Redis 服务器响应其他命令，直到 RDB 快照生成完成为止，对于内存比较大的实例会造成长时间阻塞，所以线上环境不建议使用

  • bgsave：Redis 主进程会 fork 一个子进程，RDB 快照生成有子进程来负责，完成之后，子进程自动结束，bgsave 只会在 fork 子进程的时候短暂的阻塞，这个过程是非常短的，所以推荐使用该命令来手动触发

• 大部分情况，我们会通过配置 时间间隔 触发 RDB 文件写入。

1.2、AOF持久化

• Redis 默认并没有开启 AOF 持久化方式，需要我们自行开启，与 RDB 不同的是 AOF 是以记录操作命令的形式来持久化数据的，我们可以查看以下 AOF 的持久化文件 appendonly.aof

• appendfsync 的配置项有以下三种值可选：
  always：每一次系统 serverCorn 函数调用就刷新一次缓存区
  everysec：每秒执行一次磁盘写入，期间所有的命令都会存储在 aof 缓存区
  no：不做控制，任由操作系统决定什么时候刷新缓冲区
  redis 默认配置是 everysec，即每秒刷新一次缓存区。

二、redis 配置文件

2.1、RDB 持久化配置

• save格式：
  save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。

[root@localhost ~]# vim /etc/redis/6379.conf
save 900 1    #900秒之内至少一次写操作
save 300 10   #300秒内至少10次操作
save 60 10000 #60秒内至少10000次写操作

#生成快照失败时，主线程是否停止写入
stop-writes-on-bgsave-error yes
 
#是否采用压缩算法存储
rdbcompression yes
 
#数据恢复时是否检测 RDB文件有效性
rdbchecksum yes

#RDB快照生成的文件名称，一般采用默认的dump.rdb
dbfilename dump.rdb
 
#快照生成的路径，AOF也是存放在这个路径下面
dir /var/lib/redis/6379

• 默认文件名为dump.rdb

[root@server1 ~]# cd /var/lib/redis/6379/
[root@server1 6379]# ls
dump.rdb

2.2、AOF持久化配置

• 开启AOF 持久化就在 redis.conf 配置文件中将 appendonly no 调整为 appendonly yes 。

[root@localhost ~]# vim /etc/redis/6379.conf
#开启AOF持久化
appendonly yes   

#AOF文件名称，默认值为 appendonly.aof
appendfilename "appendonly.aof"

# appendfsync always
appendfsync everysec   默认推荐
# appendfsync no

#忽略最后一条可能存在问题的指令
aof-load-truncated yes

2.3、AOF 重写

• 理论上来说，随着 redis 服务器运行时间的持续，生成的 aof 文件只会越来越大，redis 提供 AOF 重写策略帮助优化和压缩 aof 文件。能将几百条甚至几千条的命令日志，重写优化成个位数。带给我们最直观的好处就是，aof 文件体积变小，数据恢复速度变快。

• 一般来说，我们可以通过向 redis 服务器发送 bgrewriteaof 命令触发服务器对 aof 文件进行重写，如果当前有正在运行的重写子进程，则本次重写 会推迟执行，否则，直接触发一次重写。

• 除此之外，我们还可以在配置文件中配置 aof 文件达到多大，自动触发文件重写。

vim /etc/redis/6379.conf

#设置为yes表示rewrite操作不进行同步fsync,暂时存在内存中,避免造成磁盘IO操作冲突，默认为no，建议yes。
no-appendfsync-on-rewrite no
 
#当前aof文件大小超过上一次重写的aof文件大小的百分之多少时进行重写新的日志进程
auto-aof-rewrite-percentage 100
 
#允许重写aof文件的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的重写操作
auto-aof-rewrite-min-size 64mb

三、RDB与AOF的持久化对比

3.1、RDB 优缺点

RDB 文件中保存的是 redis 内存中所有的数据一份快照。

• 优点：
  1、相同的数据量下，rdb 文件要小于 aof 文件，且恢复速度要快于 aof
  2、rdb 文件中是整个数据的完整备份快照，数据存储紧凑即便不同版本的 redis，也能顺利恢复
  3、整个 rdb 持久化，只需要 fork 一个子进程进行持久化即可，父进程依然可以提供服务，效率最大化。
• 缺点：
  1、容易丢失数据，即便配置了事件时间触发备份，也至少丢失一秒数据
  2、如果数据量太大，fork 子进程的时候会阻塞毫秒级别时间

3.1、AOF 优缺点

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

• 优点：
  1、相较于 RDB，AOF 数据可靠性更强，最多丢失一秒数据
  2、数据库容错率变好，一些误操作可以通过直接改 aof 文件进行回退
• 缺点：
  1、AOF 文件通常较大且恢复效率比不上 RDB，不适合做数据冷备份
  总的来说，AOF 策略会使数据稳定性更高，具有更完整的数据备份，RDB 恢复效率高适合做灾难恢复，建议生产环境上两者都开启。