Redis的持久化策略-AOF和RDB(详细图解)

发布于:2025-07-30 ⋅ 阅读:(21) ⋅ 点赞:(0)

各位看官,大家早安午安晚安呀~~~

如果您觉得这篇文章对您有帮助的话

欢迎您一键三连,小编尽全力做到更好
欢迎您分享给更多人哦

今天我们来学习:Redis的持久化策略-AOF和RDB(详细图解)

灵魂三连问

1. Redis的持久化是什么?

2. 包括哪几种?

3. 如何选择?

解决的问题:redis在运行时,服务器宕机了,运行内存和里面的数据就没了,这就是持久化的意义所在。

Redis的持久化策略分为哪几种:

RDB和AOF两种

1.RDB( 写时复制的方法(COW)

  • RDB 文件是磁盘快照

  • 当 Redis 重启时 才会加载 RDB 文件到内存,恢复数据。

优点:快速恢复

缺点:RDB 是某一时间点的快照,两次快照之间的数据可能丢失,而且是RDB文件是二进制文件,可能完全不可用

分为主动执行和被动触发(配置文件)

先说一下RDB结构:RDB文件是经过压缩的二进制文件,默认采用LZF算法对文件做压缩处理。

新的 RDB 文件生成后不会直接“保存到数据库”,而是作为一个独立的持久化文件存储在磁盘上

  • REDIS:是否是RDB文件???
  • db_version: RDB文件的哪一个版本???
  • databases:包括了0个或者多个数据库   和   库中的 键值对数据(数据)
  • EOF:常量,文件正文内容的结束
  • check_sum:刚才的四个部分的内容计算得出的

在载入RDB文件时会将载入的数据计算得出的校验和 与 check_sum进行比较判断是否异常

1.1.1RDB持久化主动触发:save和bgsave两种方式

save方法执行时,会阻塞redis一直到持久化完成才不会继续阻塞,一般不会用。

1.1.2RDB持久化主动触发:bgsave

图解:

=》

第二种bgsave在主进程中会fork个子进程,fork过程中,redis是阻塞的

=》

接着子进程来进行持久化,此时就不再阻塞了。持久化时子进程会去遍历所有的KV,然后调用rdbsaveobject函数将数据进行二进制序列化写入到RDB文件中。

=》这个过程中主进程仍然可以修改原来的数据。

而主进程在执行修改操作时,对应的数据就会被复制一份生成副本,然后子进程会把这个副本写入RDB中。

1.2RDB持久化被动触发(配置的方式)

通过配置的策略,以下是三个默认的策略

  • 900s内有一个key发生变化,
  • 300s内有10个key发生变化,
  • 60s内有10000个Key发生变化会备份

用的是bgsave方式

1.3总结:

如果对数据保存要求比较高,那么rdb不是一个好选择,如果所在机器宕机了,还没有持久化的数据就会丢了

聪明的你肯定会想反正子进程持久化也不阻塞,那每秒做一次快照不就最大程度避免丢失了吗?

其实不行

1.一方面很频繁的将全量数据写入磁盘,磁盘会有很大的压力。

2.另一方面bgsave,fork子进程会包括子进程出来,fork这个过程还是会阻塞的,而且使用的内存越大,阻塞时间越长。

2.AOF:默认关闭,需要开启

Aof:(33策略:)

aof它是以日志的方式来记录每一个写命令的操作。执行时,不像rdb每次都弄一个完整的文件出来,而是采用在文件中追加的形式,

当redis启动后读取文件来恢复数据时,其实是按照内容将命令从头到尾执行一遍。aof默认是关闭的,需要在配置中开启,再向日志文件中写入时,并不是直接写到磁盘里。

2.1AOF的持久化策略:

首先客户端的写命令会采用追加的形式放到aof缓冲区中接着会根据配置中的持久策略来缓冲区的数据同步到磁盘里,持久化策略也是在配置中设置的。

  • 第一种:是每次有数据修改时都会写入aof文件,这种每个命令都同步到磁盘的操作,对磁盘压力是很大的。
  • 第二种:appendsync everysec它是每秒同步一次,该策略是默认的,这种每秒同步一次的频率推荐使用。在性能和数据安全上平衡性做的不错。
  • 第三种是根本就不做持久化数据,不建议使用aof。

2.2.AOF重写:重写触发可以分为主动触发和被动触发,(都是分为主动和被动)

解决的问题:随着执行命令越来越多,aof文件也会越来越大,这就需要对aof文件进行重写来缩小体积。如何重写(如何缩小文件???)

  1. 过期的数据不再写入文件
  2. 无效的命令不再写入文件,比如重复设置set name小红,set name小明就可以只保留第二个,
  3. 而删除命令就可以直接丢弃掉,还可以合并命令,将两个set可以合并成一个M site,这样执行的命令少了,aof体积自然就小了

2.2.1.主动触发:

直接调用这个命令bgrewriteof,该命令的执行与bgsave有些类似,也是主进程fox子进程后再执行重写。

2.2.2被动触发:
通过配置来实现。

第一个参数表示aof文件大小超过指定值时,满足触发条件默认为64MB。

第二个参数表示,当aof文件大小超过上次重写后文件大小的百分比是满足触发条件,默认值为100只有当这两个条件同时满足了,才会自动触发aof重写

2.2.3.重写步骤:

图解:

首先主进程fork子进程。结构中有aof缓冲区,还有个aof重写缓冲区,执行命令会同时写到这两个缓冲区中。aof缓冲区会根据持久化的策略,将命令同步到磁盘里,从而生成aof文件。

=》

当满足重写aof条件时,子进程会执行重写机制,生成新的文件完成后会给主进程一个信号。主进程接收后,会将aof重新缓冲区中的所有数据再追加到新aof文件的末尾,接着将新文件来替换旧文件,之后所有命令都会追加到新aof的文件中。

3.同时开启

如果同时开启了RDB和AOF持久化会优先使用Aof文件来还原数据

4.混合持久化

而RDB和AOF还可以混合持久化,结合了RDB的快速恢复和的数据完整优点。首先当前数据是以RDB的格式保存,而新的命令是以aof的格式保存。

混合持久化,在AOF重写时,首先将当前数据以rdb的格式写入到新aof文件的开始位置,如果有新的命令会追加到文件末尾

上述就是Redis的持久化策略-AOF和RDB(详细图解)的全部内容啦,不知道您对文章中的问题和思想是否都学会理解了呢?

能看到这里相信您一定对小编的文章有了一定的认可。

有什么问题欢迎各位大佬指出
欢迎各位大佬评论区留言修正~~

您的支持就是我最大的动力​​​!!!


网站公告

今日签到

点亮在社区的每一天
去签到