Redis基础篇(5)——持久化RDB和AOF

一、RDB

1.简介

  1. 持久化就是在指定时间间隔内将内存中的数据集快照写入磁盘,恢复时是将快照文件直接读到内存里。
  2. Redis会单独创建(fork)一个子进程来进行持久化,会先将数据先写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。
  3. 整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。如果需要进行大规模数据恢复,且对数据的完整性不是非常敏感,那么RDB方式要比AOF方式更加高效。
  4. 在redis.conf配置文件中,默认持久化文件名为dump.rdb

2.触发方式

持久化触发方式后,分为自动触发和手动触发。

  1. 自动触发可以通到配置文件中的save "来设置触发条件。
  2. 手动触发则是通过命令save和bgsave
  3. 还有一些其他自动触发机制,例如主从复制场景下,如果从节点执行全量复制操作,则主节点会执行bgsave命令,并将rdb文件发送给从节点;执行shutdown命令时,自动执行rdb持久化

3.SAVE和BGSAVE

SAVE和BGSAVE两个命令都会调用rdbSave函数,进行手动持久化操作,但它们调用的方式各有不同:

  1. SAVE直接调用rdbSave,阻塞Redis主进程,直到保存完成为止。在主进程阻塞期间,服务器不能处理客户端的任何请求。
  2. BGSAVE则fork出一个子进程,子进程负责调用rdbSave,并在保存完成之后向主进程发送信号,通知保存已完成。Redis服务器在BGSAVE执行期间仍然可以继续处理客户端的请求。

4.执行流程

请添加图片描述

  1. Redis父进程判断当前是否在执行save/bgsave/bgrewriteaof,如果正在执行则直接返回。
  2. 父进程执行fork操作创建子进程,这个过程中父进程是阻塞的,redis不能执行来自客户端的任何命令。
  3. 父进程fork后,bgsave命令返回Background saving started”信息并不再阻塞父进程,并可以响应其他命令
  4. 子进程创建rdb文件,根据父进程快照生成临时文件,完成后对原有文件进行原子替换。
  5. 子进程发送信号给父进程表示完成,父进程更新统计信息。

5.优缺点

优点

  1. 适合大规模的数据恢复
  2. 对数据完整性和一致性要求不高更适合使用
  3. rdb恢复数据快于aof

缺点

  1. 应为是按周期备份,所以会有数据丢失问题,可能丢失最后一次快照后的数据。
  2. fork时可能需要克隆一份内存数据,导致2倍的内存占用膨胀。但是fork采用了写时拷贝技术。

6.写时拷贝(COW)

在一些早期的unix系统上,系统调用fork确实会对父进程的内存空间进行复制,导致消耗两倍的内存空间。但是大多数情况下,在fork之后都是调用exec去放弃这些内存内容,所以推出了写时拷贝。
写时拷贝就是:

  1. fork函数调用时,父进程和子进程会被Kernel分配到不同的虚拟内存空间中,所以两个进程来看它们访问是不同的内存。
  2. 两个虚拟内存映射到同一个物理内存上,所以父子进程实际上是共享了物理内存。
  3. 当父进程或者子进程对共享的内存进行修改时,共享的内存才会以页(4kb)为单位进行拷贝。子进程会使用拷贝后的新物理内存。

7.为什么不采用多线程的方式

进程级的COW触发时机在父子进程对物理页写入时,由OS控制;线程级的COW触发时机在线程对共享数据写入时,这里需要由开发者来实现。使用线程实现快照加写时复制会更麻烦一点。

二、AOF

1.简介

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

2.开启配置

  1. aof默认是不开启的,到配置文件中找到appendonly no 设置为yes即开启aof。
  2. 默认文件名为appendonly.aof,通过配置文件中的appendfilename ""配置。
  3. AOF和RDB同时开启,系统默认采用AOF的数据。
  4. AOF和RDB的保存路径相同。
  5. appendfysnc always/everysec/no always表示始终同步,每次Redis的写入都立刻记入日志;性能较差但数据完整性比较好;everysec每秒同步,如果宕机,本秒的数据可能丢失。no不主动进行同步,把同步时机交给操作系统。

3.流程

请添加图片描述
命令写入时将命令append到aof_buf缓冲区,等待同步条件到后,将缓冲区数据写入到aof文件中。
随着aof文件越来越大,需要定期对aof文件进行重写,达到压缩的目的。可以通过使用bgrewriteaof主动触发,也可以自动触发:

请添加图片描述

  1. 自动触发时机 = aof_current_size > auto-aof-rewrite-min-size(表示重写时文件必须大于这个值,默认值为64mb) && (aof_current_size/aof_base_size) > auto-aof-rewrite-percentage (表示当前文件大小比上次重写后的文件大这么多才行)
  2. 如果当前进程正在执行aof重写,就不执行直接返回。如果当前进程执行的是bgsave操作,则重写命令延迟到bgsave之后再执行。
  3. 主进程fork出子进程
  4. 原有的aof机制继续运行,同时也将新的命令写入到aof_rewrite_buf中
  5. 子进程生成新的aof文件
  6. 通知父进程,新的aof文件已经生成成功;将aof_rewrite_buf中的命令追加到新的aof文件中,用新的aof文件替换旧的aof文件。
  7. 结束

4.优缺点

优点

  1. 备份机制更稳健,丢失数据概率更低
  2. 可读的日志文本,通过操作AOF稳健,可以处理误操作

缺点

  1. 比起RDB占用更多的磁盘空间
  2. 恢复备份速度慢
  3. 每次读写都同步的话,有一定的性能压力
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值