四、redis持久化之RDB与AOF-CSDN博客

本文链接：https://blog.csdn.net/yueaini10000/article/details/109329320

导读

前面文章【一、深入理解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。