Redis持久化---RDB&AOF

Redis是一个内存数据库系统,为了保证Redis数据不丢失,Redis有两种方式实现持久化:RDB和AOF

官网截图:
在这里插入图片描述
解释:
RDB:在一个时间点对所有的内存数据做一个快照,然后保存下来,每次只保留最新的一份。
AOF:针对每一次“写操作”,redis服务器都会将该操作以Redis的协议格式追加到日志文件,每次重启Redis都会通过读取日志文件重构原始的数据集

1、RDB(Redis DataBase)

1.1 RDB详述
AOF介绍 Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等) 数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。

rdb 保存的是dump.rdb文件。

1.2 如何触发RDB快照
有三种情况会触发RDB进行备份操作

  1. 配置文件中默认的快照配置
    在这里插入图片描述
    这是redis.conf的默认配置,解释一下配置的意思:
    save 900 1 //900秒之内发生了一次写操作(增删改)就执行快照备份
    save 300 10 //300秒之内发生了10次写操作(增删改)就执行快照备份
    以此类推。。。
    也可以禁用持久化,设置为:save "" 但一般不会这样做

  2. 命令save或者是bgsave
    save命令就是立马执行快照备份,不等到触发默认的快照配置,因为有些比较重要的数据需要立马备份。bgsave也是立马备份,与save不同的是bgsave是后台备份,不会阻塞,redis还是可以响应客户端请求,而save就是其他的不管,全部阻塞。

  3. 执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义

1.3 如何恢复快照
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可,另外,为了保险起见应该将dump.rdb同时备份到多台机器防止机器损坏导致文件丢失无法恢复数据。

1.4 RDB的优势和劣势

官方解释:
在这里插入图片描述

简短翻译一下
优势:

  • 允许我们保存多个版本的数据备份来防止灾难
  • RDB能够最大化Redis的性能,因为父进程唯一要做的就是fork一个子进程,剩下的就交给子进程来完成了,父进程不用执行任何I/O操作
  • 相比AOF,RDB更适合大规模数据的恢复

劣势:

  • 对数据的完整性和一致性保证没那么高,故障发生在最后一次备份操作就会丢失最后一次备份后的一些数据
  • RDB需要fork一个子进程进行持久化操作,子进程要复制一份一模一样的数据这会增加一倍内存的消耗,如果数据量大的话就会影响服务的性能。

总结(图片来自尚学堂–周阳)
在这里插入图片描述

2、AOF(Append Only File)

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

Aof保存的是appendonly.aof文件

2.3 配置位置
在这里插入图片描述

  • appendonly默认是no,改成yes开启aof
  • appendfilename默认是appendonly.aof,建议不要修改
  • 最后三个参数是rewrite相关的参数

2.4 rewrite
rewrite是什么?
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

重写原理是什么?
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似

触发机制?
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

2.5 AOF的优劣势

官方解释:
在这里插入图片描述

尚学堂老师总结为:
优势:

  • 每修改同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
  • 每秒同步:appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
  • 不同步:appendfsync no 从不同步

劣势:

  • 相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
  • aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

2.6 小总结
在这里插入图片描述

本笔记内容摘自尚学堂—周阳老师

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值