Redis连载系列(三) redis的两种持久化方式RDB和AOF

本文是Redis系列的第三篇章,详细介绍了Redis的两种持久化方式:RDB(Redis Database)和AOF(APPEND ONLY FILE)。RDB通过快照实现,适合定时备份,但在数据实时性上有损失;AOF记录每次操作日志,提供更好的数据完整性,但文件体积较大,恢复速度较慢。文章对比了两者优缺点,并讨论了AOF的重写策略,以保持文件大小的合理性。
摘要由CSDN通过智能技术生成

redis的两种持久化方式RDB和AOF

大家好,本篇文章是redis系列第三篇章节,主要是介绍redis的两种持久化方式RDB和AOF。

1. RDB(Redis Database)

RDB主要就是定时将内存里面的数据以二进制的方式写入到dump.rdb里面去。RDB主要是通过快照方式实现的,我们可以在redis配置文件里面配置快照生效规则。RDB持久化方式默认是开启的。

save 900 1  #900秒内如果超过1个key被修改,则发起快照保存
save 300 10 #300秒内容如超过10个key被修改,则发起快照保存
save 60 10000

redis的父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程,然后这个子进程就会处理接下来的所有保存工作,子进程需要将快照文件写入临时文件,用临时文件替换原来生成的快照文件,替换完成以后子进程退出。

优点:

  1. 定时备份适用于每天一备份数据的需求。
  2. 方便恢复,只需要将RDB文件移到指定目录下,redis启动的时候就会读取RDB文件里面的信息。
  3. 因为是每次进行备份的时候,都要新启一个子进程。所以,完全不会影响到父进程的工作。
    每次快照持久化都是将内存数据完整写入到磁盘一次,并不 是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。

缺点:

  1. 虽然可以控制频率持久化数据,但是,做不了实时备份,因为每次备份都是需要耗时的。
  2. 每次fork()创建子进程的时候,由于数据量特别大,会引起服务器资源紧张,尤其是备份频率比较快的时候。
  3. 由于是替换上一次的RDB文件。所以,上一次持久化的数据会丢失。

2. AOF(APPEND ONLY MODE)

以日志的方式每次记录对redis的操作(读不记录),并且追加到文件中。这样,redis在重启的时候会根据文件中的每一条指令从前到后执行每一条指令,这样以达到恢复数据的效果。

AOF有三种方式,redis的AOF默认是关闭的,如果要开启的话,修改配置文件redis.windows.conf:appendonly yes

AOF是文件操作,对于变更操作比较密集的server,那么必将造成磁盘IO的负荷加重;此外linux对文件操作采取了“延迟写入”手段,即并非每次write操作都会触发实际磁盘操作,而是进入了buffer中,当buffer数据达到阀值时触发实际写入(也有其他时机),这是linux对文件系统的优化,但是这却有可能带来隐患,如果buffer没有刷新到磁盘,此时物理机器失效(比如断电),那么有可能导致最后一条或者多条aof记录的丢失。通过上述配置文件,可以得知redis提供了3种aof记录同步选项

 no:redis并不直接调用文件同步,而是交给操作系统来处理,操作系统可以根据buffer填充情况/通道空闲时间等择机触发同步;这是一种普通的文件操作方式。性能较好,在物理服务器故障时,数据丢失量会因OS配置有关。
 always:同步持久化,每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好(慢,安全)
 everysec:出厂默认推荐,每秒异步记录一次(默认值)。
 auto-aof-rewrite-min-size 64mb   只有大于此aof文件大于此尺寸是才会触发重写。

配置为always时,每次写入都要同步AOF文件,在一般的STAT硬盘上,Redis只能支持大约几百TPS写入,显然跟Redis高性能特性背道而驰,不建议配置。

配置为everysec,是建议的同步策略,也是默认配置,做到兼顾性能和数据安全性,理论上只有在系统突然宕机的情况下丢失1s的数据。(严格来说最多丢失1s数据是不准确)

AOF工作流程如下:

  1. 所有的写入命令会追加到aof_buf(缓冲区)中。
  2. AOF缓冲区根据对应的策略向硬盘做同步操作。
  3. 随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的。(重写就是把Redis进程内的数据转化为写命令同步到新AOF文件的过程)
  4. 当Redis服务重启时,可以加载AOF文件进行数据恢复。

优点:

可以保持更高的数据完整性,如果设置追加file的时间是1s,如果redis发生故障,最多会丢失1s的数据;且如果日志写入不完整支持redis-check-aof来进行日志修复;

缺点:

AOF文件比RDB文件大,且恢复速度慢。

3.总结

RDB每次进行快照方式会重新记录整个数据集的所有信息。RDB在恢复数据时更快,可以最大化redis性能,子进程对父进程无任何性能影响。

AOF有序的记录了redis的命令操作。意外情况下数据丢失甚少。他不断地对aof文件添加操作日志记录,你可能会说,这样的文件得多么庞大呀。是的,的确会变得庞大,但redis会有优化的策略,比如你对一个key1键的操作,set key1 001 , set key1 002, set key1 003。那优化的结果就是将前两条去掉,那具体优化的配置在配置文件中对应的是
auto-aof-rewrite-percentage 100指超过上一次aof重写aof文件大小的百分之多少,会再次优化,如果没有重写过,则以启动时为主。
auto-aof-rewrite-min-size 64mb限制了允许重写的最小aof文件大小。

4.END
本文章是redis系列开篇第二章,主要介绍的是redis的几种数据类型和实用场景。redis连载系列文章请参考
Redis连载系列(一) redis的日常使用
Redis连载系列(二) redis的基本数据类型

欢迎大家关注我的个人公众号一起成长,一起进步 。本人比较才疏学浅,如有错误,欢迎指正

在这里插入图片描述
参考文章列表:
https://www.cnblogs.com/tdws/p/5754706.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值