Redis持久化——RDB和AOF

一、持久化

1.redis所有数据都是保存在内存中，redis持久化，就是把对数据的更新异步地保存到磁盘上。

2.持久化实现方式

• 快照方式持久化

        快照方式持久化就是在某时刻把所有数据进行备份。

• 写日志方式持久化

       写日志方式持久化就是把用户执行的所有写指令备份到文件中，还原数据时只需把备份的所有指令重新执行一遍即可。

二、RDB

1.什么是RDB

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb的二进制文件中。

在redis运行时，RDB程序将当前内存中的数据库快照保存到磁盘文件中， 在 Redis 重启动时， RDB 程序可以通过载入 RDB 文件来还原数据库的状态。

2.RDB的持久化配置

# 时间策略
# 900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份
save 900 1
save 300 10
save 60 10000

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /home/work/app/redis/data/

# 如果持久化出错，主进程是否停止写入
# 当备份进程出错时，主进程就停止接受新的写入操作，是为了保护持久化的数据一致性问题
stop-writes-on-bgsave-error yes

# 是否压缩
# 建议没有必要开启 开启压缩会带来更多的CPU消耗
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

3.RDB的三种主要触发机制

（1）save 命令（同步数据到磁盘上）

         由于 save 命令是同步命令，会占用Redis的主进程。若Redis数据非常多时，save命令执行速度会非常慢，阻塞所有客户端的请求。

（2）bgsave命令（异步保存数据到磁盘上）

        会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。

（3）自动生成RDB

        通过配置文件对redis进行设置，在上面的持久化配置中的 save，满足条件时，自动进行数据保存操作。

4.RDB工作原理

（1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进 程，如RDB/AOF子进程，如果存在bgsave命令直接返回。

（2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通 过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒

（3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。

（4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后 对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的 时间，对应info统计的rdb_last_save_time选项。

（5）进程发送信号给父进程表示完成，父进程更新统计信息，具体见 info Persistence下的rdb_*相关选项

5.RDB优缺点

优点：

• RDB是一个非常紧凑的文件，它保存了某个时间点得数据集，非常适用于数据集的备份。
• RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复。
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
• 与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。

缺点：

• 耗时、耗性能。RDB 需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的请求。
• 不可控、丢失数据。如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你。虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作)，是Redis要完整的保存整个数据集是一个比较繁重的工作，你通常会每隔5分钟或者更久做一次完整的保存，万一在Redis意外宕机，你可能会丢失几分钟的数据。

三、AOF

1.什么是AOF

RDB在备份时会丢失部分数据，并不是非常耐久，这时出现了另一种完全耐久的持久化方式：AOP持久化。

首先通过配置文件打开AOF方式

appendonly yes

打开AOF后，每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加到 AOF 文件的末尾。这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

AOF运行原理-创建

AOF运行原理-恢复

2.AOF持久化的三种策略

always

每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。

everysec

每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

no

从不 fsync ：将数据交给操作系统来处理，由操作系统来决定什么时候同步数据。更快，也更不安全的选择。

3.AOF重写

随着写入命令的不断增加，AOF文件也会变得越来越大，有时候会对一个数据多次操作，操作的命令都会被记录到AOF文件中，然而实际上，只需保存最后结果即可，大大减少了AOF文件中的命令。所以就出现了AOF重写，执行 bgrewriteaof 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。

Redis 2.2 需要自己手动执行 bgrewriteaof 命令； Redis 2.4 则可以通过配置自动触发 AOF 重写。

AOF重写的实现方式

• bgrewriteaof命令 Redis bgrewriteaof

        命令用于异步执行一个 AOF（AppendOnly File）文件重写操作。重写会创建一个当前AOF文件的体积优化版本。即使 bgrewriteaof 执行失败，也不会有任何数据丢失，因为旧的AOF文件在 bgrewriteaof 成功之前不会被修改。

 

• AOF重写配置

# 触发AOF文件执行重写的最小尺寸
auto-aof-rewrite-min-size 64mb

# 触发AOF文件执行重写的增长率
auto-aof-rewrite-percentage 100

# 当AOF文件的体积大于64Mb，并且AOF文件的体积比上一次重写之久的体积大了至少一倍（100%）时，Redis将执行 bgrewriteaof 命令进行重写

4.AOF相关配置

# 开启AOF持久化方式
appendonly yes

# AOF持久化文件名
appendfilename appendonly-<port>.aof

# 每秒把缓冲区的数据同步到磁盘
appendfsync everysec

# 数据持久化文件存储目录
dir /var/lib/redis

# 是否在执行重写时不同步数据到AOF文件
# 这里的 yes，就是执行重写时不同步数据到AOF文件
no-appendfsync-on-rewrite yes

# 触发AOF文件执行重写的最小尺寸
auto-aof-rewrite-min-size 64mb

# 触发AOF文件执行重写的增长率
auto-aof-rewrite-percentage 100

5.AOF的优缺点

优点：

• redis更加耐久，一旦出现故障，最多丢失1秒的数据。
• AOF 文件有序地保存了对数据库执行的所有写入操作。
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写。

缺点：

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB

四、RDB和AOF对比

参考文章 https://segmentfault.com/a/1190000016021217?utm_source=sf-related

参考文章 https://segmentfault.com/a/1190000015983518