在指定的时间间隔，执行数据集的时间点快照
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
将内存数据全部保存到磁盘dump.rdb文加中

1.2 Redis 6 和 7 的配置文件区别

Redis 7

1.3 RDB 的自动触发和手动触发

教程

自动触发

步骤：

Redis7版本，按照redis.conf里配置的save <seconds> <changes>
本次案例5秒2次
修改修改dump文件保存路径
修改dump文件名名称

触发备份条件：5秒内执行两次改变数据的操作。

如何恢复备份：

将备份文件(dump.rdb)移动到redis安装目录并启动服务即可
物理恢复，服务和备份分机隔离

手动触发

Save
- 在主线程中执行会阻塞redis服务器，直到持久化工作完成才能处理其他命令，线上禁止使用
BGSAVE（默认）
- Redis 会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，该触发过程会 fork 一个子进程由子进程复制持久化过程
- lastsave 命令可以获取最后一次成功执行快照的时间

1.4 优势和劣势

优势：

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

劣势：

在一定间隔时间做一次备份，如果redis意外down机，就会丢掉最近一次快照到down机时的数据
内存数量的全量同步，如果数据量过大会导致IO严重影响服务器性能
RDB依赖于主进程的 fork ，在更大的数据集中，这可能会导致服务器请求的瞬间延迟
- fork 的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑

1.5 其他

1. 如何检查修复dump.rdb文件

2. 哪些情况会触发RDB快照

配置文件中默认的快照配置
手动 save/bgsave 命令
执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
执行 shutdown 且没有设置开启 AOF 持久化
主从复制时，主节点自动触发

3. 如何禁用快照

动态所有停止 RDB 保存规则的方法命令(一般不用): redis-cli config set save “”
快照禁用

4. RDB优化配置项详解

🥐2. AOF（Append Only File）

2.1 什么是AOF

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
默认情况下，redis是没有开启AOF的
- 开启AOF 功能需要设置配置： appendonly yes

2.2 AOF 持久化工作流程

2.3 AOF 缓冲区三种写回策略

三种写回策略

always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
everysec 每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
no 操作系统控制写回，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

2.4 AOF 启动/恢复/修复

1. 启动

步骤：

a. 如何开启AOF

在redis.conf文件中进行修改

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

c. aof文件-保存路径

Redis 6 AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置
Redis 7 作了改变 dir/appendirname

d. aof文件-保存名称

Redis 6 有且只有一个
Redis 7 三个文件：base基本文件、incr增量文件、manifest清单文件

3. 正常恢复

恢复1：重启redis然后重新加载，结果OK
恢复2：
- 写入数据进redis，然后flushdb+shutdown服务器
- 新生成了dump和aof
- 备份新生成的aof.bak，然后删除dump/aof
- 再看恢复B重启redis然后重新加载
- 停止服务器，拿出我们的备份修改后再重新启动服务器。

4. 异常恢复

在网络闪断时，aof文件写了错误的指令，使用异常修复命令： redis-check-aof --fix 进行修复

2.5 优劣势

优势

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

劣势

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

2.6 AOF重写机制的自动触发和手动触发

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

自动触发

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

手动触发

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

结论：也就是说AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。

AOF文件重写触发机制:通过 redis.conf配置文件中的auto-aof-rewrite-percentage:默认值为100，以及auto-aof-rewritemin-size: 64mb配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

2.7 AOF重写原理

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

2.8 AOF 优化配置项详解

🥐3. RDB - AOF混合持久化

同时开启两种持久化方式

当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
- 那要不要只使用AOF呢
  - 安特雷兹建议不要
  - 因为RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段

1 开启混合方式设置

设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用

2 RDB+AOF的混合方式---------> 结论：RDB镜像做全量持久化，AOF做增量持久化

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。----》AOF包括了RDB头部+AOF混写

🥐4. 纯缓存模式

同时关闭RDB + AOF

save “”
- 禁用rdb
- 禁用db持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
appendonly no
- 禁用aof
- 禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof生成aof文件

分享到此，感谢大家观看！！！

如果你喜欢这篇文章，请点赞加关注吧，或者如果你对文章有什么困惑，可以私信我。

🏓🏓🏓

Redis持久化详解

Redis持久化简介

为什么需要持久化

Redis持久化有哪些方式？为什么重点学习RDB和AOF？

Redis持久化简介

为什么需要持久化

Redis的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证Redis的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。

Redis持久化有哪些方式？为什么重点学习RDB和AOF？

从严格意义上来讲，Redis提供四种持久化存储方式，RDB、AOF、虚拟内存（VM）、DISKSTORE。

虚拟内存方式，从version 2.4 开始就被官方明确表示不再建议使用，version 3.2 再也找不到任何关于虚拟内存的配置。DISKSTORE 是从version 2.8 提出的一种设想，到目前为止Redis官方也没有在任何版本中明确使用这种方式。最关键的是目前官方文档上能够看到的Redis对持久化存储的明确支持就只有两种方案。第一种是快照（RDB），第二种是AOF日志。

快照是一次全量备份，AOF日志是连续的增量备份。快照是内存数据的二进制序列化形式，在存储上非常紧凑，而 AOF 日志记录的是内存数据修改的指令记录文本。AOF日志在长期的运行中会变得无比庞大，数据库重启会加载AOF日志进行指令重放，这个时间会无比漫长，所以需要定期进行AOF重写，进行瘦身操作。

快照原理

RDB持久化是把当前进程数据生成快照保存到磁盘的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。

触发方式：

触发RDB持久化的方式有两种：手动触发、自动触发。

手动触发：

save命令：阻塞当前redis服务器，直RDB过程完成为止。（如果内存比较大会造成redis长时间阻塞，这样显然不是我们想要的。线上禁止使用）
bgsave命令：redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般很短（和实例数据大小有关系）

自动触发：

除了执行命令手动触发之外，存在以下4种方式自动触发RDB的持久化机制。

使用save相关配置，如“save m n” 表示m秒内数据集存在n次修改时（可以配置多组条件，其中一个达标就触发），自动触发bgsave
主从复制时，从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
执行debug reload命令重写加载redis时
默认情况下执行shutdown命令时，如果没有开启aof持久化则自动执行bgsave

bgsave运作流程

执行bgsave命令，redis父进程判断是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回（生成RDB、AOF要浪费大量磁盘io资源，如果开启aof，磁盘io有可能成为redis的瓶颈）
父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats 命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时（单位ms）（具体阻塞时间和内存大小有关）
父进程fork完成后，bgsave命令返回“Background saving started”信息并不在阻塞父进程，子进程创建RDB文件，根据父进程内存生成的临时快照文件，完成后对原有的文件进行院子替换。执行lastsave命令可以获取最后一次生成RDB的时间
子进程发送信号给父进程表示完成，父进程更新统计信息。

RDB深入理解

内存中的数据同步到硬盘过程中Redis服务收到数据写操作请求，如何保证数据一致性呢？

RDB中的核心思路是Copy-on-Write，来保证在进行快照操作的这段时间，需要压缩写入磁盘上的数据在内存中不会发生变化。Redis在持久化时会调用glibc的函数fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段.这是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。

这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成（一页4k），当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。

子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。

在进行快照操作的这段时间，如果发生服务崩溃怎么办？

很简单，在没有将数据全部写入到磁盘前，这次快照操作都不算成功。如果出现崩溃的情况，将以上一次完整的RDB快照文件作为恢复内存数据的参考。

可以每秒做一次快照吗？

对于快照来说，所谓“连拍”就是指连续地做快照。这样一来，快照的间隔时间变得很短，即使某一时刻发生宕机了，因为上一时刻快照刚执行，丢失的数据也不会太多。但是，这其中的快照间隔时间就很关键了。

所以，要想尽可能恢复数据，t 值就要尽可能小，t 越小，就越像“连拍”。那么，t 值可以小到什么程度呢，比如说是不是可以每秒做一次快照？毕竟，每次快照都是由 bgsave 子进程在后台执行，也不会阻塞主线程。

这种想法其实是错误的。虽然 bgsave 执行时不阻塞主线程，但是，如果频繁地执行全量快照，也会带来两方面的开销：

一方面，频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。
另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了。

那么，有什么其他好方法吗？此时，我们可以做增量快照，就是指做了一次全量快照后，后续的快照只对修改的数据进行快照记录，这样可以避免每次全量快照的开销。这个比较好理解。

RDB的优缺点

优点：

RDB是一个紧凑压缩的二进制文件，某个时间点的上的快照。适用于备份、全量复制等场景
redis加载RDB恢复数据远快于AOF的方式

缺点：

RDB方式数据没办法做到实时持久化/秒级持久化。
bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
RDB文件使用特定二进制格式保存，没有可读性
Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

AOF日志原理

AOF的主要作用是解决了数据持久化的实时性。Redis先执行命令，把数据写入内存，然后才记录日志。AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录，这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。

AOF日志采用写后日志，即先写内存，后写日志。

为什么采用写后日志？

Redis要求高性能，采用写后日志有两方面的好处？

避免额外的检查开销：Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。
不会阻塞当前的写操作

但这种方式存在潜在风险：

如果命令执行完成，写日志之前宕机了，会丢失数据。
主线程写磁盘压力大，导致写盘慢，阻塞后续操作。

如何实现AOF

AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

命令追加当AOF持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。
文件写入和同步关于何时将 aof_buf 缓冲区的内容写入AOF文件中，Redis提供了三种写回策略：

Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

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

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

三种写回策略的优缺点

上面的三种写回策略体现了一个重要原则：trade-off，取舍，指在性能和可靠性保证之间做取舍。

关于AOF的同步策略是涉及到操作系统的 write 函数和 fsync 函数的，在《Redis设计与实现》中是这样说明的：

为了提高文件写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。这样的操作虽然提高了效率，但也为数据写入带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失。为此，系统提供了fsync、fdatasync同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

深入理解AOF重写

Redis在长期运行过程中，AOF的日志会越来越大，如果实例宕机重启，重放整个AOF日志会非常耗时，导致Redis长时间无法对外提供服务。为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写机制来对AOF日志瘦身。

AOF重写机制

Redis通过创建一个新的AOF文件来替换现有的AOF，新旧两个AOF文件保存的数据相同，但新AOF文件没有了冗余命令。

AOF重写会阻塞吗？

AOF重写过程是由后台进程bgrewriteaof来完成的。主线程fork出后台的bgrewriteaof子进程，fork会把主线程的内存拷贝一份给bgrewriteaof子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

所以aof在重写时，在fork进程时是会阻塞住主线程的。

AOF日志何时会重写？

有两个配置项控制AOF重写的触发：

auto-aof-rewrite-min-size:表示运行AOF重写时文件的最小大小，默认为64MB。

auto-aof-rewrite-percentage:这个值的计算方式是，当前aof文件大小和上一次重写后aof文件大小的差值，再除以上一次重写后aof文件大小。也就是当前aof文件比上一次重写后aof文件的增量大小，和上一次重写后aof文件大小的比值。

重写日志时，有新数据写入咋整？

重写过程总结为：“一个拷贝，两处日志”。在fork出子进程时的拷贝，以及在重写时，如果有新数据写入，主线程就会将命令记录到两个aof日志内存缓冲区中。如果AOF写回策略配置的是always，则直接将命令写回旧的日志文件，并且保存一份命令至AOF重写缓冲区，这些操作对新的日志文件是不存在影响的。（旧的日志文件：主线程使用的日志文件，新的日志文件：bgrewriteaof进程使用的日志文件）

而在bgrewriteaof子进程完成会日志文件的重写操作后，会提示主线程已经完成重写操作，主线程会将AOF重写缓冲中的命令追加到新的日志文件后面。这时候在高并发的情况下，AOF重写缓冲区积累可能会很大，这样就会造成阻塞，Redis后来通过Linux管道技术让aof重写期间就能同时进行回放，这样aof重写结束后只需回放少量剩余的数据即可。

最后通过修改文件名的方式，保证文件切换的原子性。

在AOF重写日志期间发生宕机的话，因为日志文件还没切换，所以恢复数据时，用的还是旧的日志文件。

总结操作

主线程fork出子进程重写aof日志
子进程重写日志完成后，主线程追加aof日志缓冲
替换日志文件

主线程fork出子进程的是如何复制内存数据的？

fork采用操作系统提供的写时复制（copy on write）机制，就是为了避免一次性拷贝大量内存数据给子进程造成阻塞。fork子进程时，子进程时会拷贝父进程的页表，即虚实映射关系（虚拟内存和物理内存的映射索引表），而不会拷贝物理内存。这个拷贝会消耗大量cpu资源，并且拷贝完成前会阻塞主线程，阻塞时间取决于内存中的数据量，数据量越大，则内存页表越大。拷贝完成后，父子进程使用相同的内存地址空间。

但主进程是可以有数据写入的，这时候就会拷贝物理内存中的数据。如下图（进程1看做是主进程，进程2看做是子进程）：

在主进程有数据写入时，而这个数据刚好在页c中，操作系统会创建这个页面的副本（页c的副本），即拷贝当前页的物理数据，将其映射到主进程中，而子进程还是使用原来的的页c。

在重写日志整个过程时，主线程有哪些地方会被阻塞？

fork子进程时，需要拷贝虚拟页表，会对主线程阻塞。
主进程有bigkey写入时，操作系统会创建页面的副本，并拷贝原有的数据，会对主线程阻塞。
子进程重写日志完成后，主进程追加aof重写缓冲区时可能会对主线程阻塞。

为什么AOF重写不复用原AOF日志？

两方面原因：

父子进程写同一个文件会产生竞争问题，影响父进程的性能。
如果AOF重写过程中失败了，相当于污染了原本的AOF文件，无法做恢复数据使用。

Redis4.0 混合持久化

重启Redis时，很少使用快照方式恢复内存状态，因为会丢失大量数据，使用AOF日志重放，比快照方式慢很多，实例很大的时候，启动很花费时间。

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。

Redis4.0使用新的持久化选项——混合持久化。在重启的时候，可以先加载RDB内容，然后在重放AOF日志，效率得到很大提升。这里AOF日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量AOF日志。通常这部分AOF日志很小。

性能与实践

通过上面的分析，我们都知道RDB的快照、AOF的重写都需要fork，这是一个重量级操作，会对Redis造成阻塞。因此为了不影响Redis主进程响应，我们需要尽可能降低阻塞。

降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写；
控制Redis最大使用内存，防止fork耗时过长；
合理配置Linux的内存分配策略，避免因为物理内存不足导致fork失败。

以上是关于Redis7Redis7 持久化（重点：RDB与AOF重写机制）的主要内容，如果未能解决你的问题，请参考以下文章