Redis 的持久化方案

持久化

Redis 是内存数据库，读写都是在内存中，所以性能很高。但是在内存中的数据会随着服务器的重启而丢失，为了解决数据丢失问题，就需要把内存的数据存储到磁盘，这个过程就叫持久化

Redis 中的持久化有三种方式：

• RDB

• AOF

• 混合持久化

RDB 持久化

RDB 全称是 Redis Database Backup file（Redis 数据备份文件），也被叫做 Redis 数据快照

简单来说就是把内存中的所有数据以二进制的方式记录到磁盘中，当 Redis 实例故障重启后，从磁盘读取快照文件从而恢复数据

快照文件称为 RDB 文件，默认保存在当前运行目录

RDB 的持久化触发有两种：手动触发和自动触发

手动触发

手动触发的命令有两个：save 和 bgsave

 save # 由主进程来执行 RDB，会阻塞所有命令
 bgsave # 开启子进程执行 RDB，避免主进程受到影响

save 命令由主进程完成，在执行 save 命令后，就会触发 Redis 的持久化，但是会使 Redis 处于阻塞状态，直到 RDB 持久化完成，才会进行其他操作

bgsave 命令执行后，主进程会 fork 出来一个子进程来执行持久化，fork 期间会有短暂的阻塞，等到 fork 完成后，主进程就可以进行其他操作，而持久化由子进程在后台完成

在生产环境中启动持久化，bgsave 命令更合适

自动触发

在主动停机 Redis 时（不是宕机），会默认做一次 RDB 操作，保存 Redis 中的数据

Redis 内部有触发 RDB 的机制，可以在 redis.conf 文件中找到，格式为：

 # 900秒内，如果至少有一个 key 被修改，则执行 bgsave 如果是 save "" 则表示禁用 RDB
 save 900 1
 # 如果有多个条件，任意一个条件满足后都会触发
 save 100 2

Redis 会根据配置去判断，满足设定的条件就执行一次 bgsave 命令

执行 flushall 命令后，除了会清空所有键值对，还会自动触发持久化，把 RDB 文件清空

其他配置

RDB 的其他配置也可以在 redis.conf 文件总设置

 # 是否压缩 建议不开启，压缩过程会消耗 cpu，相对来说磁盘不值钱
 rdbcompression yes
 ​
 # 写入和读取文件时是否检查 RDB 文件有无损坏，如果检查发现损坏会停止启动
 rdbchecksum yes
 ​
 # RDB 文件名称
 dbfilename dump.rdb
 ​
 # 文件保存的路径 默认为当前路径
 dir ./

RDB 的缺点有：

• 执行间隔时间长，两次 RDB 之间写入的数据有丢失的风险，假如把执行间隔设置的很短，就可能出现“忙不过来”的情况

• fork 子进程、压缩、写出 RDB 文件都比较耗时，

AOF 持久化

RDB 持久化有一定的时间间隔，间隔小了会造成性能的浪费，间隔大了 Redis 服务意外终止时丢失的数据较多，假如 3 秒持久化一次，在 2.9 秒 Redis 服务异常终止，那这 2.9 秒内的数据就丢失了

为了解决这个问题，可以采用 AOF 持久化

AOF 全称为 Append Only File（追加文件） Redis 处理的每一个写命令都会记录在 AOF 文件，可以看作是命令日志文件

AOF 默认是关闭的，需要修改 redis.conf 配置文件来开启 AOF

 # 是否开启 AOF 功能，默认是 no
 appendonly yes
 # AOF 文件的名称
 appendfilename "appendonly.aof"

AOF 的命令记录的频率也可以通过 redis.conf 文件来配置

 # 表示每执行一次写命令，立即记录到 AOF 文件
 appendfysnc always
 # 写命令执行完先放入 AOF 缓存区，然后每隔 1 秒将缓存区的数据写到 AOF 文件，是默认方案
 appendfysnc everysec
 # 写命令执行完先放入 AOF 缓存区，由操作系统决定何时将缓存区内容写回磁盘
 appendfysnc no

对比一下三种方案，设置为 always 时，安全性最好，但是性能最差；设置为 everysec 时，最坏的情况就是丢失 1 秒内的数据，但是相对来说性能好；设置为 no 时，如果由操作系统决定何时写入磁盘，这个时间往往会很长，虽然性能最高，但是安全性最低

因为 AOF 是记录命令，所以会比 RDB 文件大的多。但对于多次写来说只有最后一次写操作有意义

通过执行 bgrewriteaof 命令，可以让 AOF 文件执行重写功能，用最少的命令达到相同效果

执行这个命令后，会开启一个独立线程在后台异步执行

Redis 也会在触发阈值时自动去重写 AOF 文件。阈值可以在 redis.conf 中配置

 # AOF 文件比上次文件增长超过多少百分比时触发重写
 auto-aof-rewrite-percentage 100
 # AOF 文件体积最小多大以上触发重写
 auto-aof-rewrite-min-size 64mb

如果只开启了 AOF 持久化，Redis 启动时只会加载 AOF 文件进行数据恢复

如果只开启了 RDB 持久化，Redis 启动时只会加载 RDB 文件进行数据恢复

如果同时开启了 RDB 和 AOF 持久化，Redis 启动时只会加载 AOF 文件进行数据恢复，即使 AOF 文件不存在，只有 RDB 文件存在，也不会去加载 RDB 文件

混合持久化

RDB 和 AOF 各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者使用

为了能同时使用 RDB 和 AOF 各种的优点，Redis 4.0 之后新增了混合持久化的方式

开启混合持久化后，AOF 重写时会创建出一个同时包含 RDB 数据和 AOF 数据的 AOF 文件，每次重写会把 Redis 的持久化数据以 RDB 的格式写入到 AOF 文件的开头，之后的数据再以 AOF 的格式追加到文件的末尾

也就是说，开启混合持久化后，AOF 文件中的内容 前半部分是二进制的 RDB 内容，后面跟着 AOF 记录，AOF 夹在两次 RDB 之间

混合持久化有两种方式启用，一种是命令行、一种是配置文件

命令行开启

 config set aof-use-rdb-preamble yes

通过命令可以手动开启混合持久化，缺点是重启服务后配置就会失效

不经常用

修改 redis.conf 文件

 # 开启混合持久化 默认值为 no
 aof-use-rdb-preamble yes

混合持久化缺点：

• AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差

• 兼容性差，只适用于 Redis 4.0 之后版本

总结

Redis 主要的持久化方式有 RDB 和 AOF

两种方式各有其优势和使用场景，RDB通过提供特定时间点的数据快照，对于灾难恢复非常有效

而AOF则通过记录每个写入操作，提供了更好的数据持久性保证

然而它们也有各自的局限性，这就需要根据实际需求来权衡选用哪种持久化方式

在 Redis 4.0 之后的版本，可以适用混合持久化来结合 RDB 和 AOF 的优点，但同时也影响了 AOF 文件的可读性和兼容性