Redis持久化方式:RDB和AOF

文章目录

    • RDB(Redis Database)
      • 原理
      • 触发条件
      • 优缺点
    • AOF(Append-only File)
      • 原理
      • 工作流程
      • 刷盘策略
      • 命令重写机制
      • 触发命令重写
      • 优缺点

RocketMQ思维导图,不看会后悔哟
Mysql思维导图分享

上面思维导图可去gongzhonghao回复:扣扣号,获取联系方式后找我免费获得可编辑版本。 后面会继续分享其他思维导图,包括Redis、JVM、并发编程、RocketMQ、RabbtiMQ、Kafka、spring、Zookeeper、Dubbo等等

原文链接戳这里

RDB(Redis Database)

原理

  RDB就是将某一时刻的内存数据快照 以二进制形式写到磁盘里。

  由于RDB⽂件是保存在硬盘上的,所以即使Redis崩溃或者退出,只要RDB⽂件存在,就可以⽤它来恢复还原数据库的状态。它利用了系统的COW(copy on write)机制。

触发条件

  触发RDB的持久化有两种方式:手动触发和自动触发

  1. 手动触发

  • 调用save命令:会阻塞当前Redis服务器直到RDB文件创建完成为止,对于内存比较大的实例会造成长时间阻塞,线上环境非必要不要使用。

  • 调用bgsave命令:通过执行fork操作创建一个子进程来进行持久化 ,减少了父进程的阻塞。但是在fork阶段也会阻塞父进程(时间很短)。

  2. 自动触发

  • 在redis.conf中配置“save m n”。表示当m秒内数据有n次变化时就会自动触发bgsave

  • 从节点执行全量复制操作时,主节点自动执行bgsave生成RDB文件并发送给从节点

  • 执行debug reload命令重新加载Redis时,也会自动触发save操作

  • 执行shutdown命令时,如果没有开启AOF则自动执行bgsave

优缺点

 RDB的优点是体积小,恢复数据快。缺点是生成二进文件更耗性能,且是间隔保存,丢失数据风险更大

Redis持久化方式:RDB和AOF_第1张图片

AOF(Append-only File)

原理

 AOF以独立日志的方式记录每条写和修改命令, 重启时再重新执行AOF文件中的命令达到恢复数据的目的。

 AOF可设置为总是保存,但是一般都是设置1秒保存一次。我们生产时就是这样设置的,运维给出的建议是,不要希望redis作数据的一致性保证,它只为了解决高并发的问题的,一致性通过好的架构设计去保证。

工作流程

  • 命令追加到aof_buf(缓冲区)中。

  • aof_buf(缓冲区)根据设置的刷盘策略向磁盘同步。

  • 文件变大后对AOF文件进行重写,以减少文件体积。

  • redis服务器重启时,加载AOF文件进行数据恢复。

刷盘策略

  • appendfsync always:每次写入都进行刷盘操作,对性能影响最大,占用磁盘 IO 较高,数据安全性最高

  • appendfsync everysec:1秒刷一次盘,对性能影响相对较小

  • appendfsync no:写入aof_buf后不刷盘,由操作系统的定时机制进行刷盘。对性能影响最小,数据安全性低

命令重写机制

  • 过期的数据不再写入文件
  • 无效的命令不再写入文件。如重复设置某个值,或数据已经被删除
  • 多条命令合并为一条命令。比如push list a; push list b 两条命令,就可以合并为push list a b 这一条命令;

触发命令重写

1. 手动触发

  直接调用 bgrewriteaof命令

2. 自动触发,满足以下两个条件

  auto-aof-rewrite-min-size:AOF 文件体积最小多大以上触发

  auto-aof-rewrite-percentage:AOF 文件距离上次文件增长超过多少百分比 = 当前AOF大小 / 上次重写时AOF的大小

优缺点

  优点 是数据更完整。缺点 文件体积大,加载慢,磁盘IO高。

Redis持久化方式:RDB和AOF_第2张图片

你可能感兴趣的:(Redis,redis,AOF,RDB,持久化策略)