Redis 持久化
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,则可以使用主从复制。代价是如果主从同时挂掉,则会丢失十几分钟的数据。