Redis的持久化RDB与AOF

Redis的持久化RDB与AOF

Redis是一个内存数据库，数据保存在内存中，但是内存中的数据在服务器发生故障的时候易丢失，持久化是将内存中数据保存到硬盘中。在Redis中，持久化方式有两种，即快照(RDB)与日志(AOF)。

RDB方式

RDB其实就是把数据以快照的形式保存到磁盘中，在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式就是将内存中的数据以快照的方式写入到二进制文件中，默认的文件名dump.rdb。

触发方式

对于RDB方式持久化，提供了三种触发机制：save、bgsave、自动触发。

• save触发

  该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。执行完成后如果存在老的RDB文件，就把新的替代旧的。

• bgsave触发

  执行该命令时，Redis会在后台通过fork创建子进程，有子进程异步进行快照操作，阻塞只发生在fork阶段，时间很短，很快就可以响应客户端请求。

• 自动触发

  自动触发是由我们的配置文件来完成的，在redis.conf配置文件中，里面有下面配置：

  • save seconds count：这里配置redis的RDB方式持久化条件，也就是什么时候将内存中的数据保存到硬盘中，例：save 10 5：表示10秒内有5次修改了数据，自动触发bgsave。若不需要持久化，注释掉save停用功能。
  • stop-writes-on-bgsave-error：默认值为yes，当启用RDB且最后一次后台保存数据失败，redis是否停止接受数据，这会让用户发现数据没有正确持久化到磁盘上，否则没有人会注意到灾难的发生。若Redis重启，又可以重新开始接受数据。
  • rdbcompression ：默认值是yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。
  • rdbchecksum ：默认值是yes，在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加约10%的性能消耗，如果希望获取到最大的性能提升，需要关闭次功能。
  • dbfilename：置快照的文件名，默认时dump.rdb。
  • dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。

RDB的优劣势

• 优势
  • RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
  • 生成RDB文件的时间，redis主进程会fork一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
  • RDB在恢复大量数据集时速度比AOF的速度快。
• 劣势
  • RDB快照是一次全量备份，存储的时内存数据的二进制序列化形式，存储上非常紧凑，当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程在修改内存子进程不会知道，所以在快照持久化期间修改的数据不会被保存，可能导致数据丢失。

AOF方式

AOF原理

RDB全量备份比较耗时，AOF是一种更高效的方式，工作机制简单，Redis服务会将收到的每一个写命令都通过write函数追加到指定的文件中。通俗理解就是日志记录。

文件重写

AOF的方式也有另一个问题，持久化文件将会随着时间流逝越来越大，为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令，将内存中的数据以命令的方式保存到临时文件中，同时会fork一条新进程来将文件重写。

• 重写的触发
  • 手动触发：直接调用bgrewrite命令。
  • 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
    • auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认 为64MB。
    • auto-aof-rewrite-percentage：代表当前AOF文件空间 （aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。

AOF的触发方式

AOF的触发需要在redis.conf中添加配置:

• appendonly：yes/no，是否开启AOF持久化功能，默认为no，不开启。
• appendfsync：AOF写数据策略。有下列选项：
  • always：每次修改同步，同步持久化每次发生数据变更会被立即记录到磁盘，性能较差，但是数据完整性比较好。
  • everysec：每秒同步，如果一秒内宕机，会有数据丢失的情况。
  • no：由系统控制。

AOF的优劣势

• 优势
  • AOF可以更加完整的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次写入操作，最多丢失1秒中的数据。
  • AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不用一损坏。
  • AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
  • AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性误删除的数据恢复。比如不小心用flushall命令清空所有的数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令删除，然后在将该AOF文件放回去，就可以通过恢复机制，自动恢复所有的数据。
• 缺点
  • 对于同一份数据来说，AOF日志文件通常比RDB快照文件更大。
  • AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒写入日志，当然写的性能也是很高的。
  • 以前AOF发生过BUG，通过AOF记录的日志进行数据恢复的时候，没有恢复一模一样的数据。

RDB和AOF如何选择

一般来说，两者加一起更好，因为两个持久化机制不同，看各自的需求，但通常都是结合使用。

项目	RDB	AOF
启动优先级	低	高
文件体积	小	大
恢复速度	快	慢
数据安全性	丢数据	根据策略决定
持久化的轻重	重	轻

注意

• 1、AOF持久化开启且存在AOF文件时，优先加载AOF文件，打印如下日志：

  DB loaded from append only file: xxx seconds

• 2、AOF关闭或者AOF文件不存在时，加载RDB文件，打印如下日志：

  DB loaded from disk: xxx seconds

• 3、加载AOF/RDB文件成功后，Redis启动成功。

• 4、AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。