四、redis持久化之RDB与AOF

导读

前面文章【一、深入理解redis之需要掌握的知识点 】中,我们对redis需要学习的内容框架进行了一个梳理。

二、redis中String和List两种数据类型和应用场景 】、【二、redis中Hash、Set、SortedSet应用场景 】两篇文章我们对redis中String、List、Hash、Set、SortedSet五种数据类型做了一下讲解,并且对他们各自的应用场景进行了介绍。

三、redis数据存储之跳跃表(SKIP LIST) 】深入学习支撑SortedSet排序背后的数据结构,跳跃表;

本篇文章我们将要学习redis中的两种持久化策略:RDB(快照)和AOF(追加日志)
在这里插入图片描述如果大家在工作、学习、面试中针对redis还有什么疑问或者其他问题,可以评论区告诉我。
为了保证可以连续不间断的获取最新的技术分析及讲解,建议关注本博客【不吃_花椒】。

RDB(快照)

介绍:

定时(指定时间间隔)对内存数据进行快照存储,例如每半个小时进行一次。整个内存数据序列化后成为二进制文件(dump.rdb)的形式保存在磁盘上。

优点:

1.定时生成,可以根据需求恢复到不同的版本;
2.在恢复大数据集方面相比AOF形式,生成速度快恢复速度快。
3.rdb文件非常小且紧凑,非常适合容灾备份;
4.在生成rdb文件时候,是在redis服务fork出的子进程中进行的,因此可以最大化的保持redis的性能。

缺点:

1.只能保存某一时刻的全量数据。如果在某个未进行快照保存的时间窗口内redis服务出现错误或者崩溃,那么当前崩溃时间到上一次执行快照保存时间之间的数据将丢失。如果不能接受丢失一段时间的数据,那么不建议选择这种方式。
2.在进行RDB形式的数据持久化时,需要经常fork出子进程。如果数据集很大且CPU和磁盘IO性能较低时候,会对主进程产生影响。

使用示例:

1.可以对 Redis 进行设置, 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时, 自动保存一次数据集。你也可以通过调用 SAVE或者 BGSAVE , 手动让 Redis 进行数据集保存操作。

以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时, 自动保存一次数据集:

save 60 1000

这种持久化方式被称为快照 snapshotting.

工作方式:

使用写时复制机制保证创建持久化文件时数据安全

1.当需要生成.rdb文件时候,redis主进程fork出一个子进程;
2.子进程去生成新的rbd文件;
3.子进程生成新rdb文件后,主进程用新rdb文件替换原来的rdb文件,并删除原RDB文件。

AOF(追加日志)

介绍:

以redis协议追加的形式把所有的写操作都写入到日志文件末尾。Redis会对追加的文件进行重写,以保证日志文件不会特别大。当服务器奔溃时,可以从日志文件中恢复所有数据。

优点:

1.提供多种形式的同步策略(fsync):无sync、每秒一次sync(默认)、每次写入操作进行一次sync。Fsync由redis主进程fork出的子进程进行,不会占用太多redis性能;在默认配置项下,即使数据丢失也只丢失1秒的数据。

2.aof文件是一个只可以进行追加的日志文件。即使在磁盘满了、写入过程中服务器奔溃、断电等情况出现时,也可以使用redis-check-aof命令修复aof文件。

3.在aof文件过大时,redis会自动在后台对aof文件进行重写。重写后的文件以最小命令集的方式可以恢复当前数据,并且redis保证这个过程是安全的。

4.aof文件中的所有写入操作命令是有序的并且遵从redis协议简单易读。当出现误操作时(例如执行了FLUSHALL命令),我们在aof文件中把该误写的命令删除掉,重启redis即可恢复之间的样本数据。

缺点:

1.相对于rdb文件,aof文件体积较大,更加占用磁盘空间。

2.根据所使用的sync策略,aof的速度可能慢于RDB。不过这种缺点也是相对的,如果AOF形式下使用无SYNC策略,那么AOF可以与RDB一样快;如果在实际使用过程中,对REDIS的写入操作超级多,那么AOF形式的速度要慢于RDB的。

AOF持久化模式下的三种SYNC策略:

1.每个写入操作都进行SYNC操作(非常慢、但是安全);
2.每秒进行一次SYNC操作,即使奔溃也只丢失一秒数据(速度可与RDB媲美);
3.无SYNC操作,速度更快,更加不安全;

注意:推荐使用每秒一次SYNC的方式,该方式也是AOF方式持久化的默认策略,该策略兼顾了安全和速度。

使用示例:

1.配置文件中配置appendonly yes 打开AOF持久化方式;

2.redis2.2之后,redis提供了AOF手动重写的功能,redis2.4之后提供自动重写。使用BGREWRITEAOF命令可以在自动的基础上手动触发AOF重写功能。AOF重写优化示例:对某一个key进行了100次INCR操作,最后结果为100,实际只需要一个SET操作即可解决内存中数据存储问题。

工作方式:

使用写时复制机制保证创建持久化文件时数据安全

1.redis主进程fork一个子进程去创建新的AOF文件。

2.redis主进程继续往旧的AOF文件末尾追加数据,同时把这部分数据放入一个缓存中。

3.子进程完成创建AOF文件后通知主进程,主进程把缓存中的内容追加到新的AOF文件中。

4.主进程把新的AOF文件替换原AOF文件,删除原AOF文件

如何选择哪种形式的持久化

1.如果只希望redis中的数据只有在运行是存在,那么可以不配置任何类型的持久化。

2.如果可以接受一定数据的丢失,那么可以只开启RDB形式。

3.如果想保证全量数据都存在,那么可以开启AOF形式。

4.可以RDB、AOF两种形式都开启。但是redis在重启时会优先使用AOF文件中的数据进行恢复,因为AOF文件中的数据更加完整。

5.更高版本的REDIS中,优化了AOF形式的数据备份。把AOF和RDB进行了整合。Redis4.x之后做了做了整合和混淆。既有RDB又有AOF。

RDB与AOF的相互作用

在版本号大于等于 2.4 的 Redis 中, BGSAVE 执行的过程中, 不可以执行 BGREWRITEAOF 。 反过来说, 在 BGREWRITEAOF 执行的过程中, 也不可以执行 BGSAVE。这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。

如果 BGSAVE 正在执行, 并且用户显示地调用 BGREWRITEAOF 命令, 那么服务器将向用户回复一个 OK 状态, 并告知用户, BGREWRITEAOF 已经被预定执行: 一旦 BGSAVE 执行完毕, BGREWRITEAOF 就会正式开始。

当 Redis 启动时, 如果 RDB 持久化和 AOF 持久化都被打开了, 那么程序会优先使用 AOF 文件来恢复数据集, 因为 AOF 文件所保存的数据通常是最完整的。

如需了解更多更详细内容也可关注本人CSDN博客:不吃_花椒

后续redis中将要讲解的内容梳理

在这里插入图片描述
在这里插入图片描述在这里插入图片描述

往期文章

Redis

一、深入理解redis之需要掌握的知识点

二、redis中String和List两种数据类型和应用场景

二、redis中基础数据类型Hash、Set、SortedSet及其应用场景

三、redis数据存储之跳跃表(SKIP LIST)

Java集合

一、深入理解-Java集合初篇

二、Jdk1.7和1.8中HashMap数据结构及源码分析

三、JDK1.7和1.8HashMap数据结构及源码分析-续

四、深入理解Java中的HashMap「网易面试快答」

五、深入理解JDK1.7中HashMap哈希冲突解决方案

六、深入理解JDK1.8中HashMap哈希冲突解决方案

七、JDK1.7中HashMap扩容机制

八、JDK1.8中HashMap扩容机制

Java-IO体系

一、C10K问题经典问答

二、java.nio.ByteBuffer用法小结

三、Channel 通道

四、Selector选择器

五、Centos-Linux安装nc

六、windows环境下netcat的安装及使用

七、IDEA的maven项目的netty包的导入(其他jar同)

八、JAVA IO/NIO

九、网络IO原理-创建ServerSocket的过程

十、网络IO原理-彻底弄懂IO

十一、JAVA中ServerSocket调用Linux系统内核

十二、IO进化过程之BIO

十三、Java-IO进化过程之NIO

十四、使用Selector(多路复用器)实现Netty中Reactor单线程模型

十五、使用Selector(多路复用器)实现Netty中Reactor主从模型

十六、Netty入门服务端代码

十七、IO进化过程之EVENT(EPOLL-事件驱动异步模型)

如需了解更多更详细内容也可关注本人CSDN博客:不吃_花椒

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值