Redis -持久化方式对比

redis 提供两种持久化方式，一种是RDB持久化（定时将数据被分到磁盘上），另一种是AOF（append only file）持久化（将对 redis 的操作日志以追加形式写入文件）

---

RDB持久化

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

配置方式

在redis.conf中默认配置

#   save <seconds> <changes>

# 时间策略
# 900s (15min)内超过 1 个key被修改，则进行持久化
save 900 1
# 300s (5min)内超过 10 个key被修改，则进行持久化
save 300 10
# 60s 内超过 10000 个key被修改，则进行持久化
save 60 10000

# 文件名称
dbfilename dump.rdb

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

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

使用

手动触发

在 redis 中手动触发持久化可使用以下命令（一般只适用bgsave）

• save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。
• bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。

自动触发

• 根据 save m n 配置自动触发
• 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发bgsave
• 执行debug reload时
• 执行shutdown时，若没有开启aof，也会触发

执行流程

优势

1. 备份出的数据只包含一个文件，当系统出现灾难性故障时，恢复十分容易
2. 性能最大化，对于redis的服务进程来说，在开始持久化时，唯一需要做的就是fork出子进程，之后再由子进程完成持久化的工作，从而避免服务进程执行IO操作
3. 相比于AOF，如果数据量很大，RDB的启动效率会很高

劣势

1. 在两次持久化之间若服务宕机，数据就会因为还未保存而丢失
2. 通过fork子进程完成持久化工作，若数据量较大时，可能会导致服务器暂时停止服务几百ms，或1s

---

AOF持久化

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

配置方式

同样在redis.conf中默认配置文件672行

############################## APPEND ONLY MODE ###############################
# 是否开启AOF，默认关闭（no）
appendonly yes

# 指定 AOF 文件名
appendfilename appendonly.aof

# Redis支持三种不同的刷写模式：
# appendfsync always #每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
# appendfsync no     #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。

#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no
no-appendfsync-on-rewrite no 

#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100

#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

使用

手动触发

通过bgrewriteaof命令手动触发AOF持久化

自动触发

根据redis.conf中的配置规则来触发

执行流程

优势

1. 对比RDB持久化，具有更高的数据安全性。redis 中提供了三种同步策略：每秒同步，每修改同步和不同步。
   1. 每秒同步也是异步完成的，但是若系统突然宕机，可能一秒中之内的数据将会丢失
   2. 每修改同步是效率最低的，每次发生数据的变化都会被立刻记录到磁盘中
2. AOF对于日志文件采用的是追加模式，因此在写入过程中即使出现宕机，也不会破坏日志文件中已经存在的内容；若只写入一半数据就宕机，在redis下次启动时，可通过redis-check-aod工具来解决数据一致性的问题
3. 若日志文件过大，redis可自动启用rewrite机制。
4. AOF包含一个格式清晰，易于理解的日志文件用于记录所有的数据修改操作。

劣势

1. 对于相同数据量时，AOF文件通常大于RDB文件，并且RDB在恢复大数据量时速度要比AOF快
2. 根据同步策略的不同，AOF在运行效率上往往会慢于RDB

注

不论是RDB还是AOF都是先写入一个临时文件，然后通过 rename 完成文件的替换工作。

参考

• https://www.php.cn/redis/421586.html
• https://blog.csdn.net/aitangyong/article/details/52072708