Redis 持久化

最新推荐文章于 2023-12-10 23:03:18 发布

张伟杰-Vijay

最新推荐文章于 2023-12-10 23:03:18 发布

阅读量365

点赞数 2

分类专栏： Redis 文章标签： redis aof rdb

本文链接：https://blog.csdn.net/zwj_jyzl/article/details/107874511

版权

Redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

RDB

what

快照保存方式，根据配置文件中的配置，当满足一定条件时，比如默认的：15分钟内修改了 1 次、5 分钟内修改了 10 次、1 分钟内修改了 10000 次，则自动将 Redis 中的数据进行一次备份，并生成一个 dump.rdb 文件。

how(如何工作)

父进程首先 fork 一个子进程，然后由子进程进行备份工作，父进程仍然响应客户端，这样 Redis 在备份的时候也不会影响 Redis 的性能。
子进程先将所有的数据备份到一个临时文件，当备份完成的时候，用新的 rdb 文件替换原来的旧 rdb 文件。

when(何时触发)

配置文件配置：save seconds changes（例如：save 900 1）。
手动执行 save、bgsave 命令：手动执行这两个命令会立即备份，生成一个新的 rdb 文件，不同的是：save 会阻塞，bgsave 会在后台进行异步快照，Redis 仍然可以响应客户端。
执行 flushall、shutdown 命令：当执行此操作时也会生成 rdb 文件，不过 flushall 将所有的数据清空，生成的 rdb 文件毫无意义。

优缺点

优点

生成一个单一的文件，便于容灾备份
当恢复大量数据时，速度要比 AOF 快

缺点

当 Redis 发生意外宕机时，可能会丢失几分钟的数据（因为 RDB 方式是每隔几分钟才备份一次，所以还没到备份时间点时发生宕机，则从上一次备份到宕机时刻，所有的数据都会丢失）
在备份的时候，由于会 fork 一个子进程，当数据量比较大时，fork 过程比较耗费性能，可能会造成毫秒级的无法响应
fork 会产生一个和原进程一样的子进程，数据被克隆了一份，所以还要考虑 2 倍的膨胀性

AOF

what

将所有的修改命令都追加到一个 apendonly.aof 文件中，Redis 在启动的时候，再逐步读取每一条指令并执行。

how(如何工作)

AOF 模式可以在配置文件中配置 3 种同步策略，分别是：

Always：每执行一次修改，就会向 AOF 文件中同步追加一条命令，速度最慢，但数据完整性最好
Everysec：每秒保存一次，速度很快，和 RDB 差不多，即使发生故障，也只会丢失 1 秒内的数据
No：交给操作系统处理，速度最快，安全性不如前两种方式

优缺点

优点

可以选用不同的 fsync 策略，数据完整性比较好

缺点

同等数量的数据，比 RDB 文件要大，且恢复的时候也比 RDB 要慢
根据使用的 fynsc 策略，AOF 的速度可能要慢于 RDB
因为命令会不断追加，所以就会导致 AOF 文件越来越大

AOF 文件重写

what

我们知道 AOF 模式，会将写命令不断的追加到 aof 文件的末尾，这样就会造成 aof 文件越来越大的问题，文件重写就是来帮助我们减少 aof 文件大小的。

文件重写就是将 AOF 文件中的命令精简，精简成可以恢复当前数据所需的最少命令。比如：set k1 1，然后执行累加操作，最后 k1 的值是 100，那么这些累加的命令就是多余的，可以直接精简成 set k1 100。

how(原理)

父进程先 fork 一个子进程，由子进程进行重写
子进程也是先将所有的命令先写到一个临时文件，同时父进程仍然将客户端发来的命令放到缓存中，并追加到原来的 AOF 文件（即使在重写的过程中发生宕机，也不会造成任何影响）
当子进程重写完成时通知父进程，父进程将缓存中的命令追加到新的临时文件中，并用新的 aof 文件替换原来的 aof 文件
此后所有新命令都会追加到新的 aof 文件中

when(何时触发)

通过配置文件中的两个配置
① Auto-aof-rewrite-min-size：重写触发时文件大小的最小值，默认 64 M。
② Auto-aof-rewrite-percentage：达到上一次重写后文件大小的百分比，默认 100。

当上述 2 个条件都满足时，就会触发重写。

Redis 在追加命令时，意外宕机，AOF 文件如何修复？

可以使用 Redis 自带的 redis-check-aof 进行修复，执行命令：redis-check-aof --fix appendonly.aof。

如何选择

能否共存

可以共存，当共存时，Redis 在启动的时候会先加载 aof 文件，因为 aof 文件记录的数据完整性要比 rdb 文件要好，如果 aof 文件有错误，则无法启动 redis，需要先修复 aof 文件。

选择

官方推荐：AOF 和 RDB 方式共用，因为 AOF 方式虽然已经将数据非常完整的保存了，但是 RDB 方式非常适合备份，而且 RDB 恢复的速度也要比 AOF 方式要快。
个人建议：在 slave 机器上使用 RDB 方式定时备份。
至于 AOF 方式，可以选择启用也可以选择不启用。

① 如果启用 AOF 方式，则最坏的情况也只是丢失 1 秒的数据。但是 AOF 方式的缺点就是一是持续的 IO；二是 rewrite 过程中，最后将新产生的命令写到新的 aof 文件中造成的阻塞是不可避免的，如果启用 AOF 则应该尽量减少 rewrite 的频率。

② 如果不启用 AOF，则可以使用主从复制。代价是如果主从同时挂掉，则会丢失十几分钟的数据。