Redis持久化

一、redis持久化说明

Redis 是一款基于内存的非关系型数据库，其是将数据全部存储在内存中。但是如果 Redis 服务器出现某些意外情况，比如宕机或者断电等，那么内存中的数据就会全部丢失。因此必须有一种机制能够保证 Redis 储存的数据不会因故障而丢失，这就是 Redis 的数据持久化机制。数据的持久化存储是 Redis 的重要特性之一，它能够将内存中的数据保存到本地磁盘中，实现对数据的持久存储。这样即使在服务器发生故障之后，也能通过本地磁盘对数据进行恢复。

Redis 提供了一系列持久性选项。其中包括：

  • RDB（Redis 数据库）：RDB 持久性按指定的时间间隔执行数据集的时间点快照。
  • AOF（仅追加文件）：AOF 持久性记录服务器收到的每个写入操作。然后可以在服务器启动时再次重播这些操作，重建原始数据集。命令的记录格式与 Redis 协议本身相同。
  • 无持久性：可以完全禁用持久性。这有时在缓存时使用。
  • RDB + AOF：您还可以在同一实例中组合 AOF 和 RDB。

参考网站：https://redis.io/docs/management/persistence/，截图如下：

二、RDB快照模式

2.1.RDB快照模式原理

RDB 即快照模式，它是 Redis 默认的数据持久化方式，它会将数据库的快照保存在 dump.rdb 这个二进制文件中。

  • 所谓“快照”就是将内存数据以二进制文件的形式保存起来。
  • 需要知道的是 Redis 是单线程的，也就说一个线程要同时负责多个客户端套接字的并发读写，以及内存数据结构的逻辑读写。Redis 服务器不仅需要服务线上请求，同时还要备份内存快照。在备份过程中 Redis 必须进行文件 IO 读写，而 IO 操作会严重服务器的性能。那么如何实现既不影响客户端的请求，又实现快照备份操作呢，这时就用到了多进程。
  • Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化操作。
  • RDB 实际上是 Redis 内部的一个定时器事件，它每隔一段固定时间就去检查当前数据发生改变的次数和改变的时间频率，看它们是否满足配置文件中规定的持久化触发条件。当满足条件时，Redis 就会通过操作系统调用 fork() 来创建一个子进程，该子进程与父进程享有相同的地址空间。
  • Redis 通过子进程遍历整个内存空间来获取存储的数据，从而完成数据持久化操作。注意，此时的主进程则仍然可以对外提供服务，父子进程之间通过操作系统的 COW 机制实现了数据段分离，从而保证了父子进程之间互不影响。

2.2.RDB持久化触发策略

RDB 持久化提供了两种触发策略：一种是自动触发，另一种是手动触发。

2.2.1.自动触发策略

1)自动触发策略设置

自动触发策略，是指 Redis 在指定的时间内，数据发生了多少次变化时，会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中，修改redis.conf ,如下所示：

上图所示， save m n 的含义是在时间 m 秒内，如果 Redis 数据至少发生了 n 次变化，那么就自动执行BGSAVE命令。配置策略说明如下：

  • save 5 2 表示在 5秒内，至少更新了 2条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
  • save 900 1 表示在 900 秒内，至少更新了 1 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
  • save 300 10 表示在 300 秒内，至少更新了 10 条数据，Redis 自动触 BGSAVE 命令，将数据保存到硬盘。
  • save 60 10000 表示 60 秒内，至少更新了 10000 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。

上面的策略可以有多个，如果有多个的时候，上述四个条件任意满足一个，服务器就会自动执行BGSAVE命令（为了后面演示方便，我就只放开了第一个策略）。当然可以根据实际情况自己调整触发策略。

注意：每次创建 RDB 文件之后，Redis 服务器为实现自动持久化而设置的时间计数和次数计数就会被清零，并重新开始计数，因此多个策略的效果不会叠加。

2)修改dump文件的保存路径

创建路径，用来保存dump文件：

mkdir -p /myredis/dumpfiles

在redis.conf文件中修改的dump文件生成后的存放路径，这样便于后期去查看文件信息，修改如下：

3)修改dump文件名称

在redis.conf文件中修改生成的文件名称,如下：

4)触发备份

在5秒种内操作2次，让其触发 BGSAVE保存操作

上述设置的5s内操作两次，这个条件只要满足其一即可，模拟在k3和k4的创建两次操作间隔时间超过5s，会发现k3刚刚创建，文件大小无变化，超过5s，再次创建k4，发现文件变大

5）通过持久化文件恢复数据

 需要注意执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，回复也是无意义

在redis中可以通过 下面命令查看持久化文件存放路径：

127.0.0.1:6379> CONFIG GET DIR
1) "DIR"
2) "/myredis/dumpfiles"
127.0.0.1:6379>

案例如下：

Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379>
# 触发规则，保存到rdb文件
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379>
# 出现rdb文件
[root@localhost dumpfiles]# ls
dump6379.rdb
# 将生成的rdb文件赋值到、tmp目录下一份
[root@localhost dumpfiles]# cp dump6379.rdb /tmp
[root@localhost dumpfiles]# cd /tmp
[root@localhost tmp]# ls
dump6379.rdb  systemd-private-32436087de684bcfa725b6a9c01d7b28-vmtoolsd.service-5Ewmwy
[root@localhost tmp]#
[root@localhost tmp]# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> keys *
1) "k2"
2) "k1"
# 执行flushall/flushdb、SHUTDOWN命令也会产生dump.rdb文件，但里面是空的，无意义
127.0.0.1:6379> FLUSHALL
OK
# 执行FLUSALL情况后查看会情况内容，查看信息为空
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> SHUTDOWN
not connected> quit
[root@localhost tmp]# ls
dump6379.rdb  systemd-private-32436087de684bcfa725b6a9c01d7b28-vmtoolsd.service-5Ewmwy
[root@localhost tmp]# cd /myredis/dumpfiles/
# 这个是空的，没有意义
[root@localhost dumpfiles]# ls
dump6379.rdb
# 删除掉这个空的rdb
[root@localhost dumpfiles]# rm -rf dump6379.rdb
# 在将之前保存的rdb文件复制
[root@localhost dumpfiles]# cp /tmp/dump6379.rdb .
[root@localhost dumpfiles]# ls
dump6379.rdb、
# 重新重启redis
[root@localhost dumpfiles]# redis-server /myredis/redis.conf
[root@localhost dumpfiles]# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379>、
# 查看，发现之前的数据已经回复过来了
127.0.0.1:6379> keys *
1) "k1"
2) "k2"

2.2.2.手动触发策略

手动触发是通过 SAVAE 命令或者 BGSAVE 命令将内存数据保存到磁盘文件中。如下所示：

# 查看当前文件大小为107
[root@localhost dumpfiles]# ll
总用量 4
-rw-r--r--. 1 root root 107 3月   6 16:28 dump6379.rdb
[root@localhost dumpfiles]# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379>
# 新建键值对
127.0.0.1:6379> set k5 v5
OK
127.0.0.1:6379>
# 再次查看文件大小没变化
[root@localhost dumpfiles]# ll
总用量 4
-rw-r--r--. 1 root root 107 3月   6 16:28 dump6379.rdb
[root@localhost dumpfiles]# redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# 使用BGSAVE手动触发
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>
# 再次查看文件大小变为114，表示手动触发成功
[root@localhost dumpfiles]# ll
总用量 4
-rw-r--r--. 1 root root 114 3月   6 17:00 dump6379.rdb
[root@localhost dumpfiles]#

上述命令BGSAVE从后台执行数据保存操作，其可用性要优于执行 SAVE 命令。生产环境只能使用BGSAVE，SAVE绝对不允许使用，因为SAVE 命令会阻塞 Redis 服务器进程，直到 dump.rdb 文件创建完毕为止，在这个过程中，服务器不能处理任何的命令请求。而
BGSAVE命令是非阻塞式的，所谓非阻塞式，指的是在该命令执行的过程中，并不影响 Redis 服务器处理客户端的其他请求。这是因为 Redis 服务器会 fork() 一个子进程来进行持久化操作（比如创建新的 dunp.rdb 文件），而父进程则继续处理客户端请求。当子进程处理完后会向父进程发送一个信号，通知它已经处理完毕。此时，父进程会用新的 dump.rdb 文件覆盖掉原来的旧文件。因为SAVE命令无需创建子进程，所以执行速度要略快于BGSAVE命令，但是SAVE命令是阻塞式的，因此其可用性欠佳，如果在数据量较少的情况下，基本上体会不到两个命令的差别，不过仍然建议您使用 BGSAVE命令。

可以通过LASTSAVE 命令用于查看 BGSAVE 命令是否执行成功。如下：

127.0.0.1:6379>
# 获取最后一次执行成功执行快照的时间
127.0.0.1:6379> LASTSAVE
(integer) 1678093233
127.0.0.1:6379>
[root@localhost dumpfiles]#
# 将获取的时间戳转换为年月日时分秒
[root@localhost dumpfiles]# date -d @1678093233
2023年 03月 06日 星期一 17:00:33 CST

2.3.RDB持久化的优劣势

  • 在 RDB 持久化的过程中，子进程会把 Redis 的所有数据都保存到新建的 dump.rdb 文件中，会消耗大量的资源和时间。因此 Redis 服务器不能过于频繁地创建 rdb 文件，否则会严重影响服务器的性能。
  • RDB 持久化的最大不足之处在于，最后一次持久化的数据可能会出现丢失的情况。例如，在 持久化进行过程中，服务器突然宕机了，这时存储的数据可能并不完整，比如子进程已经生成了 rdb 文件，但是主进程还没来得及用它覆盖掉原来的旧 rdb 文件，这样就把最后一次持久化的数据丢失了。
  • RDB 数据持久化适合于大规模的数据恢复，并且还原速度快，如果对数据的完整性不是特别敏感（可能存在最后一次丢失的情况），那么 RDB 持久化方式非常合适。

2.4.RDB检查修复dump.rdb文件

有时候一些操作，会导致dump.rdb文件出现损坏，这时候就可以通过 redis-check-rdb 命令修复，如下所示：

# 进入到redis的安装路径
[root@localhost dumpfiles]# cd /usr/local/bin/
[root@localhost bin]# ll
总用量 21536
-rwxr-xr-x. 1 root root  5198864 2月  24 13:04 redis-benchmark
lrwxrwxrwx. 1 root root       12 2月  24 13:04 redis-check-aof -> redis-server
lrwxrwxrwx. 1 root root       12 2月  24 13:04 redis-check-rdb -> redis-server
-rwxr-xr-x. 1 root root  5416288 2月  24 13:04 redis-cli
lrwxrwxrwx. 1 root root       12 2月  24 13:04 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 11430496 2月  24 13:04 redis-server
# 使用redis-check-rdb修复/myredis/dumpfiles/dump6379.rdb文件
[root@localhost bin]# redis-check-rdb /myredis/dumpfiles/dump6379.rdb
[offset 0] Checking RDB file /myredis/dumpfiles/dump6379.rdb
[offset 26] AUX FIELD redis-ver = '7.0.8'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1678093233'
[offset 67] AUX FIELD used-mem = '1005304'
[offset 79] AUX FIELD aof-base = '0'
[offset 81] Selecting DB ID 0
[offset 114] Checksum OK
[offset 114] \o/ RDB looks OK! \o/
[info] 3 keys read
[info] 0 expires
[info] 0 already expired
[root@localhost bin]# ^C

2.5.触发RDB持久化的场景总结

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

2.6.如何禁用RDB持久化

有时候我们需要禁用RDB持久化，redis中提供了两种方式：通过命令禁止RDB、通过修改配置文件的方式

1.通过命令禁止RDB

停止RDB保存规则的方法：

redis-cli config set save ""

2.通过修改配置文件的方式（推荐）

快照RDB，修改redis.conf：

2.7.RDB持久化优化参数

在配置文件redis.conf中修改文件中的一些参数可以对齐做一下优化设置：

2.7.1.stop-writes-on-bgsave-error

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

2.7.2.rdbcompression

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

2.7.3.rdbchecksum

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

2.7.4.rdb-del-sync-files

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

三、AOF模式

3.1.AOF模式说明

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

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

appendonly yes

3.2.AOF持久化模式工作流程

如上图所示，工作步骤如下：

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

3.2.AOF持久化缓存区三种写入策略

三种写回策略说明如下：

  1. Always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘。
  2. everysec（推荐）：每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘。
  3. no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

三种会写机制对比：

回写策略 回写方式 优势 劣势
Always 同步写回 可靠性较高，数据基本不会丢失 每个命令都要频繁的写入磁盘，性能影响较大
everysec 每秒写回 性能适中 宕机是丢失1秒内的数据
no 操作系统控制写回 性能好 宕机时丢失的数据较多

3.3.AOF持久化配置

3.3.1.配置文件说明(6 和7之间存在区别)

开启aof，在redis.conf中修改如下配置为yes即可

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

AOF持久化文件保存路径

redis6中AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的 dir 配置实现的，而在redis7之后的，则在需要在appenddirname参数单独设置，如下图：

为了方便管理，这里我将RDB的路径重新设置保存在/myredis目录下：

 然后将AOF的持久化文件保存路径配置到 /myredis/appendonlydir 目录下，实际上就是上述dir对应的路径+appendonlydir

AOF持久化文件名介绍

在redis6中生成的持久化文件只有一个：appendonly.aof，而在redis7中采用了Multi Part AOF的设计，持久化文件就变为了3个，分别如下：

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

3.3.2.正常的数据恢复

设置启动AOF持久化

修改redis.conf中的配置项，默认的appendonly no，改为yes即可

登录redis进行写操，生成aof文件到指定的目录

重启redis然后重新加载，结果还是存在，则表示AOF持久化成功，可以恢复数据

测试redis服务器宕机的数据持久化效果，先删除掉RDB的持久化文件，在将AOF的持久化文件复制一份到/tmp路径下面，也将其删除掉切记只删除appendonlydir下面的三个文件，不要删除这个目录本身，如下：

登录redis客户端，然后使用flushdb和shutdown命令清除redis服务器数据

重启redis，查看数据为空

这时候将复制到 /tmp/appendonlydir目录中的持久化文件重新拷贝到/myredis/appendonlydir目录下

再次重启redis，即可看到数据又可以恢复回来

3.3.3.异常的数据恢复

故意写乱正常的AOF文件，模拟网络闪断文件写error操作：

重启服务器，然后再次启动redis,会发现启动也是报错

通过异常修复命令：redis-check-aof --fix 进行修复文件

再次重启redis，发现启动正常，可以查到数据

3.4.AOP持久化优劣势说明

优势：

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

劣势

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

3.5.AOF重写机制

3.5.1.AOF重写机制简述

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

3.5.2.触发机制

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

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

3.5.2.1.自动触发机制案例演示

这里我们去验证启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。先需要开启AOF持久化

修改重写峰值为1k，写入信息超过1k就会触发重写

关闭混合，设置为no，就是设置只启用AOF持久化，避免干扰

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

查看三大配置文件

不断的修改k12的值，多次修改，让AOF文件暴涨，突破之前设置的峰值1k

然后触发重写机制

打开查生成的文件，发现只保存最后一次写入的信息

 

3.5.2.2.手动触发机制案例演示

 客户端向服务器发送bgrewriteaof命令，手工触发：

3.5.2.3.结论

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

3.5.3.AOF持久化机制原理说明

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

3.6.AOF持久化配置项详解

配置文件APPEND ONLY MODE模块中可以配置的项说明：

配置指令 配置含义 示例
appendonly 是否可以AOF持久化配置 appendonly yes
appendfilename 保存数据的AOF文件名称 appendfilename "appendonly.aof"
appendfsync 数据同步模式默认为everysec appendfsync everysec
no-appendfsync-on-rewrite
AOF重写期间是否同步 no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage

auto-aof-rewrite-min-size

重写触发配置

文件重新策略

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

四、RDB和AOF混合持久化

4.1.RDB-AOF混合持久化说明

RDB 和 AOF 持久化各有利弊，RDB 可能会导致一定时间内的数据丢失，而 AOF 由于文件较大则会影响 Redis 的启动速度，为了能同时使用 RDB 和 AOF 各种的优点，Redis 4.0 之后新增了混合持久化的方式。在开启混合持久化的情况下，AOF 重写时会把 Redis 的持久化数据，以 RDB 的格式写入到 AOF 文件的开头，之后的数据再以 AOF 的格式化追加的文件的末尾。

混合持久化的数据存储结构如下图所示：

4.2.RDB模式对比AOF模式

4.2.1. RDB

RDB文件本质上是一份内存快照，保存了创建RDB文件那个时间点的redis全量数据。具有数据文件小创建、恢复快的优点，但是由于快照的特性无法保存创建RDB之后的增量数据。

4.2.2.AOF

AOF文件本质上是一份执行日志保存所有对redis进行更改的命令，增量数据也就随命令写入AOF文件刷盘的策略，由配置项appendfsync控制可以选择"everysec"或"always"。AOF文件基本上是human-readable的文本，所以其体积相对较大，在从AOF文件恢复数据时就是做日志回放执行AOF文件中记录的所有命令，所以相对RDB而言恢复耗时较长。随着redis的运行AOF文件会不断膨胀，由aofrewrite机制来防止磁盘空间

4.3.RDB-AOF混合持久化的加载流程

混合持久化的加载流程如下：

  1. 判断是否开启 AOF 持久化，开启继续执行后续流程，未开启执行加载 RDB 文件的流程；
  2. 判断 appendonly.aof 文件是否存在，文件存在则执行后续流程；
  3. 判断 AOF 文件开头是 RDB 的格式, 先加载 RDB 内容再加载剩余的 AOF 内容；
  4. 判断 AOF 文件开头不是 RDB 的格式，直接以 AOF 格式加载整个文件。

AOF 加载流程图如下图所示：

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

4.4.开启RDB-AOF混合持久化

4.4.1.开启混合持久化

查询是否开启混合持久化可以使用 config get aof-use-rdb-preamble 命令，执行结果如下图所示：

其中 yes 表示已经开启混合持久化，no 表示关闭，Redis 7.0 默认值为 yes。 我的由于之前为了演示改为了no，如果是其他版本的 Redis 首先需要检查一下，是否已经开启了混合持久化，如果关闭的情况下，可以通过以下两种方式开启：

  • 通过命令行开启
  • 通过修改 Redis 配置文件开启

4.4.2.通过命令行开启混合模式（本次有效）

使用命令 config set aof-use-rdb-preamble yes 执行结果如下图所示：

 注意：命令行设置配置的缺点是重启 Redis 服务之后，设置的配置就会失效。

4.4.3.通过修改 Redis 配置文件开启（永久有效）

在 Redis 的根路径下找到 redis.conf 文件，把配置文件中的 aof-use-rdb-preamble no 改为 aof-use-rdb-preamble yes 如下图所示：

五、纯缓存模式

redis还有一种模式，不做持久化，只需要直接关闭掉RDB和AOF模式，单纯的采用缓存方式，

5.1.禁用RDB持久化

在redis.conf配置文件修改如下配置：

save ""

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

5.2.禁用AOF持久化

在redis.conf配置文件修改如下配置：

appendonly no

注意：禁用aof持久化模式下，仍然可以使用命令bgrewriteaof生成aof文件

posted @ 2023-03-03 18:09  酒剑仙*  阅读(240)  评论(0)    收藏  举报