基本概述

持久化：在 Redis 当中，将某一时刻内存中的数据保存到磁盘的过程，我们称为 「持久化」 或 「快照持久化」。默认情况下，保存的文件名称为 dump.rdb。当 Redis 实例启动后，会自动读取 dump.rdb 中的数据并将其加载到内存当中进行数据的恢复。如果要完全禁用 RDB 持久化，可在配置文件这样配置——save ""

Q：为什么需要持久化呢？

Redis 是一种 KV 型的 NoSQL，是基于内存的缓存数据库，众所周知，内存中的数据在断电之后就会丢失，这对于生产环境是灾难性的，因此 Redis 需要持久化。有了持久化，不管是断电、宕机、重启或其他不可控因素，都可以将缓存数据永久写入到磁盘当中，等待下次启动时，直接从磁盘中读取已经缓存的数据。

cache（缓存）：指把读取出来的数据保存在内存当中，当再次读取相同数据时，不用读取硬盘而直接从内存当中读取，加速数据的读取过程。

在 Redis 当中，你可以根据需要选择特定的持久化方案：

• RDB（Redis Database） – 默认方案，文件名默认为 dump.rdb。这种方案类似于照相机拍照记录的效果，其通过指定的时间间隔给 Redis 中的内存数据「拍照」（即快照），将这一时刻的数据和状态以文件的形式写入到磁盘中，这个 RDB 文件即 dump.rdb。触发写入到磁盘的动作可以是自动的（即配置文件中的参数），也可以是手动的（Redis 当中的 save 或 bgsave 命令）。
• AOF（Append Only File） – AOF 是以日志追加的形式记录每个写操作（读操作不记录），当 Redis 实例重启后，会从头到尾读取日志文件的内容并进行数据的重建。
• RDB + AOF – 在同一个实例当中同时使用 RDB 和 AOF 方案。需要注意！AOF 的优先级更加高，会优先加载 AOF 文件。
• No persistence – 禁止 redis 开启持久化

配置文件相关

原先在《Redis基础篇07 — 配置文件详解（二）》中提到了部分内容，这里可以再回顾下。

Shell > ls  -l  /usr/local/redis/conf/
总用量 112
-rw-rw-r-- 1 root root 107592 10月  4 21:12 redis.conf

这个配置文件将整个配置参数划分成了几个部分，其中与持久化相关的是下面这两个部分。

SNAPSHOTTING 部分

默认配置文件中有这样一行注释行——save 3600 1 300 100 60 10000，等价于三行：

• save 3600 1 // 1小时轮询检查一次，如果至少有 1 次 key 变更，则将内存中数据保存到磁盘中
• save 300 100 // 5分钟轮询检查一次，如果至少有 100 次 key 变更，则将内存中数据保存到磁盘中
• save 60 10000 /// 1分钟轮询检查一次， 如果至少有 10000 次 key 变更，则将内存中数据保存到磁盘中

• stop-writes-on-bgsave-error yes // 如果 redis 执行 bgsave「持久化」失败（常见如内存不足），是否不再接受 客户端 写入数据。
• rdbcompression yes // 持久化是否开启对字符串的压缩（使用 LZF 压缩），开启后会占用一部分的 CPU 资源，不开启，则「持久化」的文件大小会较大
• rdbchecksum yes // 是否开启对 rdb 文件的校验，开启后会使文件更耐损坏，但在保存以及加载时会造成性能损失（约10%）
• dbfilename dump.rdb // db 的文件名称
• rdb-del-sync-files no // 在未开启 redis 「持久化」的实例中，是否删除 副本 所使用的 .rdb 文件。默认情况下为 no，但在有些情况下（比如主从复制中），需要尽快删除 主 服务器上提供给 副本 服务器的 .rdb 文件。请注意！此参数仅在禁用 RDB 和 AOF 的 Redis 「持久化」实例中适用，否则该参数会被忽略。
• dir /usr/local/redis/DB/ // 持久化所在的目录

APPEND ONLY MODE 部分

RDB 方案在许多场景中已经足够使用了，但可能会丢失几分钟的数据（这取决于 SNAPSHOTTING 部分 save 是如何配置的）

AOF 是以日志追加的形式记录每个写操作（读操作不记录），当 Redis 实例重启后，会从头到尾读取日志文件的内容并进行数据的重建。

默认配置参数如下：

• appendonly no // 是否开启 AOF 。同时开启 AOF 和 RDB 是没有问题的，但是当 Redis 实例重启时，会优先使用 AOF 进行数据的重建
• appendfilename "appendonly.aof" // AOF 文件名的前缀定义
• appenddirname "appendonlydir" // AOF 目录定义，这个目录存放在 dir 参数定义的目录下，在我的环境中，即 /usr/local/redis/DB/appendonlydir/ 目录位置
• appendfsync everysec // 同步频率为每秒，即持久化到磁盘上，可能会丢失一秒的数据。值还可以是 no 和 always

随着时间的推移， AOF 日志文件越来越大，Redis 采用了一种叫做 「重写」 的机制来缓解存储和恢复的压力。

• no-appendfsync-on-rewrite no //当主线程进行写操作和子进程进行重写操作时，两者都会操作磁盘，可能会出现阻塞的情况。设置为 no，表示不会丢失数据但是要忍受阻塞问题。为了数据的安全性，推荐配置为 no
• auto-aof-rewrite-percentage 100 // 触发 Redis 重写 AOF 文件的条件之一，这里的 100 意思是 100%，也就是说，它会对比上一次重写 AOF 的文件大小，如果当前 AOF 文件的大小大于指定的百分比，则触发重写
• auto-aof-rewrite-min-size 64mb // 触发重写的条件之一。当前触发重写的最小文件大小。请注意！只有两个条件同时满足，才会触发重写。
• aof-load-truncated yes // 当 Redis 突然崩溃时，AOF 文件会出现被截断的情况。如果设置为 yes，表示 Redis 加载截断的 AOF 文件并通知用户该事件；如果为 no ，则拒绝启动，在重启 Redis 之前需要使用 redis-check-aof 命令修复 AOF 文件。
• aof-use-rdb-preamble yes // 是否开启混合持久化。如果开启，需要首先将 appendonly 设置为 yes ，这将导致 AOF 重写文件同时包含 RDB 格式和 AOF 格式。
• aof-timestamp-enabled no // 是否开启时间戳（在 AOF 文件中记录时间戳注释），7.0 版本之后的 Redis 可以支持 AOF 的时间戳，换言之，你可以基于时间点来恢复数据。小心！这会改变 AOF 文件的格式。

RDB 持久化方案

您可以通过 info 命令查看 RDB 持久化方面的信息：

192.168.100.3:6379> info
...
# Persistence
loading:0  // 是否正在加载 RDB 文件的内容
async_loading:0   // 在 redis 7.0  中添加。当前为旧数据服务时异步加载数据集，这意味着您的 repl-diskless-load 开启且被设置为 swapdb
current_cow_peak:0  // fork 出的子进程在复制写入到内存当中的峰值大小（以字节为单位）
current_cow_size:0  // fork 出的子进程在复制写入到内存当中的大小（以字节为单位）
current_cow_size_age:0 // current_cow_size 值的寿命，以秒为单位
current_fork_perc:0.00  // fork 的进度百分比，对于 RDB 和 AOF，它是指 current_save_keys_processed 占current_save_keys_total 的百分比
current_save_keys_processed:0 // 当前保存任务处理的 key 数
current_save_keys_total:0  // 当前保存任务开始时的 key 数，即操作处理的总 key 数
rdb_changes_since_last_save:0  // 上次 dump 以来的变更数
rdb_bgsave_in_progress:0  // 是否正在后台执行 RDB 保存任务
rdb_last_save_time:1701180193  // 最后一次执行 RDB 保存的 UNIX 时间戳（以秒为单位）
rdb_last_bgsave_status:ok  // 最后一次执行 RDB 保存任务的状态
rdb_last_bgsave_time_sec:-1  // 最后一次执行 RDB 保存任务消耗的时间（以秒为单位）
rdb_current_bgsave_time_sec:-1  // 正在执行 RDB 保存任务的时间（如果有的话）
rdb_saves:0           // 自启动以来，redis 执行的快照数
rdb_last_cow_size:0  // 最后一次执行 RDB 保存任务所消耗的内存（以字节为单位）
rdb_last_load_keys_expired:0  // redis 7 中添加，最后一次执行 RDB 加载到内存当中时，删除的易失性 key 数
rdb_last_load_keys_loaded:12  // redis 7 中添加，最后一次执行 RDB 加载到内存当中时，加载的 key 数
...

手动触发 RDB 写入到文件的动作（save 和 bgsave）

通常来说，我们都会优先建议使用 bgsave 命令，这主要是因为：

• save 命令会阻塞 Redis 的进程，需要一直等到 dump.rdb 文件创建完毕为止，在这个过程中，服务器不接受任何的命令请求，生产环境下慎用。
• bgsave 是非阻塞式的，在该命令执行过程中，并不影响客户端的命令请求。在执行过程中，Redis 在后台会 fork 出一个子进程执行持久化操作，父进程则继续处理客户端的请求。当持久化操作完毕，子进程会发送信号给父进程，通知其已处理完毕。此时的父进程会使用新 dump.rdb 文件覆盖掉原来的旧文件。

为了完整演示，现在将各个 DB 里的数据删除，即使用 flushdb 或 flushall 命令来清空（生产环境下慎用），然后结束掉 Redis 进程，将配置文件的 save 这个参数配置为——save 60 3，手动删除 dump.rdb 文件，持久化的目录为——/usr/local/redis/DB/，最后启动我们的 Redis 实例。

Session 1	Session 2
192.168.100.3:6379> select 10 OK 192.168.100.3:6379[10]> keys * (empty array) 192.168.100.3:6379[10]> set k1 v1 OK
	Shell > ls /usr/local/redis/DB/ Shell >
# 如果这个数据很重要，则可以使用 bgsave 手动触发 192.168.100.3:6379[10]> bgsave Background saving started
	Shell > ls -l /usr/local/redis/DB/ -rw-r–r– 1 root root 100 11月 29 12:07 dump.rdb                                   ↑                            100 字节
192.168.100.3:6379[10]> info … rdb_last_save_time:1701230832 //2023-11-29 12:07:12 rdb_last_bgsave_status:ok … rdb_saves:1 …

有关 UNIX 时间戳（以秒为单位）和自然日期时间的相互转换，可以执行以下 bash 命令：

# 将自然日期时间转换为 UNIX 时间戳
Shell > date --date="2023/11/29 12:25:00" +%s
1701231900

# 将 UNIX 时间戳转换为自然日期时间
Shell > date --date="@1701231900"
2023年 11月 29日 星期三 12:25:00 CST

多提一句，不同的软件可能使用不同单位的 UNIX 时间戳，有些以天为单位（比如 /etc/shadow 文件的第三个字段，它是指密码最后一次修改的时间，是以天为单位的 UNIX 时间戳），有些以秒为单位，需要注意！

自动触发 RDB 写入到文件的动作

自动触发指的是通过配置文件的参数来实现，本质其实也就是 bgsave 命令的执行。

这里的 "save 60 3" 不是指 60s 内一定要发生 3 次 key 的变更就触发持久化，60 指的是 时间轮询，有相当多的中文资料会在这一部分误导你，如下所示：

Session 1	Session 2
# 16:46:14 执行以下命令 192.168.100.3:6379[10]> set k2 v2 OK # 16:48:05 执行以下命令 192.168.100.3:6379[10]> set k3 v3 OK
	# 16:48:10 执行以下命令，未触发持久化动作 Shell > ls /usr/local/redis/DB/ -l -rw-r–r– 1 root root 100 11月 29 12:07 dump.rdb
# 16:50:16 执行以下命令 192.168.100.3:6379[10]> set k4 v4 OK
	# 16:50:40 执行以下命令，文件的大小发生了变化 Shell > ls /usr/local/redis/DB/ -l -rw-r–r– 1 root root 121 11月 29 16:50 dump.rdb
192.168.100.3:6379[10]> info … rdb_last_save_time:1701247816 //2023年 11月 29日 星期三 16:50:16 CST …

有关这个 dump.rdb 二进制文件如何被解析并查看其内容，官方有一个被叫做 librdb 的项目，目前还处于初级阶段，了解就可以了—— https://github.com/redis/librdb

生产环境下的建议

由于这个 dump.rdb 文件很重要，因此在生产环境下，我们建议将其单独存放在一块磁盘上，或者使用定时任务（crontab）搭配 bash 脚本的方式将这个文件发送到其他机器上。

修复 RDB 文件

如同 MySQL 的 mysqlcheck 命令可以对损坏的表进行查看、修复一样，Redis 也有专门的修复命令——redis-check-rdb，它是 redis-server 命令的软链接。

Shell > ll -hi /usr/local/redis/bin/
928339 -rwxr-xr-x 1 root root 9.1M 10月 11 11:39 redis-benchmark
928342 lrwxrwxrwx 1 root root   12 10月 11 11:39 redis-check-aof -> redis-server
928341 lrwxrwxrwx 1 root root   12 10月 11 11:39 redis-check-rdb -> redis-server
928340 -rwxr-xr-x 1 root root 9.8M 10月 11 11:39 redis-cli
928343 lrwxrwxrwx 1 root root   12 10月 11 11:39 redis-sentinel -> redis-server
928338 -rwxr-xr-x 1 root root  19M 10月 11 11:39 redis-server

# 命令的输出如下
Shell > /usr/local/redis/bin/redis-check-rdb  /usr/local/redis/DB/dump.rdb
[offset 0] Checking RDB file /usr/local/redis/DB/dump.rdb
[offset 26] AUX FIELD redis-ver = '7.2.1'
[offset 40] AUX FIELD redis-bits = '64'
[offset 52] AUX FIELD ctime = '1701247816'
[offset 67] AUX FIELD used-mem = '4921320'
[offset 79] AUX FIELD aof-base = '0'
[offset 81] Selecting DB ID 10
[offset 121] Checksum OK
[offset 121] \o/ RDB looks OK! \o/
[info] 4 keys read
[info] 0 expires
[info] 0 already expired

AOF 持久化方案

这种日志就如同 MySQL 的 binlog（二进制日志）——它是记录任何 成功执行 后引起 数据变化 的日志。select、show、事务的回滚、语法错误未能成功执行的等不会记录。

AOF 是以日志追加的形式记录每个写操作（读操作不记录），当 Redis 实例重启后，会从头到尾读取日志文件的内容并进行数据的重建。默认情况下，未开启 AOF 持久化方案。相比 RDB ，AOF 可允许您丢失 1 秒的数据，这在前面提到过：

• appendfsync everysec // 同步频率为每秒，即持久化到磁盘上，可能会丢失一秒的数据。值还可以是 no 和 always

值	说明
always	每个写命令执行完毕后都会立刻将记录同步写到磁盘，好处是每一个写命令都不会丢失，但是会增加磁盘的 I/O 并降低 Redis 的性能
everysec	在性能和数据丢失中的平衡值。单个写命令执行完毕后，先把写记录放到 AOF 的内存缓冲区当中，每间隔一秒把缓冲区的数据写到磁盘
no	将写记录同步写到磁盘的操作交给操作系统控制。每个写命令执行完毕后，都会被放入 AOF 文件的内存缓冲区当中，由操作系统决定何时将缓冲区内容写到磁盘。虽然不增加磁盘 I/O，但是数据丢失的风险太大

在 Redis 7 中，AOF 文件不再是以前版本的单个文件，而是划分成了一组三类的多个文件（官方称为 Multi Part AOF）：

• 基础 AOF：可以是 RDB 二进制格式的，也可以是 AOF 文本命令格式的。由子进程通过 重写 产生，通常只有一个文件，但是如果数据量很大，也小概率有多个文件。
• 增量 AOF：纯文本文件，在 重写 开始执行时被创建，可拥有多个文件，通常而言，各种写操作都会导致增量 AOF 文件变大
• 历史 AOF：重写完成后，本次重写之前的 基础 AOF 和 增量 AOF 都会变更为 HISTORY 且被 Redis 自动删除。
• 清单文件：纯文本文件，用来跟踪和管理这些基础 AOF 和增量 AOF 文件

同 RDB 一样，你也可以使用 info 命令查看有关 AOF 持久化方面的信息。

AOF 持久化方案演示

为了演示，同样的使用 flushall 或 flushdb 清空数据、结束 redis-server 进程、删除 dump.rdb 文件、配置文件中关闭 RDB 持久化方案（save ""）、开启 AOF 持久化方案（appendonly yes）、关闭混合模式（aof-use-rdb-preamble no），最后启动我们的 Redis 实例。

# 生成 AOF 相关文件
192.168.100.3:6379> mset newk1 newv1 newk2 newv2 newk3 newv3
OK

192.168.100.3:6379> keys *
1) "newk3"
2) "newk1"
3) "newk2"

192.168.100.3:6379> quit

Shell > tree  -h /usr/local/redis/DB/appendonlydir/
/usr/local/redis/DB/appendonlydir/   
├── [    0]  appendonly.aof.1.base.aof  ← 文本格式的基础 AOF，数字 1 表示重写的第几次
├── [  103]  appendonly.aof.1.incr.aof  ← 增量 AOF，数字 1 表示重写的第几次
└── [   88]  appendonly.aof.manifest    ← 清单文件

0 directories, 3 files

# 停止 redis
Shell > killall redis-server

# 启动 Redis 实例，查看数据是否还存在
Shell > /usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf

Shell > /usr/local/redis/bin/redis-cli -h 192.168.100.3 -p 6379 -a MyPassword
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.100.3:6379> keys * 
1) "newk3"
2) "newk2"
3) "newk1"

修复 AOF 文件

在高并发场景下，会遇到一些特殊情况导致 AOF 的文件不是完整的，即损坏的 AOF 文件，导致 redis 无法正常启动，您可以尝试使用 redis-check-aof 命令进行修复，一般用法为：

Shell > redis-check-aof  --fix  file.aof

appendonly.aof.1.incr.aof 文件的内容

前面提到，增量 AOF 是一个纯文本文件，可以使用一般的编辑器打开并查看。这个文件内容的结构遵循 redis 通信协议（Redis Serialization Protocol，RESP）

Shell > cat  /usr/local/redis/DB/appendonlydir/appendonly.aof.1.incr.aof
*2
$6
SELECT
$1
0
*7
$4
mset
$5
newk1
$5
newv1
$5
newk2
$5
newv2
$5
newk3
$5
newv3

当您使用 redis-check-aof 进行修复时，其实就是遵循 RESP 进行一些语法校验，将不符合要求的行进行剔除。

重写机制（rewrite）

随着时间的推移， AOF 日志文本文件越来越大，Redis 采用了一种叫做 重写 的机制来缓解存储和恢复的压力。重写之后，新的基础 AOF 文件名里的数字会 +1，新的增量 AOF 文件名里的数字也会 +1；新的基础 AOF 文件的大小会发生变化（保留最小指令集），新的增量 AOF 文件大小会变成 0。

自动触发

前面提到，触发重写机制依赖配置文件中的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 这两个条件参数，只有两个条件同时满足才能触发重写。

# 为了更加容易演示自动触发重写机制，演示环境下会将上面参数的值改小。
Shell > vim /usr/local/redis/conf/redis.conf
...
auto-aof-rewrite-percentage 10
auto-aof-rewrite-min-size 1kb
...

# 重启 redis
Shell > killall redis-server &&  /usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf
Shell > /usr/local/redis/bin/redis-cli -h 192.168.100.3 -p 6379 -a MyPassword
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.100.3:6379> config get auto-aof-rewrite-percentage
1) "auto-aof-rewrite-percentage"
2) "10"
192.168.100.3:6379> config get auto-aof-rewrite-min-size
1) "auto-aof-rewrite-min-size"
2) "1024"

# 写入一些数据，在此时，键入的任何写命令都会导致  appendonly.aof.1.incr.aof 文件增大
## 反复执行下面这个命令
192.168.100.3:6379>  mset name zhang age 20 class 3 ID 30697512575123 number 1000000000 tmp aaaaaaaaaaaaaaaaaaa tmp2 bbbbbbbbbbbb  tmp3 ccccccc

# 触发重写机制后，一组三类的相关文件变化如下：
Shell > ls -lh /usr/local/redis/DB/appendonlydir/
总用量 8.0K
-rw-r--r-- 1 root root 433 12月  1 10:56 appendonly.aof.2.base.aof
-rw-r--r-- 1 root root   0 12月  1 10:56 appendonly.aof.2.incr.aof
-rw-r--r-- 1 root root  88 12月  1 10:56 appendonly.aof.manifest

## 虽然执行了多次写命令，但只保留最小指令集（即数据最后修改的样子）
Shell > cat /usr/local/redis/DB/appendonlydir/appendonly.aof.2.base.aof
*2
$6
SELECT
$1
0
*3
$3
SET
$5
newk2
$5
newv2
*3
$3
SET
$4
name
$5
zhang
*3
$3
SET
$5
newk1
$5
newv1
*3
$3
SET
$6
number
$10
1000000000
*3
$3
SET
$3
tmp
$19
aaaaaaaaaaaaaaaaaaa
*3
$3
SET
$3
age
$2
20
*3
$3
SET
$5
newk3
$5
newv3
*3
$3
SET
$2
ID
$14
30697512575123
*3
$3
SET
$4
tmp2
$12
bbbbbbbbbbbb
*3
$3
SET
$4
tmp3
$7
ccccccc
*3
$3
SET
$5
class
$1
3

手动命令触发

使用 bgrewriteaof 命令触发

RDB 持久化方案与 AOF 持久化方案的对比

RDB：

• 优点 – 紧凑的单文件备份，可以将文件传输到其他机器上实现远程备份；将文件内容加载到内存当中时，RDB 对比 AOF 会更加快。
• 缺点 – 那些对数据一致性和完整性要求较高的场景不适合使用 RDB。前面提到，RDB 是通过时间间隔的方式将数据写入到磁盘中，这意味着，当最新的数据没有触发持久化时，Redis 可能会丢失最新的数据，比如中途断电、操作系统异常、Redis 服务宕机等等情况。

AOF：

• 优点 – 配置为 ervrysec，最多允许丢失 1 秒的数据，可靠性更加高；基础 AOF 文件和 增量 AOF 文件都是纯文本文件，对于人类而言更加易读，也意味着可直接通过修改文件内容的方式就能完成数据重构；通过重写机制对文件的大小进行瘦身和精简。
• 缺点 – 在恢复时，同数据量的 AOF 会比 RDB 慢；相同数据量的情况下， AOF 文件的大小通常比 RDB 大；由于是每秒写入，因此会有额外的磁盘 I/O，会对 Redis 性能造成一定的影响。

RDB + AOF 混合持久化方案（生产环境推荐）

Shell > killall redis-server

再次清空 /usr/local/redis/DB/ 目录下的文件，并配置三个参数：

• save 60 3
• appendonly yes
• aof-use-rdb-preamble yes

AOF 触发重写条件的参数还是没变化：

• auto-aof-rewrite-percentage 10
• auto-aof-rewrite-min-size 1kb

开启混合持久化方案之后，就相当于为您的数据上了双重保险，优先使用 AOF 的相关文件进行恢复，如果不能恢复，则使用 RDB 文件进行恢复。

# 启动 redis
Shell > /usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf
Shell > /usr/local/redis/bin/redis-cli -h 192.168.100.3 -p 6379 -a MyPassword
192.168.100.3:6379> config get save
1) "save"
2) "60 3"
192.168.100.3:6379> config get appendonly
1) "appendonly"
2) "yes"
192.168.100.3:6379> config get aof-use-rdb-preamble
1) "aof-use-rdb-preamble"
2) "yes"
192.168.100.3:6379> config get appenddirname
1) "appenddirname"
2) "appendonlydir"

# 写入三个 string 类型的 KV 对
192.168.100.3:6379> mset mixk1 mixv1 mixk2 mixv2 mixk3 mixv3
OK
192.168.100.3:6379> keys *
1) "mixk1"
2) "mixk2"
3) "mixk3"
192.168.100.3:6379> quit

# 可以看到，同样只对三个 KV 对存储，RDB 只需要 132 字节，而 AOF 需要 279 字节
Shell > tree -h /usr/local/redis/DB/
/usr/local/redis/DB/
├── [ 4.0K]  appendonlydir
│   ├── [   88]  appendonly.aof.1.base.rdb  ← 这里就不是原先的 aof 文本格式，而是 rdb 二进制格式
│   ├── [  103]  appendonly.aof.1.incr.aof
│   └── [   88]  appendonly.aof.manifest
└── [  132]  dump.rdb

1 directory, 4 files

# 停止 redis 实例，删除 dump.rdb，验证是否是优先从 AOF 相关文件进行恢复
Shell > killall redis-server
Shell > rm -rf /usr/local/redis/DB/dump.rdb
Shell > /usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf
Shell > /usr/local/redis/bin/redis-cli -h 192.168.100.3 -p 6379 -a MyPassword
## KV对依旧存在，验证通过
192.168.100.3:6379> keys *
1) "mixk2"
2) "mixk1"
3) "mixk3"