Redis持久化方式

  1. 1RDB Redis DB
  2. 2AOF AppendOnlyFile 默认关闭

RDB方式

默认情况下,Redis将数据库快照保存在名字为dump.rdb的二进制文件中。
在RDB方式下,有两种保存方式:

(1)、手动执行持久化数据命令来让redis进行一次数据快照。
  • save:在客户端手动执行save命令,它会阻塞Redis服务,无法响应客户端请求,创建新的dump.rdb替代旧文件
  • bgsave:它是一个异步命令,非阻塞,Redis服务正常接收处理客户请求,这种方式,Redis会fork()一个新的子进程来创建RDB文件,子进程处理完后会向父进程发送一个信号,通知它处理完毕,然后父进程会用新的dump.rdb文件来替代旧文件

注意:Fork发生时,父进程内存共享,所以为了不影响子进程做数据快照,在这期间修改数据,将会被复制一份,而不进共享内存,所以说:RDB所持久化的数据,是Fork发生时的数据,在这样的条件下进程持久化数据,如果因为某些情况宕机,则会丢失一部分数据,如果在实际生产中对数据丢失没那么敏感,丢失的也可以从传统数据库中获取或者丢失部分也无所谓,那么就可以选择RDB持久化方式。

save和bgsave的比较:

  • save不用创建新的进程,速度略快,bgsave需要创建子进程,消费额外的内存
  • save适合停机维护,服务低谷时段,bgsave适合线上执行

(2)、另一种则是根据你所配置的配置文件中的策略,达到策略的某些条件时自动持久化数据,和bgsave执行原理相同
  1. save 900 1
  2. save 300 10
  3. save 60 10000

这是配置文件默认的策略,它们之间是或的关系,每个900秒,在这期间变化至少一个键值,做快照。或者每300秒,变化10个键值做快照。或者每60秒,变化10000个键值,做快照。

AOF方式

append only file,采用追加的方式保存,默认文件是:appendonly.aof

它记录所有的写操作命令,在服务启动的时候使用这些命令可以还原数据库,调整AOF持久化策略,可以在服务出现故障时,不丢失任何数据,也能丢失一秒数据,相对于RDB来说损失小的多。

(1)、AOF写入机制

事实上,AOF机制并不会立即将命令写入到硬盘文件中,而是写入到磁盘缓存,在接下来的策略中,配置多长时间来将硬盘缓存写入到硬盘文件,所以在一定条件下,还是会丢失数据,不过丢失很少一部分。所以AOF方式不能保证绝对不能丢失数据。

(2)、写入磁盘策略

Redis默认使用ervrysec,就是说每秒持久化一次,而always则是每次操作都会立即写入aof文件中,而no则是不主动进行同步操作,是默认30s一次。

  • Always:服务器每写入一个命令,就调用一个fdatasync,将缓冲区里面的命令写入到硬盘。这中模式下,服务器出现故障,也不会丢失任何已经成功执行的命令数据。
  • Everysec:服务器每一秒调用一次fdatasync,将缓冲区里面的命令写入到硬盘。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行命令数据。
  • No:服务器不主动调用fdatasync,由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下,服务器遭遇意外故障时,丢失命令的数量是不确定的。

运行速度:always的速度慢,everysec和no都很快。

(3)AOF重写机制:

AOF有序的记录了redis的命令操作,意外情况下丢失数据很少,它不断地对APF文件添加操作日志记录,redis有专门的优化策略来优化日志记录文件过大的问题。

  1. auto-aof-rewrite-percentage 100
  2. auto-aof-rewrite-min-size 64mb

前者是指超过上一次aof重写aof文件大小的百分之多少,会再次优化,如果没有重写,则以启动时为主,后者是限制了允许重写的最小aof文件大小,bgrewritesof命令是手动重写命令,会fock子进程,在临时文件中重写数据库状态对原apf无任何影响,当重建旧的状态后,也会把fock发生后的一段时间内的数据一并追加到临时文件,最后替换原有的aof文件,新的命令继续向新的aof文件中追加。

重写的过程:
(1)fock一个子进程负载重写AOF文件
(2)子进程会创建一个临时文件写入AOF信息
(3)父进程会开辟一个内存缓冲区接收新的写入命令
(4)子进程重写完成后,父进程会获得一个信号,将父进程接收到的新的写入操作由子进程写入到临时文件中
(5)新文件替换旧文件

注:如果写入操作的时候出现故障导致命令写半截,可以使用redis-check-aof工具修复

AOF重写触发:
手动:客户端向服务器发送BGREWRITEAOF命令
自动:配置文件中配置自动执行BGREWRITEAOF命令

auto-aof-rewrite-min-size <size>
触发AOF重写所需的最小体积:只要在AOF文件的体积大于等于size,才会考虑是否需要进行重写AOF,这个选项用于避免对体积过小的AOF文件重写
auto-aof-rewrite-percentage <percent>
指定触发所需的AOF文件体积的百分比:当AOF文件的体积大于指定的体积,并且超过上一次重写之后的AOF文件体积的percent%时,就会触发AOF重写。这个值设置为0表示关闭自动AOF重写。

举例:

  1. auto-aof-rewrite-percentage 100
  2. auto-aof-rewrite-min-size 64mb
  3. appendonly no / yes

当AOF大于64M的时候,可以考虑AOF文件重写
只有当AOF文件的增量大于起始值size的100%时,启动重写, 默认是关闭

RDB和AOF比较:

1、RDB

优点:

  • 完全备份,不同时间的数据集备份可以做到多版本恢复
  • 紧凑的单一文件,方便网络传输,适合容灾恢复
  • 恢复大数据集速度比AOF快

缺点:

  • 会丢失最近写入,修改的未能持久化的数据
  • fock过程非常耗时,会造成毫秒级不能响应客户端请求

    2、AOF

    优点:

  • 写入机制,默认是ervrysec每秒执行,性能好不阻塞服务,最多丢失一秒数据

  • 重写机制,优化AOF文件
  • 如果误操作,比如fulshall等,只要AOF未被重写,停止服务,移除AOF文件尾部FUSHALL命令,重启redis,可以将数据集恢复到flushall执行前的状态

缺点:

  • 相同数据集,AOF文件体积比RDB大很多
  • 恢复数据库速度比RDB慢