前言

Redis作为内存型数据库,性能好,读写快。但是难免会遇到进程崩溃或者系统重启的时候,如果此时的内存数据没有被及时的保存,无法恢复,就会消失不见。
所以数据的持久化是内存型数据库的重中之重。为此Redis对于数据持久化提供了两种持久化的方案,RDB(Redis DataBase)AOF(Append Only)
下面我们来详细地了解下两者的区别于选择场景。

RDB

RDB是Redis默认的持久化方案。在指定的时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。
即在指定目录下生成一个dump.rdb二进制文件。
Redis重启会通过加载dump.rdb文件恢复数据。

RDB文件的创建的方式

  • 手动触发
    • save : 同步执行,文件策略:如存在老的RBD文件,会替换,会阻塞客户端其他命令。
    • ngsave : 异步执行,redis会重新fork一个进程来执行保存RDB文件的操作,不会阻塞客户端其他命令,但是消耗内存。
  • 自动触发

    打开redis.conf配置文件,找到SNAPSHOTTING的配置,Save Point的设置。

1
2
3
4
# save ""
save 900 1
save 300 10
save 60 10000

当至少有一个key变更时,900秒后会执行一次SAVE。其他配置同理,有10次变更,300秒后保存一次…

若不想用RDB方案,可以把 save “” 的注释打开即可。

RDB恢复

先kill掉Redis进程,再重新启动Redis Server,会发现日志会有这样的一行:DB loaded from disk..
说明Redis在启动的时候,会加载数据初始化。

不过,这里加载的初始化数据不一定是RDB的。如果Redis开启了AOF,会优先从AOF初始化数据,否则才会加载RDB的数据。

RDB方式的优缺点

优点

  • 适合大规模的数据恢复,RDB加载会更快。
  • RDB是某一时间点的快照,是一个紧凑的单文件,更多用于数据备份。如果业务对数据完整性和一致性要求不高,RDB是很好的选择。

缺点

  • 如果Redis不及时保存RDB文件,会造成数据的丢失,所以对数据的完整性和一致性完成不高。
  • RDB经常需要fork子进程去执行,但如果再大量数据的情况下,这个fork操作会非常耗CPU资源的。

AOF

Redis默认不开启。
打开redis.conf配置文件,找到appendonly no改成appendonly yes,即可开启。
它的出现是为了弥补RDB的不足(数据的不一致性),所以它采用日志的形式来记录每个写操作,并追加到文件中。
Redis重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF fsync同步策略

Redis提供了三种同步策略,命令是先写到缓冲区,再根据策略刷到硬盘。

  • appendfsync always:每次操作记录都同步到硬盘上,不丢失数据,但是IO开销大,硬盘压力。
  • appendfsync everysec:每秒执行一次把操作记录同步到硬盘上,是默认的选项,但是可能会丢失某一秒的数据。
  • appendfsync no:不执行fysnc调用,让操作系统自动操作把缓存数据写到硬盘上,不可靠,但最快。

AOF恢复

正常情况下,将appendonly.aof文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。
但在实际开发中,可能因为某些原因导致appendonly.aof 文件格式异常,从而导致数据还原失败,
可以通过命令redis-check-aof --fix appendonly.aof进行修复。

打开AOF文件,可以观察到有对应的操作的记录日志。

AOF的重写机制

AOF虽然比RDB更可靠,但缺点也是比较明显的,AOF的工作原理是将写操作追加到文件中,文件的冗余内容会越来越多。所以Redis新增了重写机制。
AOF重写即是,把重复的,无效的命令,过去数据等进行优化,化简再进行AOF写入,目的是减少磁盘占用,加速恢复的速度。

AOF的重写方式

看回redis.conf配置,有两项控制rewrite的选项。
触发机制:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

  • auto-aof-rewrite-percentage 100,当文件增长100%(一倍)时候,自动重写。
  • auto-aof-rewrite-min-size 64mb,日志重写最小文件大小,如果小于该大小,不会自动重写。

AOF方式的优缺点

优点

  • 更加灵活,可以根据策略来选择恢复方式。
  • 数据的完整性和一致性更高。

缺点

  • 相同数据量下,AOF的文件通常体积会比RDB大。但AOF在日志重写后会压缩一些空间。
  • 在大量写入和载入的时候,AOF的效率会比RDB低。因为大量写入,AOF会执行更多的保存命令,载入的时候也需要大量的重执行命令来得到最后的结果,相对较慢。

总结

以上基本介绍了Redis的两种持久化方式——RDB和AOF的基本原理以及对应的优缺点。
那么在实际开发中,我们到底怎么去选择用哪种持久化方式呢?
其实最安全的做法是RDB与AOF同时使用,这样即使AOF出现意外无法修复,还可以用RDB来恢复数据。