Redis持久化之RDB&AOF学习笔记

文章目录

- RDB&AOF

RDB&AOF

为什么需要持久化？

把热点数据放到redis中缓存，有一天，redis突然宕机了，如果没有配置持久化，那么，所有缓存数据都会丢失，并且如果这个时候有大量的请求打进来，那么就会给db造成很大压力，甚至宕机，要想数据不丢失，就得配置持久化规则，配置持久化redis提供了两种实现 => rdb&aof。

RDB

什么是rdb？

RDB（Redis Database）：在指定的时间间隔执行数据集的时间点快照。

能干嘛？

在指定的时间间隔内将内存中的数据集快照写入磁盘(disk)，恢复时再将硬盘中的快照文件直接读回到内存里。

快照(Snapshotting)

默认情况下，Redis将数据集的快照保存在磁盘上（注意：这里的快照是全量快照，也就是说，把内存中的所有数据都记录到磁盘中），保存在一个名为dump.rdb的二进制文件中。如果数据集频繁更新，那么可以配置redis让它每n秒保存一次数据集，或者手动调用save或BGSAVE命令。

例如：你的redis每隔60秒至少有1000个key发生变化，那么每60秒就会自动将数据集写入磁盘上

save 60 1000

这种策略称为快照（snapshot）

它是如何工作的？

现在我们有了一个子进程和一个父进程。

子进程开始将数据集写入一个临时的RDB文件

当子进程写完新的RDB文件后，它会替换旧的RDB文件

使用案例

配置文件（redis6 VS redis7）

redis-6.0.18 redis.conf

redis-7.0.9 redis.conf

从以上图中可以看出，redis6与redis7的持久化配置规则有重大变更

自动触发

redis7版本，按照redis.conf里配置的save

配置示例：

上图表示10秒内两次修改就会自动触发保存快照

修改dump文件保存路径

默认配置：

自定义路径

如果想在redis客户端获取目录，可以使用以下命令

config get dir

修改dump文件名称

默认名称

修改后的名称

注意：修改完配置后，要想配置生效，一定要进入redis客户端使用shutdown命令让redis关机，然后再重新启动redis-server

触发快照备份

第一种情况：

没有任何修改之前，没有触发备份

set两个元素

10秒后观察有没有触发备份，产生dump6379.rdb这个快照文件

第二种情况：

set之前先看一下dump6379.rdb文件大小

添加一个元素后，再观察文件大小有没有变化

没有任何变化，因为10秒内我们只修改了一次

10秒后，我们再添加一个元素，再观察rdb文件大小是否有变化

我们发现rdb文件大小变了，说明它进行了一次快照保存，在这个地方有些读者可能会有疑问，不是说好10秒内至少两个key发生变化才会进行一次快照保存吗？为什么超过了10秒第二次set元素还会进行快照保存呢？

原因是这样的：

rdb底层有个计数器和计时器，只有进行了rdb快照，计数器和计时器才会重置，并且我们的rdb保存策略是每隔10秒至少两个key发生变化，意思就是它每隔10秒都会去检查你有没有满足保存策略的条件，还有一个就是多个策略效果不会叠加，如果想了解的更加深入，可以去读一读rdb实现源码。

注意： rdb快照保存策略其实是执行了bgsave命令，这个后面会说到。

手动触发

redis提供了两个命令来生成rdb文件，分别是save和bgsave。

save

在主程序中执行会阻塞当前redis服务器，直到持久化工作完成，执行save命令期间，redis不能处理其他命令，建议不要线上使用

使用案例：

save之前看下rdb文件大小

set一个元素，再用save命令保存，观察rdb文件大小

bgsave

工作原理：

redis会在后台异步进行快照操作，不阻塞快照同时还可以相应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程。
redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。

流程图：

fork是什么？

在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会进行一个操作，那就是exec系统调用，出于效率考虑，尽量避免膨胀。

使用案例：

现在我们是没有生成rdb文件的

在redis客户端添加一个元素，然后手动bgsave一下，再看有没有生成rdb文件

可以看到，我们执行bgsave命令后，rdb文件就生成好了

最后，可以通过lastsave命令获取最后一次执行快照保存的时间

示例：

可以看到返回的是一个时间戳

如何转换成日期？

Linux环境下：

也可以找一些时间戳在线转换的网站进行转换，这里就不演示了。

优势

RDB是Redis数据的一个非常紧凑的单文件时间点表示。RDB文件非常适合备份。例如，您可能想要对最近24小时内的RDB文件进行每小时存档，并保存30天内每天的RDB快照。这允许您在发生灾难时轻松地恢复数据集的不同版本。
RDB非常适合用于灾难恢复，因为它是一个紧凑的文件，可以传输到远端的数据中心或Amazon S3(可能是加密的)。
RDB最大化了Redis的性能，因为Redis父进程为了持久化所需要做的唯一工作就是创建一个子进程来完成剩下的所有工作。父进程永远不会执行磁盘I/O或类似操作。
与AOF相比，RDB允许在大数据集上更快地重启。
在副本上，RDB支持重启和故障转移后的部分重新同步。

如果不是很理解，可以看以下小总结：

适合大规模的数据恢复
按照业务定时备份
对数据完整性和一致性不高
RDB文件在内存中的加载速度要比AOF快得多

劣势

如果你需要在Redis停止工作(例如停电)的情况下最小化数据丢失的机会，那么RDB不是一个好选择。您可以配置生成RDB的不同保存点(例如，在对数据集进行至少5分钟和100次写入之后，您可以有多个保存点)。然而，你通常会每五分钟或更长时间创建一个RDB快照，所以如果Redis因为任何原因而停止工作，你应该做好丢失最新数据的准备。
为了使用子进程持久化到磁盘上，RDB经常需要fork()。如果数据集很大，fork()可能很耗时，如果数据集很大，CPU性能不太好，可能会导致Redis停止为客户端服务几毫秒甚至一秒钟。AOF也需要fork()，但不太频繁，你可以调整重写日志的频率，而无需权衡持久性。

如果不是很理解，可以看以下小总结：

在一定间隔时间做一次备份，如果redis意外宕机的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据丢失。
内存数据全量同步，如果数据量太大会导致I/O严重影响服务器性能
RDB依赖于主进程的fork，在更大的数据集中，还可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致两倍的膨胀性，需要考虑。

数据丢失案例：

此时是没有rdb文件的

set两个元素，rdb文件生成了

接下来我们set k3 v3 然后模拟宕机

只set一个元素，没有满足快照策略，所以数据不会被快照

当前redis里有3个key

突然意外宕机，然后重启redis服务器，查看数据是否丢失，发现k3数据没有被快照，这就是rdb缺点，丢失从当前至最近一次快照期间的数据

如何检查修复rdb文件？

使用redis-check-rdb命令即可

示例：

哪些情况会触发RDB快照？

redis.conf文件中配置的快照策略
手动save/bgsave命令
执行flushall/flushdb命令也会产生rdb文件，但是里面是空的，没有意义
主从复制时，主节点自动触发

如何禁用快照？

在redis-cli里使用以下这条命令即可

config set save ""

还有一种就是直接修改redis.conf

将save配置为 “” 即可

RDB优化配置项详解

SNAPSHOTTING

save （快照策略）
dbfilename （配置rdb文件名）
dir （rdb文件路径）
stop-writes-on-bgsave-error

默认yes

如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，

也能确保redis继续接受新的写请求
rdbcompression

默认为yes

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum

默认为yes

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
rdb-del-sync-files

在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。

小总结

RDB是一个非常紧凑的文件。
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
与AOF相比，在恢复大的数据集的时候，RDB的方式更会快一些。
RDB数据丢失风险大
RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能会导致redis在一些毫秒级不能响应客户端请求

AOF

什么是aof？

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

有了RDB为什么还要用AOF？

快照不是完全持久。如果你的redis服务器停机了，电源线故障了，或者你不小心kill -9掉了实例，最新写入Redis的数据将丢失。虽然对于某些应用程序来说这可能不是什么大问题，但有些用例需要完全的持久性，在这些情况下，单独使用Redis快照并不是一个可行的选择。

append-only file 是Redis的另一种完全持久的策略。

AOF能干嘛？

每次Redis接收到更改数据集(例如SET)的命令时，它都会将其添加到AOF中。当你重启Redis时，它会重新播放AOF来重建状态。换言之就是key发生改变时，他会把这条指令放到AOF文件中，当你重启redis时，他就会把AOF文件中的指令逐条执行，以达到数据恢复的效果。

从Redis 7.0.0开始，Redis使用了多部分AOF机制。也就是说，原始的单个AOF文件被拆分为基本文件(最多一个)和增量文件(可能有多个)。基本文件表示重写AOF时数据的初始快照(RDB或AOF格式)。增量文件包含自创建上一个基本AOF文件以来的增量更改。所有这些文件都放在单独的目录中，并由清单文件(manifest file)跟踪。

文件格式

默认为appendonly.aof，可以通过redis.conf修改

AOF工作流程

流程图：

Client作为命令的来源，会有多个源头以及源源不断的请求命令
在这些命令到达redis server以后并不是直接写入AOF文件，会将其这些命令先放进AOF缓存中进行保存，这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量后再写入磁盘，避免频繁的磁盘IO操作。
AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
随着写入AOF内容的增加，文件会越来越大，为了避免文件膨胀，会根据规则进行命令的合并（又称AOF重写）从而起到AOF文件压缩的目的。
当redis server重启的时候会从AOF文件中载入数据。

AOF缓冲区三种写回策略

Always

同步写回，每个命令执行完立刻同步的将日志写回磁盘。

everysec

每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘。

no

操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

小总结：

使用案例和说明AOF配置/启动/修复/恢复

配置文件说明（Redis 6 VS 7）

如何开启AOF？

使用默认写回策略，每秒钟

aof文件-保存路径

redis6:

AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置。
redis.conf

redis6 rdb与aof文件是保存在一个路径下的
保存的文件名

有且仅有一个，意思就是他只有这一个文件，而redis7有着重大变更

redis7：

AOF保存文件的最终路径： dir+appenddirname

保存的文件名：

在前面我们提到过Redis Multi Part AOF，redis的多部分AOF，什么意思呢？就是不只是有一个AOF文件，而是有多个AOF文件，下面我们就来介绍一下配置文件：

base：基本文件

incr：增量文件

manifest：清单文件

Multi Part AOF的实现：

数据恢复案例

正常恢复

启动AOF，修改配置文件，把appendonly设置为yes

启动之后，我们看看生成的aof文件（注意观察文件大小）

进行写操作，然后观察AOF文件大小

我们发现3个aof文件只有增量文件有变化，为什么呢？因为我们的写操作命令是保存到增量文件里的

恢复数据1：

我们重启redis模拟宕机，看看数据会不会恢复（使用shutdown命令模拟宕机）

启动redis server

连接上redis-cli之后，我们可以使用keys * 指令查看我们的key有没有丢失

数据恢复成功！

恢复数据2：

首先，写入数据进redis，备份新生成的aof文件，然后flushdb+shutdown服务器

示例：

以上操作做完之后，我们重启redis试试能不能将数据恢复？

我们发现数据没了，为什么？

因为flushdb也是写操作，这条命令写进了我们的增量文件，重启redis的时候命令全部加载，所以数据没了。

使用备份的aof文件试试？

修改完后记得重启redis-server

数据回来了

异常恢复

故意乱写正常的AOF文件模拟网络闪断文件写Error

重启redis后就会进行AOF文件的载入

发现根本启动不了

这个时候我们使用redis-check-aof --fix 命令修复aof文件

示例：

修复成功，此时我们再看增量文件，发现乱写的那个配置已经没了

重新启动redis，看看能不能启动，然后看看数据有没有恢复

redis启动成功，数据也恢复了

优势

使用AOF Redis更持久:你可以有不同的fsync策略:完全不同步、每秒同步、每次查询都同步。使用默认的每秒同步策略，写性能仍然很好。Fsync是使用后台线程执行的，当没有正在进行的Fsync时，主线程将努力执行写入操作，因此您只能丢失一秒的写入值。
AOF日志是一个只能追加的日志，因此在停电时不会出现寻道或腐败问题。即使日志由于某些原因(磁盘已满或其他原因)以写了一半的命令结束，redis-check-aof工具也能够轻松地修复它。
Redis能够在后台自动重写AOF，当它变得太大时。重写是完全安全的，因为当Redis继续追加到旧文件时，使用创建当前数据集所需的最小操作集生成一个全新的文件，一旦第二个文件准备好，Redis会切换两个文件并开始追加到新文件。
AOF以易于理解和解析的格式一个接一个地包含所有操作的日志。您甚至可以轻松导出AOF文件。例如，即使用户不小心使用FLUSHALL命令刷出了所有数据，只要在此期间没有重写日志，用户仍然可以通过停止服务器、删除最新的命令并重新启动Redis来保存数据集。

演示一下第4点

示例：

不小心执行了flushall 命令，怎么办？

这个时候千万不要直接重启redis，先查看aof增量文件（如果这时候你直接重启了redis服务器，那直接跑路吧）

这个时候发现增量文件里多了个flushall命令，我们把它删除即可，删除之后再重启redis，看看数据会不会恢复

可以看到，数据已经恢复了

小总结：

更好的保护数据并不丢失、性能高、可做紧急恢复。

劣势

对于相同的数据集，AOF文件通常比对应的RDB文件大。
AOF可能比RDB慢，这取决于确切的fsync策略。一般来说，如果将fsync设置为每秒一次，性能仍然非常高，如果禁用fsync，即使在高负载下，它的速度也应该与RDB一样快。即使在写负载很大的情况下，RDB仍然能够为最大延迟提供更多的保证。

小总结：

1. 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。
1. aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。

AOF重写机制

是什么？

官网说明：

随着写操作的执行，AOF变得越来越大。例如，如果你对一个计数器加100次，那么数据集中只有一个键包含最终值，而AOF中有100个条目。其中99项不需要重建当前状态。
重写是完全安全的。当Redis继续向旧文件追加内容时，它会使用创建当前数据集所需的最小操作集生成一个全新的文件，一旦第二个文件准备好，Redis会切换两个文件并开始向新文件追加内容。
因此，Redis支持一个有趣的功能:它能够在不中断客户端服务的情况下在后台重建AOF。每当你发出BGREWRITEAOF时，Redis都会编写所需的最短命令序列，以在内存中重建当前数据集。如果你在Redis 2.2中使用AOF，你需要时不时地运行BGREWRITEAOF。因为Redis 2.4能够自动触发日志重写(更多信息请参见示例配置文件)。
由于Redis 7.0.0，当计划重写AOF时，Redis父进程会打开一个新的增量AOF文件来继续写入。子进程执行重写逻辑并生成一个新的基本AOF。Redis将使用临时清单文件来跟踪新生成的基础文件和增量文件。当它们准备好时，Redis将执行一个原子替换操作，使这个临时清单文件生效。为了避免在AOF重写的重复失败和重试的情况下创建许多增量文件的问题，Redis引入了AOF重写限制机制，以确保失败的AOF重写以越来越慢的速度重试。

小总结：

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集或者可以手动使用命令 bgrewriteaof 来重新。

如果以上都看不太懂，那就一句话：启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

触发机制

默认配置

注意，同时满足，且的关系才会触发

1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍。

2 重写时满足的文件大小。

自动触发

满足配置文件中的选项后，Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64MB时。

案例说明：

启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

**举个例子：**比如有个key

一开始你 set k1 v1

然后改成 set k1 v2

最后改成 set k1 v3

如果不重写，那么这3条语句都在aof文件中，内容占空间不说启动的时候都要执行一遍，共计3条命令；但是，我们实际效果只需要set k1 v3这一条，所以，开启重写后，只需要保存set k1 v3就可以了只需要保留最后一次修改值，相当于给aof文件瘦身减肥，性能更好。

AOF重写不仅降低了文件的占用空间，同时更小的AOF也可以更快地被Redis加载。

“启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集”，怎么证明这句话是正确的呢？这句话需要得到验证，话不多说，上实操

开启AOF
重写峰值修改为1k
关闭混合，设置为no
删除之前的aof与rdb文件，清除干扰项（注意：如果这里没有rdb文件，就不用管）
完成上述正确配置，重启redis服务器，执行set k1 v1 查看aof文件是否正常
查看三大配置文件（基本文件、增量文件、清单文件）
不停的给k1 set新的值，注意观察增量文件大小
重写触发

压缩瘦身之后将最小指令集临时保存到base文件中

手动触发

客户端向服务器发送bgrewriteaof命令

观察aof文件，发现已经瘦身成功

结论

也就是说AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
AOF文件重写触发机制：通过redis.conf配置文件中的auto-aof-rewrite-percentage：默认值为100，以及auto-aof-rewrite-min-size：64mb配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64MB时触发。

重写原理

在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

AOF优化配置项详解

redis.conf文件APPEND ONLY MODE模块

小总结

RDB-AOF混合持久化

从以下图中可以看出，官网也是推荐这种方式的

官网说明：

Redis >= 2.4确保在RDB快照操作正在进行时避免触发AOF重写，或者在AOF重写正在进行时允许BGSAVE。这可以防止两个Redis后台进程同时进行繁重的磁盘I/O操作。
当快照正在进行中，并且用户使用BGREWRITEAOF显式请求日志重写操作时，服务器将以OK状态码回复用户，告诉用户操作已被调度，并且在快照完成后将开始重写。
在同时启用AOF和RDB持久性的情况下，Redis会重启AOF文件来重建原始数据集，因为它保证是最完整的。

问题

可否共存？如果共存先加载谁？

AOF和RDB持久性可以同时启用，不会有问题。如果启动时启用了AOF, Redis将加载AOF，即文件具有更好的持久性保证。

数据恢复顺序与加载流程

在同时开启rdb和aof持久化时，重启时只会加载aof文件，不会加载rdb文件。

同时开启两种持久化方式

在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着RDB作为一个兜底方案。