Redis持久化 rdb aof

本文概述了Redis的两种持久化方法——RDB快照与AOF日志,讨论了它们的优缺点,包括性能、数据完整性和适用场景。RDB适合大规模恢复,但可能存在数据丢失;AOF保证完整,但文件量大,效率较低。

Redis Database(rdb)

Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失,因此Redis提供了持久化功能

在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。Redis会单独创建 ( fork )一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能.

如果需要进行大规模数据的恢

复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB,一般情况下不需要修改这个配置!

rdb保存的文件是dump.rdb 都是在我们的配置文件中快照中进行配置的!

save的规则满足的情况下,会自动触发rdb规则

执行flushall命令,也会触发rdb规则

退出Redis,也会产生rdb文件

恢复rdb文件:

只需要将rdb文件放在Redis启动目录下即可

优点:

1.适合大规模的数据恢复

2.对数据的完整性要求不高(有缺失的数据)

缺点:

1.需要一定的时间间隔进行操作(例如如果意外宕机,最后一次数据将丢失)

2.fork进程会占用内存

===============================================

Append Only File(aof)

将我们的所有命令都记录下来

以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件, redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

Aof保存的是appendonly.aof 文件

在配置文件中默认是未开启状态:

append filename "appendonly.aof"

appendonly no

优点:

1.每次修改都会同步,文件的完整性会更好

缺点:

1.数据量大,修复慢

2.运行效率低

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

莫荒莫慌

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

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

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

打赏作者

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

抵扣说明:

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

余额充值