四、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博客：不吃_花椒