redis的rdb和aof

由于redis的数据都直接存储在内存里,在服务器发生宕机时内存的数据会瞬间清空,那么必须要有重启时恢复数据的方法。
redis通过持久化机制将数据存储到磁盘中从而在服务器重启时恢复数据,这篇文章主要简介redis的持久化机制。

  • rdb:rdb是通过快照的方式实现持久化,redis定期将数据集快照写入磁盘。

    • 触发RDB持久化过程分为手动触发和自动触发。手动触发的命令为save和bgsave。
      save:会阻塞主进程,一般不使用;bgsave:fork操作创建子进程,子进程执行,完成后自动结束,阻塞只发生在fork阶段,阻塞时间很短。
      自动触发都是通过bgsave的方式执行(save配置、从节点发送同步请求后主节点通过bgsave然后发送给从节点、默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave)
    • save配置:
      save 900 1 #在900秒(15分钟)之后,如果至少有1个key发生变化,则dump内存快照。
      save 300 10 #在300秒(5分钟)之后,如果至少有10个key发生变化,则dump内存快照。
      save 60 10000 #在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照。
    • rdb的优点:
      • RDB是一个紧凑压缩的二进制文件,代表Redis在某一个时间点上的数据快照。非常适合用于备份,全量复制等场景。比如每6小时执行bgsave备份,并把RDB文件拷贝到远程机器或者文件系统中(如hdfs),用于灾难恢复。
      • Redis加载RDB恢复数据远远快于AOF方式。
    • rdb的缺点:
      • RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
      • RDB文件使用特定二进制格式保存,Redis版本演进过程中有多个格式的RDB版本,存在老版本Redis服务无法兼容新版RDB格式的问题。
  • aof:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式。

    • 由于aof文件可能会变得很大,提供了文件重写机制,分为自动重写和手动重写
    • aof配置:
      appendfsync always # 每次有数据修改发生时都会写入AOF文件。
      appendfsync everysec # 每秒钟同步一次,该策略为AOF的缺省策略。
      appendfsync no # 从不同步。高效但是数据不会被持久化。
  • 此外,redis4.0还推出了混合持久化策略,解决了重启时使用aof恢复慢和rdb保存时效不高的问题,有兴趣的读者可以自行了解。

redis的rdb和aof

上一篇:redhat7 安装 mysql5.7


下一篇:Ubuntu 20.04上安装MySQL教程,ubuntu安装mysql