Redis的两种持久化方式AOF和RDB

Redis之所以速度这么快，是因为Redis是基于内存的数据库，进行读写操作时，redis都会先在内存中完成，然后定时的刷新到磁盘中去，RDB和AOF就是两种持久化内存中数据的方式。笼统来讲，RDB可以将某一时刻的所有数据写入硬盘中，相当于复制了一份数据；而AOF会在redis执行写命令时，将被执行的写命令复制到磁盘中，恢复数据的时候，redis会在原有基础上依次执行AOF文件中的写命令，从而恢复数据。

快照RDB

Redis将某一时刻的快照（备份的数据库数据）保存成一种称为RDB格式的文件中，这种格式是经过压缩的二进制文件。redis保存和恢复文件，如图1和图2所示：

保存RDB数据的命令有两种：一个是save，一个是bgsave，一般用的都是bgsave命令。

  • save命令：save命令会阻塞redis服务器的进程，直到RDB文件创建完，在该期间，redis不能处理任何的命令请求，这就是save命令最大的缺陷。
  • bgsave命令：与save命令不同的是，bgsave在生成RDB文件时，会派生出一个子进程，子进程负责创建RDB文件，在此期间，主进程和子进程是同时存在的，因此不会阻塞redis服务器进程。（可用lastsave命令查看生成RDB文件是否成功）。

自动保存RDB文件

除了特殊情况外，我们一般是不会直接使用命令来生成RDB文件的，redis提供了自动生成RDB文件的功能。redis提供了使用配置文件配置的方式每隔一段时间自动执行一次bgsave命令，配置在redis.conf中，例如下面三条命令，只要满足了一个，bgsave就会被执行：

save 900 1
save 300 10
save 60 10000

含义：

Redis 服务器在 900 秒之内，对数据库进行了至少一次修改
Redis 服务器在 300 秒之内，对数据库进行了至少 10 次修改
Redis 服务器在 60 秒之内，对数据库进行了至少 10000 次修改

另外，设计RDB文件的配置选项还有：

dbfilename dump.rdb
dir ./
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

含义：

dbfilename：配置 RDB 文件名称，一般叫dump.rdb
dir：配置 RDB 文件存放的路径
stop-writes-on-bgsave-error：当生成 RDB 文件出错时是否继续处理 Redis 写命令，默认为不处理
rdbcompression：是否对 RDB 文件进行压缩
rdbchecksum：是否对 RDB 文件进行校验和校验

RDB快照持久化数据的优缺点

优点：

  • 采用子线程创建RDB文件，不会对redis服务器性能造成大的影响；
  • 快照生成的RDB文件是一种压缩的二进制文件，可以方便的在网络中传输和保存。通过RDB文件，可以方便的将redis数据恢复到某一历史时刻，可以提高数据安全性，避免宕机等意外对数据的影响。

缺点：

  • 在redis文件在时间点A生成，之后产生了新数据，还未到达另一次生成RDB文件的条件，redis服务器崩溃了，那么在时间点A之后的数据会丢失掉，数据一致性不是完美的好，如果可以接受这部分丢失的数据，可以用生成RDB的方式；
  • 快照持久化方法通过调用fork()方法创建子线程。当redis内存的数据量比较大时，创建子线程和生成RDB文件会占用大量的系统资源和处理时间，对 redis处理正常的客户端请求造成较大影响。

AOF

AOF是redis对将所有的写命令保存到一个aof文件中，根据这些写命令，实现数据的持久化和数据恢复。

AOF配置

配置在redis.conf文件中，通过将appendonly:yes打开创建AOF文件功能。

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

含义：

  • appendonly：是否打开 AOF 持久化功能
  • appendfilename：AOF 文件名称
  • appendfsync：同步频率

对于同步频率有三种方式：

  • always：redis执行每个写命令时，都同步写入硬盘，这样会严重降低redis性能；
  • everysec：每秒执行一次，显示的在这一秒内执行的写命令同步到硬盘；
  • no：不同步到硬盘（让操作系统来决定何时进行同步）。

AOF文件生成机制

生成过程包括三个步骤：命令追加、文件写入、文件同步。

redis打开AOF持久化功能之后，redis在执行完一个写命令后，把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾，此时缓冲区的记录还没有写到appendonly.aof文件中。

然后，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。

对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程，只有经过了文件的同步过程，写命令才真正的被保存到了AOF文件中。appendfsync 就是配置同步的频率的选项。

AOF重写

redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，当AOF文件体积过大时，数据恢复的时间也是非常长的，因此，redis提供了重写或者说压缩AOF文件的功能。

比如对key1初始值是0，调用incr命,100次，key1的值变为100，那么其实直接一句set key1 100 就可以顶之前的100次调用，AOF重写功能就是干这个事情的。

重写时，可以调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。

auto-aof-rewrite-percentage 100 #当前AOF文件大小和上一次重写时AOF文件大小的比值
auto-aof-rewrite-min-size 64mb  #文件的最小体积

重写步骤：

  1. 创建子进程进行AOF重写
  2. 将客户端的写命令追加到AOF重写缓冲区
  3. 子进程完成AOF重写工作后，会向父进程发送一个信号
  4. 父进程接收到信号后，将AOF重写缓冲区的所有内容写入到新AOF文件中
  5. 对新的AOF文件进行改名，原子的覆盖现有的AOF文件

AOF优缺点

优点：
  • 提供了多种同步命令的方式，默认1秒同步一次写命令，最多丢失1秒内的数据；
  • 如果AOF文件有错误，比如在写AOF文件时redis崩溃了，redis提供了多种恢复AOF文件的方式，例如使用redis-check-aof工具修正AOF文件（一般都是最后一条写命令有问题，可以手动取出最后一条写命令）；
  • AOF文件可读性交强，也可手动操作写命令。
缺点：
  • AOF文件比RDB文件较大；
  • redis负载较高时，RDB文件比AOF文件具有更好的性能；
  • RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，因此从理论上来说，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些情况下，AOF的确也存在一些bug，比如使用阻塞命令时，这些bug的场景RDB是不存在的。

 

参考：

 

posted @ 2022-01-14 11:45  残城碎梦  阅读(97)  评论(0)  编辑  收藏  举报