本篇文章会对Redis的持久化进行详解。主要涉及到的方面有：redis为什么需要持久化、redis怎么进行的持久化、持久化的方式都有哪些、每种持久化方式的优缺点是什么、持久化的流程进行展开详解。希望本篇文章会对你有所帮助。
文章目录
🙋♂️ 作者：@Ggggggtm 🙋♂️
👀 专栏：Redis 👀
💥 标题：Redis中的持久化详解💥
❣️ 寄语：与其忙着诉苦，不如低头赶路，奋路前行，终将遇到一番好风景 ❣️
一、持久化简介
什么是持久化？简单理解，就是把数据保存到可以永久存放数据的介质中（通常是磁盘等硬件）。我们知道，在内存中的数据一旦进程出现问题或者掉电，那么数据就丢失了。为了防止一些重要的数据因突发情况而丢失，必不可少的就是对数据进行持久化操作。
一提到持久化，不知道你是不是能够想到Mysql事务的特性：原子性、一致性、持久性、隔离性。而这里的持久性实际上是和持久化是一个概念。Mysql是怎么做到持久化的呢？很简单，就是把数据保存在了磁盘上了。
但是Redis是一个内存数据库，是把数据存储在内存中的。那么一旦内存掉电或者进程异常终止，如果不对数据进行持久化保存，那么就会造成数据丢失。所以内存中的数据是不持久的！要想能够做到持久，就需要让redis把数据存储到硬盘上。什么？？写硬盘？？？那不就和Mysql一样了吗？为了保证速度快和持久化，Reids做法是：内存中也存数据，硬盘上也存数据（既要也要）。理论上这两份数据应该完全相同的，但实际上是很难做到的。这就关系到Redis怎么去做持久化了。我们接着往下看。
二、Redis的持久化
在Redis中，当要插入一个新的数据的时候，就需要把这个数据同时写入到内存和硬盘。这样效率会不会很低呢？实际上Redis在写硬盘上有着自己的策略来保证整体的效率。当我们在查询数据的时候，还是直接从内存中读取。而硬盘上的数据只是Redis在启动时，用来回复内存中的数据使用的！
上述也提到了Redis在写硬盘上有着自己的策略来保证整体的效率，不同的策略也就是对应的不同的持久化方案！Redis 提供了两种主要的持久化方案：RDB（Redis DataBase）和 AOF（Append Only File）。
- RDB 持久化：RDB 持久化是通过创建快照来保存 Redis 数据库在某个时间点的状态。在redis重新启动时，加载快照的方式来实现数据恢复。
- AOF 持久化：AOF 持久化则是通过记录 Redis 服务器执行的所有写命令来保存数据库状态。在redis重新启动时，通过执行保存的命令来实现数据恢复。
先把两种方式的概念引出，下面我们再来慢慢体会两者细节与区别！
2、1 RDB
不知道大家有没有备份数据的习惯。试想一下：在备份数据时，我们可以选择每隔一段时间把我电脑硬盘上重要数据整体的备份到这个备份盘中（定期备份），也可以只要我更新过重要的数据就立即把这个学习资料往备份盘中拷贝一份（实时备份）。
RDB就是定期的把我们Redis内存中的所有数据，生成一个"快照"，然后写入硬盘中。怎么理解这里的快照呢？数据“快照”可以理解为对某一时刻 Redis 数据库中的状态的一个完整“拍照”或“复制”。更具体地说，当触发 RDB 持久化操作时，Redis 会将当前内存中的数据库数据进行一次性的复制和序列化，将其以紧凑的二进制格式存储到磁盘上，形成一个.rdb 文件。这个.rdb 文件就是所谓的“快照”。打个比方，您可以想象 Redis 数据库是一个装满各种物品的房间，而生成 RDB 快照就像是快速地给这个房间里所有物品的摆放状态拍了一张照片，并且将这个照片（也就是.rdb 文件）保存了起来。之后，如果 Redis 数据库出现故障或者需要恢复数据，就可以依据这个“照片”（.rdb 文件）来还原当时数据库中的数据状态。
后续Redis 一旦重启了，内存数据就没了。就可以根据刚才的“快照"就能把内存中的数据给恢复出来！话又说回来，RDB是定期形成快照，但定期是指的什么时候形成快照呢？
2、2 RDB快照形成
2、2、1 触发方式
RDB快照的触发方式分为两种：手动触发和自动触发。手动触发分别对应save和 bgsave命令：
- save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例造成长时间阻塞，基本不采用。
- bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork阶段，一般时间很短。
Redis是单线程模型，如我们使用save命令形成快照，在此期间Redis会被阻塞住，造成Redis服务器不能够及时处理客户端的命令，进而造成一些列不好的影响。所以还是十分不推荐的。这对这种情况Redis怎么做的呢？是不是偷摸搞了个多线程啥的？并非如此！此处 redis使用的是"多进程"的方式来完成的并发编程。也就是上述的 bgsave 的实现~
自动触发可以在 Redis 的配置文件（redis.conf）中设置触发 RDB 持久化的条件。下文（对应小结：2、2、3）会讲解到。
2、2、2 快照形成原理
了解到快照形成是有多进程来实现的，具体的流程是什么的？我们看如下图：
首先，这里的多进程是指的父进程通过fork（）函数创建了一个子进程。生成RDB快照的任务交给了子进程去完成，此时父进程依然可以处理客户端来的请求和命令。其中的细节如下：
- 执行bgsave 命令，Redis父进程判断当前进是否存在其他正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
- 父进程执行fork创建子进程，fork过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一次fork操作的耗时，单位为微秒。
- 父进程fork完成后，bgsave命令返回"Background saving started"信息并不再阻塞父进程，可以继续响应其他命令。
- 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。
- 子进程发送信号给父进程表示完成，父进程更新统计信息。
2、2、3 RDB效果演示
redis 生成的rdb文件是存放在redis的工作目录中的。也是在redis 配置文件中可以设置的。小编使用的ubuntu的系统。当我们安装了redis后，可在 /etc/redis/redis.conf中更改配置。具体如下图：
具体配置如下：
我们可以去该路经下看一下：
我们看到有一个 dump.rdb 文件。该文件就是rdb机制生成的镜像文件。这也说明redis服务器默认就是开启了rdb 的。该文件是以二进制的方式来保存数据的，把内存中的数据以压缩的形式，保存到这个二进制文件中。需要注意的是压缩需要消耗一定的cpu资源，但是能节省存储空间。
Redis自始至终只会有一个rdb文件。当执行生成 rdb镜像操作的时候，此时就会把要生成的快照数据，先保存到一个临时文件中。当这个快照生成完毕之后，再删除之前的rdb文件，把新生成的临时的rdb文件名字改成刚才的dump.rdb 。
生成的rbd文件的名字是dump.rdb，改名字也是可以自己进行配置的。还是刚才的配置文件如下图：
自动触发的方式我们也可以在该文件中查看，具体如下：
上图中的"save m n"表示m秒内数据集发生了n次修改，会进行自动RDB持久化。例如 save 900 1 表示 900 秒内如果至少有 1 个键被修改，就会触发 BGSAVE 进行 RDB 持久化。另外还有自动触发的持久化的条件：
- 执行shutdown命令时，如果没有开启 AOF 持久化，Redis 会自动执行 BGSAVE 操作。
- 当主从复制时，如果从节点执行全量复制操作，主节点会自动执行 BGSAVE 生成 RDB 文件并发送给从节点用于数据同步。
上述的第一条会在本篇文章中解释，第二条会须文章会解释。
虽然此处的这些数值都可以自由修改配置，但是此处修改上述数据的时候,要有一个基本的原则：生成一次rdb 快照这个成本是一个比较高的，不能让这个操作执行的太频繁！正因为rdb生成的不能太频繁，这就导致快照里的数据和当前实时的数据情况可能存在偏差！举个例子：两次生成rdb之间的间隔最少得是60s，12:00:00生成了rdb(硬盘上的快照数据和内存中一致)，12:00:01开始, redis 收到了大量的key的变化请求，12:01:00生成下一个快照文件。在12:01:00之前, redis服务器挂了！此时就会导致，12:00:00之后的这些数据就丢了！！这也是定期持久化的一个坏处！
现在我们来手动生成一次快照。如下图他：
再来看一下对应的dump.rdb文件。如下图：
不要忘记rdb是以二进制形式存储数据的，当然看不出来的所以然。我们在添加一些命令，再来看一下该文件。如下图：
我们看到里面的数据确实多了，并且能够看到key1、key、key3，至于其他的就不了解了。此时我们重启redis的服务器，如下图：
再次打开客服端查看，之前的键值都还存在，如下图：
原因就是 redis 服务器在重新启动的时候加载了rdb文件的内容，恢复了内存中之前的状态了。
bgsave操作流程是创建子进程，子进程完成持久化操作。由于我们这里的数据很少，持久化速度太快了。难以观察到子进程。持久化会把数据写入到新的文件中，然后使用新的文件替换旧的文件。这个是容易观察到的！我们可以通过使用stat命令，查看问价拿到inode编号，如下：
如果插入新的key，不手动执行bgsave呢？如果是通过正常流程重新启动redis服务器, 此时 redis服务器会在退出的时候,自动触发生成 rdb操作。这也就是我们前面所说的通过shutdown命令(redis里的一个命令)关闭redis服务器，或者(service redis-server restart)正常关闭都会触发自动生成rdb。但是如果是异常重启(kill -9或者服务器掉电)此时redis服务器来不及生成 rdb，内存中尚未保存到快照中的数据，就会随着重启而丢失。这里大家可以自己实操验证一下！
注意：如果自己修改rbd文件，或者其他原因导致rdb文件损坏，那么重启redis服务端时，就会导致重启失败！
2、2、4 RDB的优缺点
通过上面的了解，我们再来总结一下RDB的优缺点。
- RDB是一个紧凑压缩的二进制文件，代表Redis 在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件复制到远程机器或者文件系统中(如hdfs)用于灾备。
- Redis 加载RDB恢复数据远远快于AOF的方式。
- RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork创建子进程，属于重量级操作，频繁执行成本过高。
- RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个RDB版本，兼容性可能有风险。
RDB这里使用二进制的方式来组织数据，直接把数据读取到内存中，按照字节的格式取出来放到结构体/对象中即可。AOF 是使用文本的方式来组织数据的，则需要进行一系列的字符串切分操作！二进制的文件读取天然的就比文本文件快！
其次需要注意的是：老版本的redis的rdb文件,放到新版本的redis 中不一定能识别！！！
2、3 AOF
通过上述了解到RDB最大的问题,不能实时的持久化保存数据！在两次生成快照之间,实时的数据可能会随着重启而丢失。我们再来看一下AOF持久化。
AOF 持久化则是通过记录 Redis 服务器执行的所有写命令来保存数据库状态。类似于mysql的 binlog，就会把用户的每个操作,都记录到文件中。当redis重新启动的时候，就会读取这个aof文件中的内容，用来恢复数据！aof默认一般是关闭状态，可修改配置文件来开启aof 功能。当开启aof的时候, rdb就不生效了，启动的时候不再读取rdb 文件内容了，而是读取aof文件。配置文件依然是 /etc/redis/redis.conf，具体如下图：
当我们开启AOF持久化时，会自动给我们生成一个appendonly.aof文件。如下图：
我们不妨来看一下该文件中的内容，如下：
通过上图我们能看到：AOF是一个文本文件，每次进行的操作,都会被记录到文本文件中。通过一些特殊符号作为分隔符,来对命令的细节做出区分~~(具体分隔符的规则,不必研究)
Redis虽然是一个单线程的服务器，但是速度很快！为啥速度快?重要原因只是操作内存。引入AOF之后，又要写内存又要写硬盘，还能和之前一样快了嘛??实际上，是没有影响的!!!并没有影响到redis 处理请求的速度~~
- AOF机制并非是直接让工作线程把数据写入硬盘，而是先写入一个内存中的缓冲区，积累一波之后再统一写入硬盘；
- 硬盘上读写数据,顺序读写的速度是比较快的(还是比内存要慢很多)，随机访问则速度是比较慢的。AOF是每次把新的操作写入到原有文件的末尾，属于顺序写入~~
这里有引出一个问题：如果把数据写入到缓冲区里，本质还是在内存中啊。万一这个时候,突然进程挂了，或者主机掉电了，咋办??是不是缓冲区中的数据就丢了???是的！缓冲区中没来得及写入硬盘的数据是会丢的。我们想一下：Redis本身就是为效率和速度而生的，如果Redis每执行一条指令就去进行写盘持久化，那么就会大大的影响到效率！所以并没有百分百的保证数据不会丢失！
redis给出了一些选项，让程序猿根据实际情况来决定怎么取舍。缓冲区的刷新策略：刷新频率越高,性能影响就越大,同时数据的可靠性就越高。刷新频率越低，性能影响就越小，数据的可靠性就越低~~具体如下：
实际上在配置文件中我们也可以看到，如下图：
上述配置策略说明如下：
- Always：服务器每写入一个命令，就调用一次 fsync函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据，但是其执行速度较慢；
- Everysec（默认）：服务器每一秒调用一次 fsync 函数，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据，通常都使用它作为 AOF 配置策略；
- No：服务器不主动调用 fsync 函数，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的，所以这种策略，不确定性较大，不安全。
redis默认选择的Everysec。无法保证1秒内的数据，也就是最多丢失1秒的数据。系统调用write和 fsync 说明：
- write操作会触发延迟写(delayed write)机制。Linux在内核提供页缓冲区用来提供硬盘IO性能。write操作在写入系统缓冲区后立即返回。同步硬盘操作依赖于系统调度机制，例如:缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
- Fsync针对单个文件操作，做强制硬盘同步，fsync将阻塞直到数据写入到硬盘。
2、4 AOF的重写机制
我们知道，AOF机制是网文件末尾写入命令的。那么Redis 在长期运行的过程中，aof 文件会越变越长。如果重启服务器，加载 aof 文件来恢复数据会非常耗时，导致长时间 Redis 无法对外提供服务。因此就需要对 aof 文件做一下“瘦身”运动。
2、4、1 触发方式
AOF重写过程可以手动触发和自动触发:
- 手动触发：调用bgrewriteaof命令。
- 自动触发∶根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
auto-aof-rewrite-min-size:表示触发重写时AOF的最小文件大小，默认为64MB。auto-aof-rewrite-percentage:代表当前AOF占用大小相比较上次重写时增加的比例。举个例子：加入auto-aof-rewrite-min-size为64MB，auto-aof-rewrite-percentage为100，只有当 aof 文件的增量大于 100% 时才进行重写，也就是大一倍。比如，第一次重写时文件大小为 64M，那么第二次触发重写的体积为 128M，第三次重写为 256M，以此类推。如果将百分比值设置为 0 就表示关闭 AOF 自动重写功能。
重写后的AOF为什么可以变小?有如下原因:
- 进程内已超时的数据不再写入文件（无效数据扔掉）。
- 旧的AOF中的无效命令，例如set与del、hset与hdel、sadd与srem等重写后将会删除，只需要保留数据的最终版本。
- 多条写操作合并为一条，例如lpush list a、lpush list b、lpush list 从可以合并为lpush list a b c。
因此 redis 就存在一个机制,能够针对aof文件进行整理操作。这个整理就是能够剔除其中的冗余操作,并且合并一些操作,达到给aof文件瘦身这样的效果。较小的AOF文件一方面降低了硬盘空间占用，一方面可以提升启动Redis时数据恢复的速度。
2、4、2 AOF的工作流程
通过上面对AOF机制的了解后，理解起来AOF的工作流程也就简单了。AOF的工作流程操作：命令写入(append)、文件同步(sync)、文件重写(rewrite)、重启加载(load)，如下图所示：
- 所有的写入命令会追加到aof_buf(缓冲区)中。
- AOF缓冲区根据对应的策略向硬盘做同步操作。
- 随着AOF文件越来越大，需要定期对AOF 文件进行重写，达到压缩的目的。
- 当Redis服务器启动时，可以加载AOF文件进行数据恢复。
2、4、3 AOF的重写流程
AOF重写也是采用了多进程的方式，与RDB形成快照流程类似，但是又有区别。我们来看一下：
注意：重写的时候，不关心aof 文件中原来都有啥。只是关心内存中最终的数据状态！子进程只需要把内存中当前的数据获取出来,以AOF的格式写入到一个新的AOF文件中(内存中的数据的状态，就已经相当于是把AOF文件结果整理后的）。此处子进程写数据的过程，非常类似于RDB生成一个镜像快照~~只不过 RDB这里是按照二进制的方式来生成的。AOF 重写,则是按照AOF这里要求的文本格式来生成的。
子进程写新aof文件的同时，父进程仍然在不停的接收客户端的新的请求。父进程还是会写把这些请求产生的AOF数据先写入到缓冲区，再刷新到原有的AOF文件里！在创建子进程的一瞬间,子进程就继承了当前父进程的内存状态。因此子进程里的内存数据是父进程fork之前的状态。fork之后新来的请求,对内存造成的修改,是子进程不知道的。此时,父进程这里又准备了一个aof_rewrite_buf 缓冲区，专门放fork 之后收到的数据。子进程这边把 aof数据写完之后，会通过信号通知一下父进程，父进程再把aof_rewrite_buf 缓冲区中的内容也写入到新AOF文件里。就可以用新的AOF文件代替旧的AOF文件了~~
整体重写流程总结如下图：
rdb对于fork之后的新数据,=，就直接置之不理了。aof则对于fork之后的新数据采取了aof rewrite_buf缓冲区的方式来处理。rdb本身的设计理念就是用来"定期备份”的！只要是定期备份，就难以和最新的数据保持一致~~
aof的理念则是实时备份！虽然也有可能丢失数据，但是丢失概率和数据量相对来说很小了。这里有会有一个疑问：父进程fork完毕之后，就已经让子进程写新的 aof文件了。并且随着时间的推移，子进程很快就写完了新的文件,要让新的 aof文件代替旧的。父进程此时还在继续写这个即将消亡的旧的aof文件是否还有意义？这里是考虑到极端情况了。假设在重写过程中,重写了一半了,服务器挂了，子进程内存的数据就会丢失,新的aof文件内容还不完整。所以如果父进程不坚持写旧aof文件,重启就没法保证数据的完整性了~~所以还是有必要的！
2、4、4 AOF的优缺点
综上我们再总结一下AOF的优缺点。
- AOF持久化机制更稳健，丢失数据概率更低（1秒）。
- 可通过reids的日志文本，通过操作AOF文件，可以处理误操作。
- 比RDB占用更多的磁盘空间（文本方式，RDB二进制压缩）。
- 恢复备份速度要慢（文本方式的读取天然比二进制慢）。
- 每次读写都同步的话，有一定的性能压力。
总结（摘自：Redis的持久化详解）：
- AOF文件是一个只进行追加的日志文件；
- Redis可以在AOF文件体积变得过大时，自动地在后台对AOF文件进行重写；
- AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松；
- 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积；
- 根据所使用的fsync策略，AOF的速度可能会慢于RDB。
注意：当redis 上同时存在aof文件和rdb快照的时候，此时重启加载数据以谁为主？以aof为主！！ rdb就直接被忽略了。AOF中包含的数据比RDB更全啊！
三、混合持久化
重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为可能会丢失数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。
Redis 的混合持久化是指将 RDB 快照和 AOF 日志相结合的一种持久化方式。在 Redis 4.0 及以后的版本中引入了混合持久化。
在混合持久化中，Redis 会在执行 AOF 重写时，将当前内存中的数据以 RDB 快照的形式写入 AOF 文件的开头，然后再将后续的 AOF 日志追加到文件的末尾。这样，AOF 文件的开头部分是 RDB 快照，记录了某一时刻的数据集，而后续部分则是 AOF 日志，记录了对数据集的增量修改。注意：这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。
混合持久化的加载流程如下：
混合持久化的优点包括：
- 快速恢复：在 Redis 重启时，可以首先加载 RDB 快照来快速恢复数据集，然后再通过重放 AOF 日志中的增量修改来恢复数据的完整性。这样可以大大提高 Redis 的启动速度。
- 减少 AOF 文件大小：由于 RDB 快照是压缩的二进制格式，通常比 AOF 日志小得多，因此将 RDB 快照嵌入到 AOF 文件中可以减少 AOF 文件的整体大小。
- 数据完整性：结合了 RDB 快照和 AOF 日志的优点，既能保证数据的快速恢复，又能提供较高的数据完整性。
缺点：
- AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
- 兼容性差，如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。
要开启混合持久化，需要在 Redis 配置文件中进行相应的设置。一般来说，需要同时开启 AOF 持久化，并设置
aof-use-rdb-preamble参数为yes。需要注意的是，混合持久化虽然在一定程度上提高了性能和数据恢复的效率，但也存在一些限制和注意事项。例如，如果 RDB 快照或 AOF 日志的部分损坏或丢失，可能会导致数据恢复的不完整。因此，在实际应用中，仍然需要定期备份 Redis 数据以确保数据的安全性。
5334
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
