Redis 的两种持久化策略
kun 2021-06-16 RedisRDBAOF
redis 有两种持久化策略：RDB和AOF。
# RDB
RDB是一种快照持久化策略，顾名思义，就是通过保存快照来备份redis中的数据。
# RDB 配置
RDB是redis默认的持久化策略，redis.conf 中相关配置如下：
save 900 1 #900秒内至少1个key被修改则保存快照
save 300 10 #300秒内至少10个key被修改则保存快照
save 60 10000 #60秒内至少1000-个key被修改则保存快照
stop-writes-on-bgsave-error yes #快照创建失败后是否继续执行写命令
rdbcompression yes #是否对快照文件进行压缩
dbfilename dump.rdb #生成的快照文件名
dir ./ #生成的快照存放位置
# 关闭RDB
save ""
# save 900 1
# save 300 10
# save 60 10000
# 触发 RDB 备份
- save 命令：暂停用户线程进行备份；
- bgsave命令：fork 子线程进行备份；
- 触发 redis.conf 中配置的快照备份规则时启动的是 bgsave。
- shutdown：当使用 shutdown 命令关闭 redis 时，会自动执行一个 save 命令然后再关闭服务。
- 从机上线：配置主备后，从机上线会给主机发送 sync 命令，此时主机会执行一次 bgsave 命令，然后将快照数据发给从机。
# RDB 工作方式
当触发 RDB 备份时：
- Redis 调用 forks 同时拥有父进程和子进程；
- 子进程将数据写入一个临时的 RDB 文件当中；
- 当子进程完成新 RDB 文件的写入时，Redis 用新文件替换老文件。
# RDB 的优点
- 文件紧凑，适合做历史备份，可以方便的恢复到某一时间点的状态（灾备）；
- 可以通过 fork 子进程来进行备份，对性能影响小；
- 恢复大量数据时比 aof 快；
# RDB的缺点
save 命令会阻塞用户线程； bgsave 命令 fork 子线程会占用资源； 定期持久化会有丢失数据的风险； 如果数据吞吐量过大，RDB 会频繁 fork 子进程进行备份,影响性能。
# AOF
与快照持久化不同的是aof持久化是将新的写命令追加到aof文件的莫问，恢复时从头执行一遍aof文件中的命令就行了。
# AOF 配置
aof默认是不开起的，redis.conf 中增加如下配置开启：
appendonly yes #是否开启aof持久化
appendfilename "appendonly.aof" #aof文件名称
# appendfsync always #备份策略，每次执行写命令都追加到aof文件末尾
appendfsync everysec #每秒追加一次新的写入操作
# appendfsync no #把备份时机交给操作系统
no-appendfsync-on-rewrite no #进行aof文件压缩时是否进行同步
auto-aof-rewrite-percentage 100 #
auto-aof-rewrite-min-size 64mb #
# AOF 工作方式
AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制:
- Redis 执行 fork() ，现在同时拥有父进程和子进程。
- 子进程开始将新 AOF 文件的内容写入到临时文件。
- 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
- 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
- Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
# AOF 的优点
- 默认备份策略是 everysec ，使用默认策略最多丢失 1 秒内的数据；
- aof 文件过大时会自动进行重写，只保存恢复当前数据的最小命令集合；重写是在新的 aof 文件中进行的，重写完成才会替换老的 aof 文件。
- 写命令会有序的追加在 aof 文件的末尾，内容易读，方便分析和恢复数据。
# AOF 的缺点
- 相同大小的数据集，aof 文件体积通常大于 rdb 文件；
- 处理巨大的写入量时，RDB 能提供比 AOF 更好的安全性。
# 总结
RDB 和 AOF 这两种持久化策略各有特点，如果资源允许，最好同时使用两种备份方式。