Redis 持久化

持久化结构图示

官网地址：https://redis.io/docs/management/persistence/

 

RDB (Redis DataBase)

RDB（Redis 数据库）：RDB 持久性以指定的时间间隔执行数据集的时间点快照。

是什么

在指定的时间间隔，执行数据集的时间点快照。

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

能干嘛

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里。

Redis的数据都在内存中，保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，一锅端。

RDB保存的是dump.rdb文件。

案例演示

配置文件

Redis6.0.16以下配置

Redis6.2以及Redis-7.0.0

操作步骤

1、自动触发

a、Redis7版本，按照redis.conf里配置的save <seconds> <changes>

b、本次案例5秒2次修改

c、修改dump文件保存路径

默认路径

自定义修改的路径且可以进入redis里用config get dir获取目录

d、修改dump文件名称

e、触发备份

• 第1种情况

  

• 第2种情况

f、如何恢复

*  将备份文件(dump.rdb)移动到redis安装目录并启动服务即可

*  备份成功后故意用flushdb清空redis,看看是否可以恢复数据

结论：执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义。

*  物理恢复，一定服务和备份分机隔离

备注：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了。 

2、手动触发

触发命令：save 和 bgsave

save：

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

bgsave：

  

Redis会在后台异步进行快照操作，不阻塞，快照同时还可以响应客户端请求，该触发方式会fok一个子进程由子进程复制持久化过程。

 

Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。 

LASTSAVE：可以通过lastsave命令获取最后一次成功执行快照的时间。

优势

官网说明：

 总结：

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

劣势

官网说明：

总结：

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

数据丢失案例：

步骤一：正常录入数据

步骤二：killl -9故意模拟意外down次

步骤三：redis重启恢复，查看数据是否丢失

如何检查修复dump.rdb文件

哪些情况会触发RDB快照

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

如何禁用快照

1、动态所有停止 RDB 保存规则的方法：redis-cli config set save ""

2、快照禁用：

 RDB优化配置项详解

主要是配置文件SNAPSHOTTING模块。

这三个前面有介绍：

save <seconds> <changes>

dbfilename

dir

stop-writes-on-bgsave-error

默认yes，如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的写请求。

rdbcompression

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

rdbchecksum

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

rdb-del-sync-files

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

总结

 

AOF (Append Only File)

是什么

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

默认情况下，redis 是没有开启AOF(append only file)的
开启 AOF 功能需要设置配置：appendonly yes

AOF 保存的是 appendonly.aof 文件

能干嘛

 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配置 

1、如何开启AOF

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

3、AOF文件-保存路径

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

Redis7之后最新 ：最终路径（dir + appenddirname）

4、AOF文件-保存名称

Redis6：有且仅有一个

Redis7.0 Multi Part AOF的设计：（由1个变为3个）

base            基本文件
incr              增量文件
manifest      清单文件 

Redis7.0 config中对应的配置项：

正常恢复

1、启动：设置Yes

修改默认的appendonly no，改为 yes

2、写操作继续，生成aof文件到指定的目录

3、恢复1：重启redis:然后重新加载，结果OK

4、恢复2：

a、写入数据进redis，然后flushdb+shutdown服务器

b、新生成了dump和aof

c、备份新生成的aof.bak，然后删除dump/aof再看恢复

d、重启redis然后重新加载试试？？？

e、停止服务器，拿出我们的备份修改后再重新启动服务器看看

异常恢复

1、故意乱写正常的AOF文件，模拟网络闪断文件写error

2、重启Redis之后就会进行AOF文件的载入，发现启动都不行

3、异常修复命令：redis-check-aof --fix  进行修复

注意：一定要加 --fix 

4、重新OK

优势

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

劣势

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。

aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。

AOF重写机制

是什么？

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集或者可以手动使用命令 bgrewriteaof 来重写。

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

触发机制

官网默认配置如下：

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

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

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

触发方式可分为自动触发和手动触发，自动触发就是达到条件后触发，手动触发就是输入命令触发。

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

手动触发：客户端向服务器发送 bgrewriteaof 命令。

案例说明

需求说明：

启动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文件的内容压缩，只保留可以恢复数据的最小指令集。 

步骤：

1、前期配置准备

a、开启AOF：

b、重写峰值修改为1k

c、关闭混合，设置为no

d、删除之前的全部aof和rdb,清除干扰项

2、自动触发案例01

a、完成上述正确配置，重启redis服务器，执行 set k1 v1 查看aof文件是否正常

b、查看三大配置文件

c、k1不停1111111暴涨

d、重写触发

3、手动触发案例02

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

4、结论

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

重写原理

1：在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

2：与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

3：当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中

4：当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中

5：重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

A0F优化配置项详解

主要是配置文件APPEND ONLY MODE模块

总结

 

RDB-AOF混合持久化

官网建议

RDB vs AOF

官方文档：AOF和RDB持久性可以同时启用，没有任何问题。如果AOF在启动时启用，Redis将加载AOF，即具有更好耐久性的文件。 

数据恢复顺序和加载流程：在同时开启rdb和aof持久化时，重启时只会加载aof文件，不会加载rdb文件。

你怎么选？用那个？

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。

同时开启两种持久化方式

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

推荐方式：RDB+AOF混合方式

结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。

1、开启混合方式设置

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

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

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

 

纯缓存模式

做法：同时关闭RDB+AOF

1、禁用RDB

禁用rdb持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件

配置文件修改：save ""

2、禁用AOF

禁用aof持久化模式下，我们仍然可以使用命令bgrewriteaof性成aof文件

配置文件修改：appendonly no