Redis持久化详解

RDB 快照

将 Redis 内存数据库快照保存到 dump.rdb 二进制文件中。

可以通过 redis.conf 配置文件中 save 参数控制保存频率。

 save 60 1000 # 表示当满足了在 60s 之内执行了 1000 条修改数据的指令就会保存一次

也可以在客户端通过执行 save 或者 bgsave 指令来保存数据。

save 与 bgsave 对比
save 指令是直接使用主进程来进行数据保存的。

bgsave 利用写时复用技术(COW) ，即利用通过 fork 主进程得到的子进程进行数据保存，不影响主进程的读写操作。在子进程保存数据的时候，如果有新的修改数据操作，Redis 会为这些数据生成一个副本，再由子进程把这写数据写入 rdb 文件。

	save	bgsave
IO类型	同步	异步
是否阻塞 redis 其他命令	是	否
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不会阻塞 redis 客户端额外命令
缺点	阻塞客户端命令	需要 fork 子进程，消耗内存

RDB 快照优点与缺点
优点： 因为是二进制方式存储的，所以文件小，恢复数据快。

缺点： 以 save 60 1000 这种设置方式为例，当在 30s 时宕机了，此时还没进行保存操作，这 30s 的数据都会丢失。如果把时间设置的很小，不停的进行整库复制会影响性能。

AOF（append-only file）

AOF 持久化保存数据的方式和 rdb 的不同，它是把每条修改指令保存到 appendonly.aof 磁盘文件中。

通过设置 appendonly 参数开启 AOF 功能

 appendonly yes

通过设置 appendfsync 参数控制将数据 fsync 到磁盘的频率

• appendfsync always ：只要命令追加到 aof 文件中，就 fsync 一次。
• appendfsync everysec(默认)：每隔 1s fsync 一次。
• appendfsync no：不主动 fsync，而是由操作系统决定什么时候 fsync。

AOF 重写
由于 aof 文件中记录的都是指令，其中会存在一些没用的指令，例如对于相同的 key 执行多次 incr 操作，这也会使文件变的很大。

当文件变的很大时，在客户端执行 bgrewriteaof 就会重写这个 aof 文件，重写是以当前内存数据库的内容为基础，重写后 aof 文件中的内容均是 set key value 的形式。执行 bgrewriteaof 开启了子进程，不会影响主进程的读写。

例如：此时 key 为 lisi 的 vlalue 值是 6，是通过 6 条 incr lisi 指令得到的结果。重写前 aof 文件中存放了 6 条 incr 指令，重写后这六条 incr 消失，增加了 set lisi 6 这个指令。

也可以通过配置 auto‐aof‐rewrite‐min‐size 和 auto‐aof‐rewrite‐percentage 这两个参数控制重写频率

auto‐aof‐rewrite‐min‐size 64mb # aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就
很快，重写的意义不大
auto‐aof‐rewrite‐percentage 100 # aof文件自上一次重写后文件大小增长了100%则再次触发重写

AOF 快照优点与缺点
优点： 按照默认的设置，只会丢失 1s 的数据，相比 rdb 数据更安全一点。

缺点： 文件和 rdb 文件相比更大，因此恢复数据的速度也比较慢。

混合持久化

在开启 AOF 基础上，通过配置参数 aof‐use‐rdb‐preamble 即可开启混合持久化

aof‐use‐rdb‐preamble yes

开启了混合持久化后，执行重写这个操作时，会将这一刻之前的内存做 RDB 快照处理，即以二进制方式写入 aof 文件中。之后的新的修改指令，还是以指令的形式追加到 aof 文件中。这样能够以更小的文件体积存储更多的内容。