【Redis的持久化方式RDB和AOF的区别以及优缺点】

文章探讨了Redis的两种持久化方式——RDB和AOF。RDB通过定期快照保存数据,适合大数据集的快速恢复,但可能丢失最近未持久化的数据。AOF记录所有写操作日志,提供更好的数据安全,支持同步策略调整,但在性能和文件大小上可能不如RDB。选择哪种方式取决于对一致性和性能的需求。生产环境中常结合两者使用。
摘要由CSDN通过智能技术生成

一.Redis的持久化方式RDB和AOF的区别以及优缺点

下面我们一起学习关于Redis的持久化方式RDB和AOF的区别以及优缺点的相关内容,也就是学习Redis、面试过程中遇到的问题,你看看掌握的怎么样?顺便把我之前俩篇实战的文章贴出来,放到下面了,感兴趣的同学可以自行学习。
【Redis持久化原理之快照版本RDB】
【Redis持久化原理之AOF(Append Only File)】

在这里插入图片描述

二.Redis持久化核心概念

2.1 为什么需要Redis持久化这种操作呢?

由于Redis的数据都存放在内存中,如果没有配置持久化,redis重启后数据就全丢失了,于是需要开启redis的持久化功能,将数据保存到磁盘上,当redis重启后,可以从磁盘中恢复数据。

2.2 Redis提供了那俩种持久化方式呢?

Redis提供两种方式进行持久化:

  1. RDB持久化:原理是将Reids在内存中的数据库记录定时dump到磁盘上,说的更详细一些就是在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。
    在这里插入图片描述
    具体过程如下
    在这里插入图片描述

  2. AOF持久化:原理是将Reids的操作日志以追加的方式写入文件。AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。
    在这里插入图片描述

三.Redis持久化中RDB方式的优缺点

3.1 Redis持久化中RDB的优点

  1. 整个Redis数据库将只包含一个文件,这对于文件备份而言是完美的。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。

  2. 对于灾难恢复而言,RDB是非常不错的选择。因为我们可以轻松的将一个文件压缩后再转移到其它存储介质上。

  3. 性能最大化。对于Redis的服务进程而言,在开始持久化时,它首先需要做的就是fork子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。

  4. 如果数据集很大,RDB的启动效率会更高。

3.2 Redis持久化中RDB的缺点?

  1. RDB是每隔一段时间触发持久化,因此数据安全性低。如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。

  2. 由于RDB是通过fork子进程来协助完成数据持久化工作的,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。

四.Redis持久化中AOF方式的优缺点

4.1 Redis持久化中AOF的优点

  1. AOF机制更高的数据安全性,即数据持久性。Redis中提供了3种同步策略每秒同步修改同步不同步

1.每秒同步是异步完成的,效率高,但是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失;
2.每修改同步是同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。这种方式在效率上是最低的。
3.无同步,顾名思义,就是不同步呗,无需多讲。
但是这里的不同步需要画上引号,不是说真的就不同步了,千万不要被表面意思所迷惑,我再来详细的解释一下:
当appendfsync设置为no时,表示Redis在执行数据写入操作时,不进行磁盘同步。换句话说,Redis将数据写入到操作系统的页缓存中,然后由操作系统来决定何时将数据同步到磁盘。
注意1:这个设置可以提高Redis的写入性能。因为操作系统的页缓存是放在内存中的,所以在写入过程中不需要频繁地进行磁盘IO操作,而是把数据先存放在内存中,稍后再由操作系统来控制数据的最终写入。这样可以避免频繁地进行磁盘IO操作对性能造成的影响。
注意2:当appendfsync设置为no时,数据可能会存在丢失的风险。这是因为如果Redis在写入数据后发生宕机或断电等情况,未同步到磁盘的数据就会丢失。因此,选择适当的持久化策略对于确保数据的安全性非常重要。

  1. 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

  2. 日志过大,Redis可以自动启用rewrite重写机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite重写切换时可以更好的保证数据安全性。
    在这里插入图片描述

  3. AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。

4.2 Redis持久化中AOF的缺点

  1. 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

  2. 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。

五.选择AOF or RDB呢?

  1. 并没有标准,看具体想要一致性还是高性能呢?
  2. 如果系统愿意牺牲一些性能,想要更高的缓存一致性,我们选择AOF机制;
  3. 但是系统写操作频繁的时候,想要更高的性能,此时我们选择RDB机制。(RDB有最终一致性的感觉了)。
  4. 生产环境其实更多都是二者结合使用的。

六.勉励

这么晚了,还勉励啥呀,不给你们和心灵鸡汤了,快睡吧,身体和工作同样重要哦,对了,还有父母!
我是硕风和炜,我们下篇文章见!
在这里插入图片描述

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

硕风和炜

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值