文章目录
Redis持久化说明
Redis持久化
Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。为了防止这种情况的发生，Redis提供了持久化机制，将内存中的数据异步地保存到磁盘，以保证数据的安全性和可靠性。
在redis当中，Redis的持久化机制有三种，分别是RDB持久化、AOF持久化和混合持久化。
RDB持久化
- RDB持久化概述
RDB持久化是 Redis 内置的一种持久化方式，它会在某一时间点对 Redis 的数据进行全量备份，将其存储到磁盘中。可以理解为一个快照，这个快照记录了 Redis 数据在某个时间点上的状态。
RDB持久化会生成多个数据文件，每个数据文件都代表了 Redis 在某一个时刻中的数据状态。Redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化。对外提供的读写服务，影响非常小。但是如果数据文件特别大，可能会导致对客户端提供的服务暂停数秒。
RDB持久化需要频繁地将 Redis 的数据写入到磁盘中，因此其对性能的影响比较大。此外，RDB持久化会丢失某一时间段的数据。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦 Redis 进程宕机，那么会丢失最近5分钟的数据。
RDB持久化是Redis的默认持久化方式，它通过在特定的时间点或者达到一定的条件下，将Redis的内存数据快照写入到磁盘上的RDB文件中。
RDB文件是一个二进制文件，包含了一个Redis的数据快照，它记录了Redis在某个时间点上的所有数据，可以用来恢复数据。
RDB持久化可以通过配置或者手动执行命令生成RDB文件。
通过配置设置Redis在满足一定条件时自动保存数据，要满足的条件可以通过save命令设置。
比如可以设置让Redis在满足“60秒内至少有1000个键被改动”这个条件时，自动保存一次数据集。
手动执行命令可以进入Redis客户端，执行save或者bgsave命令，Redis会将当前内存中的数据快照到一个新的RDB文件里，并覆盖之前的RDB文件。
- RDB持久化过程
在RDB生成的过程中，Redis会调用fork()函数，创建一个子进程来完成快照的生成工作。这个子进程会先将当前内存中的所有键和值遍历一遍，然后将它们写入到一个临时文件中。当子进程完成对所有键值对的遍历和写入操作之后，它会用临时文件的内容覆盖原有的RDB文件，完成快照的生成和持久化。
- RDB持久化特点
RDB持久化的优点在于它生成的文件非常紧凑和稳定，是快速恢复大量数据的最佳选择。但是它也有一些缺点，例如需要频繁的将整个数据集写入磁盘，这会造成磁盘I/O的瓶颈，影响Redis的性能。
同时，由于快照是在一个瞬间进行的，所以如果在生成快照的时候出现宕机，可能会造成数据的损失。
AOF持久化
- AOF持久化概述
AOF持久化是另一种持久化方式，它会记录Redis中的所有写操作，以append-only模式写入日志文件。AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能很高，而且文件不容易破损。
AOF持久化可以更好地保护数据不丢失。一般AOF每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。当然，这种方式也会对性能产生一定的影响。
AOF持久化文件通常比RDB数据快照文件更大。支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
此外，在AOF日志文件过大时，可以进行后台重写操作，生成一份最小恢复数据的日志以供恢复，这种方式不会影响客户端的读写。
AOF持久化是Redis的另一种持久化方式，它记录了Redis所有执行的写命令，并将它们追加到AOF文件的末尾。这个文件是一个纯文本文件，包含了Redis服务器的所有写操作。
- AOF持久化特点
相比于RDB持久化，AOF持久化更加安全，因为它可以记录每一次写操作。在Redis重启的时候，可以通过重新执行AOF文件中的命令来恢复数据。
AOF持久化可以通过配置启用，并且可以设置Redis多久将数据fsync到磁盘一次，这里的fsync就是将内存中的数据刷到磁盘上，保证数据的可靠性。
当写入许多数据时，Redis会将这些数据先写入到缓冲区中，然后再通过fsync命令将它们刷到磁盘上。
AOF文件里可能有太多没用的指令，所以Redis也提供了自动重写AOF文件的机制，它会定期根据内存的最新数据重新生成AOF文件。可以通过修改配置文件达到64M才会自动重写，也可以通过配置文件使AOF文件自上一次重写后文件大小增长了100%才会触发重写。
手动执行命令bgrewriteaof重写AOF，Redis会fork出一个子进程去完成重写工作，不会对Redis正常命令处理有太大影响。
总结：AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。
AOF 文件重写触发机制：通过 redis.conf 配置文件中的 auto-aof-rewrite-percentage：默认值为100，以及auto-aof-rewrite-min-size：64mb 配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
混合持久化
- 混合持久化概述
仅仅使用RDB持久化或者仅仅使用AOF持久化都会有一些问题。
使用RDB持久化，Redis在重启后需要将最近一次快照以及快照后的所有写操作进行重放，这会导致数据丢失。使用AOF持久化，Redis的性能会有所降低。
因此我们可以使用混合持久化的方式。开启两种持久化方式，用AOF来保证数据不丢失，作为数据恢复的第一选择；在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。
值得一提的是，Redis 4.0版本之后，还提供了增量RDB持久化（AOF重写的一部分实现方式）。这种方式会根据配置的时间间隔和数据变化情况自动进行RDB快照备份，相对于全量RDB持久化方式，可以大幅降低备份时间。
RDB持久化和AOF持久化各有优点和缺点，而混合持久化可以将两种方式的优点结合起来，达到最好的效果。在实际应用中，要根据自己的需求选择合适的持久化方式。
混合持久化是Redis在2.4版本中引入的新特性，它将RDB持久化和AOF持久化结合在一起，可以让Redis在重启时更快地恢复数据。
混合持久化需要通过配置将AOF和RDB持久化结合在一起，具体实现方式是在AOF文件中写入RDB文件的内容，并将新的数据操作追加到AOF文件的末尾。在Redis重启的时候，先加载RDB文件的内容，再根据AOF文件中的增量命令来进行恢复。这样可以大大提高恢复的速度。
在实现上，开启混合持久化后，AOF在重写时不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件。新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
因为混合持久化可以同时保证数据的完整性和可靠性，所以在实际生产环境中大部分情况下都会选择使用混合持久化。
总之，Redis的持久化机制是非常重要的，它可以保证Redis在遇到异常情况时的数据安全性和可靠性。不同的持久化方式有着各自的优缺点，需要根据实际情况来选择合适的持久化方式。同时，也需要注意持久化机制对Redis性能的影响，不要将频繁的持久化操作和高负载的业务操作同时进行，以免造成性能瓶颈。
save与bgsave
Redis 具有高性能、高可用、高扩展性等优势，但是，它也存在着一些问题，比如会出现数据丢失、数据库备份不够方便等情况。因此，Redis 就推出了两种备份方案，分别是 save 和 bgsave。
save 和 bgsave 都是 Redis 的备份方案，它们的主要目的是用来保护数据库的数据安全性和完整性。但是，它们之间有很大的不同，下面就让我详细介绍一下 save 和 bgsave 的区别。
save
save 是一种同步阻塞的备份方案，它会阻塞客户端命令和 Redis 的其他命令，直到备份完成。这样，就会对 Redis 的性能产生一定的影响。save 的备份过程中，所有的数据都会被保存到硬盘中，这样，即使 Redis 出现了异常情况，比如进程崩溃或服务器掉电等，数据也不会丢失。但是，由于 save 是同步阻塞的，所以在备份过程中，Redis 不能响应客户端的任何操作，这样对服务器压力和性能都会造成一定的影响。因此，save 通常只用于单机部署、数据量较小的情况下，对于大规模集群部署来说，它并不适用。bgsave
bgsave 与 save 不同，bgsave 是一种异步非阻塞的备份方案，它会在后台进行备份操作，不会影响 Redis 的主要业务。bgsave 的备份过程中，Redis 会先创建一个子进程，该子进程会复制 Redis 的所有数据，并将其保存到硬盘中。当备份完成后，子进程会通知 Redis 主进程，告诉它备份已经完成。
bgsave 的备份过程对 Redis 的性能影响很小，因为它是后台进行的，所以 Redis 仍然可以响应客户端的请求。但是，在备份过程中，由于需要复制 Redis 的所有数据，所以会消耗额外的内存空间，这也是 bgsave 的一个缺点。
- 场景对比
如有一个在线教育平台，它的后台需要存储很多的视频、音频和图片等多媒体数据。在这种情况下，如果使用 save 进行数据备份，那么在备份的过程中，所有的客户端请求都会被阻塞，这样会对用户体验造成一定的影响，而且在大规模集群部署的情况下，备份的速度也会很慢。但是，如果使用 bgsave 进行数据备份，那么在备份的过程中，用户的请求依然可以得到及时的响应，这样就不会影响用户的体验。当然，由于需要复制 Redis 的所有数据，所以在备份过程中会消耗额外的内存空间，但是相比于 save 来说，这种消耗是可以接受的。
综上所述，save 和 bgsave 都是 Redis 的备份方案，它们在实现方式和备份过程中的影响都不同。
save 是同步阻塞的，会阻塞客户端命令和 Redis 的其他命令，在备份过程中对服务器压力和性能都会造成一定的影响。而 bgsave 是异步非阻塞的，可以在后台进行备份操作，不会影响 Redis 的主要业务，在备份过程中对服务器压力和性能的影响很小，但是会消耗额外的内存空间。在实际应用中，需要根据具体的业务需求选择合适的备份方案。
参考：Redis持久化解析：全面了解Redis的数据持久化机制
| 特性维度 | RDB (Redis Database) | AOF (Append Only File) | 混合持久化 (RDB+AOF) |
|---|---|---|---|
| 持久化原理 | 定时内存快照（二进制格式） | 记录所有写命令（文本协议格式） | 全量数据用 RDB 存储，增量命令用 AOF 追加 |
| 触发机制 | save m n 配置 / BGSAVE 命令 |
每次写操作 / appendfsync 策略控制刷盘频率 |
依赖 AOF 重写自动触发 |
| 数据安全性 | 能丢失最后一次快照后的所有数据 | fsync=always 时零丢失 |
结合 RDB 完整性与 AOF 实时性 |
| 性能影响 | fork 子进程，内存翻倍峰值 |
每次写操作需刷盘（always模式性能骤降） |
重写时存在 RDB 生成开销 |
| 恢复速度 | 载入二进制文件（速度最快） | 需顺序重放所有命令（文件大时极慢） | 先加载 RDB 再重放少量 AOF（速度接近 RDB） |
| 文件体积 | 压缩，体积最小 | 存储原始命令，体积可能达数据量数倍 | 全量 RDB + 增量 AOF，体积适中 |
| 故障恢复完整性 | 依赖于最后一次快照时间点 | 取决于 appendfsync 配置（everysec 丢1秒数据） |
最佳：全量点 + 增量命令双重保障 |
| 配置关键参数 | savestop-writes-on-bgsave-errorrdbcompression |
appendonlyappendfsyncauto-aof-rewrite-percentage |
aof-use-rdb-preamble（Redis 4.0+） |
| 生产推荐场景 | 允许分钟级数据丢失 灾备冷备 |
金融级数据安全要求 写操作量中等 |
主流推荐方案 高可靠性要求 频繁写操作环境 |
| 云服务默认方案 | AWS ElastiCache：关闭 Azure Cache：可选 |
GCP Memorystore：默认开启 | 阿里云 Tair：默认启用混合模式 |
Redis RDB持久化
Redis 安装
略，参考《001.Redis 简介及安装》。
Redis RDB配置
[root@redis01 ~]# mkdir -p /var/lib/redis/redis01/ #创建Redis RDB持久化文件保存路径
[root@redis01 ~]# vim /etc/redis/redis01_6379.conf
#……
save 900 1 # 900秒内至少1个key变更
save 300 10 # 300秒内至少10个key变更
save 60 10000 # 60秒内至少10000个key变更
stop-writes-on-bgsave-error yes # 默认，bgsave失败时拒绝写入
rdbcompression yes # 默认，启用LZF压缩
rdbchecksum yes # 默认，写入校验和
dbfilename dump.rdb # 默认，RDB文件名
dir /var/lib/redis/redis01/ # 设置保存目录
[root@redis01 ~]# systemctl restart redis-server.service
手动触发
如上设置额触发条件，但也可以手动触发。
[root@redisclient ~]# redis-cli -h redis01 -p 6379
# 阻塞式保存
redis01:6379> SAVE
OK
# 后台异步保存(推荐)
redis01:6379> BGSAVE
Background saving started
# 查看最近RDB状态
redis01:6379> INFO PERSISTENCE
# Persistence
loading:0
async_loading:0
current_cow_peak:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1751908837
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_saves:2
rdb_last_cow_size:360448
rdb_last_load_keys_expired:0
rdb_last_load_keys_loaded:0
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_rewrites:0
aof_rewrites_consecutive_failures:0
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0
redis01:6379>
RDB持久化模拟
写入测试数据
redis01:6379> SET user:1 "Xianghy"
redis01:6379> SET user:2 "Wanger"
redis01:6379> BGSAVE
redis01:6379> exit
模拟进程异常
手动模拟Redis进程异常。
[root@redis01 ~]# ps -ef | grep redis
root 8191 1 0 01:19 ? 00:00:01 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root 8222 7881 0 01:25 pts/0 00:00:00 grep --color=auto redis
[root@redis01 ~]# kill -9 8191
[root@redis01 ~]# systemctl start redis-server.service
[root@redis01 ~]# ps -ef | grep redis
root 8231 1 0 01:26 ? 00:00:00 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root 8239 7881 0 01:26 pts/0 00:00:00 grep --color=auto redis
客户端查看写入的测试数据：
[root@redisclient ~]# redis-cli -h redis01 -p 6379
redis01:6379> get user:1
"Xianghy"
RDB的优缺点
优势
- 使用RDB持久化方式，那么整个Redis数据库将只包含一个文件，这样可以方便进行备份。
- 方便备份，可以很容易的将单个RDB文件保存到其他存储设备上。
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
- RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
劣势
- 若需要尽量避免在服务器故障时丢失数据，那么 RDB 并非很适合。虽然 Redis 允许设置不同的保存点（save point）来控制保存 RDB 文件的频率，但是，因为 RDB 文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 可能会丢失好几分钟的数据。
- 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大时，fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
Redis AOF持久化
Redis 安装
略，安装参考《001.Redis 简介及安装》。
Redis AOF配置
如下为纯粹的开启AOF持久化主要配置。
[root@redis01 ~]# mkdir -p /var/lib/redis/redis01/ #创建Redis RDB持久化文件保存路径
[root@redis01 ~]# vim /etc/redis/redis01_6379.conf
# ……
save "" # 修改，明确禁止RDB持久化
dir /var/lib/redis/redis01/
appendonly yes # 修改，启用AOF持久化
appendfilename "appendonly.aof" # 默认，AOF主文件名
appenddirname "appendonlydir" # 默认，AOF 分片文件目录
appendfsync everysec # 默认，同步策略（推荐值），每秒同步
no-appendfsync-on-rewrite no # 默认，重写时继续同步（保证数据安全）
auto-aof-rewrite-percentage 100 # 默认，文件增长100%触发重写
auto-aof-rewrite-min-size 64mb # 默认，最小重写大小
aof-load-truncated yes # 默认，允许加载截断的 AOF 文件
aof-use-rdb-preamble no # 修改，关闭混合持久化
aof-timestamp-enabled no # 默认，不在 AOF 中记录时间戳
aof-rewrite-incremental-fsync yes # 默认，增量式同步（优化重写性能）
# ……
[root@redis01 ~]# systemctl restart redis-server.service
AOF数据持久化机制：
AOF持久化模拟
写入测试数据
[root@redisclient ~]# redis-cli -h redis01 -p 6379
redis01:6379> SET name:1 "Zhangsan"
redis01:6379> SAVE
redis01:6379> SET name:2 "Lisi"
redis01:6379> QUIT
模拟进程异常
- 模拟异常
手动模拟Redis进程异常。
[root@redis01 ~]# kill -9 $(pgrep -f "redis-server.*6379") #杀死redis进程
[root@redis01 ~]# systemctl status redis-server.service
● redis-server.service - Redis Server Manager
Loaded: loaded (/usr/lib/systemd/system/redis-server.service; enabled; preset: disabled)
Active: activating (auto-restart) (Result: signal) since Sat 2025-07-12 13:53:21 CST; 922ms ago
……
[root@redis01 ~]# ll /var/lib/redis/redis01/appendonlydir/
total 8.0K
-rw-r--r-- 1 root root 0 Jul 12 13:50 appendonly.aof.1.base.aof
-rw-r--r-- 1 root root 97 Jul 12 13:52 appendonly.aof.1.incr.aof
-rw-r--r-- 1 root root 102 Jul 12 13:50 appendonly.aof.manifest
[root@redis01 ~]# cat /var/lib/redis/redis01/appendonlydir/appendonly.aof.1.incr.aof # AOF 文件可直接cat查看
- 重启redis进程
[root@redis01 ~]# systemctl start redis-server.service
[root@redis01 ~]# ps -ef | grep redis
root 8231 1 0 01:26 ? 00:00:00 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root 8239 7881 0 01:26 pts/0 00:00:00 grep --color=auto redis
- 确认结果
客户端查看写入的测试数据：
[root@redisclient ~]# redis-cli -h redis01 -p 6379
redis01:6379> GET name:1
"Zhangsan"
redis01:6379> GET name:2
"Lisi"
AOF的优缺点
优势
- AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
- AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
- AOF文件的格式很容易阅读，这使得使用者可以更加灵活地处理它们。例如，意外错用了 FLUSHALL 命令，在重写还没进行时，可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。
劣势
- 对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大。AOF默认的每秒同步一次频率虽然提供了多种同步频率选项，但性能依然较高。在 Redis 负载较高时，RDB提供了比AOF更好的性能保证。
- RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。据官方文档指出，AOF 存在着一些 RDB 没有的 BUG。
混合持久化存储
Redis 安装
略，安装参考《001.Redis 简介及安装》。
Redis 混合持久化配置
如下为纯粹的开启混合持久化主要配置。
[root@redis01 ~]# vim /etc/redis/redis01_6379.conf
#……
#save "" # 默认，开启RDB持久化
save 900 1 # 15分钟内有1个key变化则触发RDB
save 300 10 # 5分钟内有10个key变化则触发RDB
save 60 10000 # 1分钟内有10000个key变化则触发RDB
stop-writes-on-bgsave-error no # 修改，bgsave失败时继续写入（高可用场景）
rdbcompression yes # 默认，启用RDB压缩
rdbchecksum yes # 默认，启用RDB校验和
dir /var/lib/redis/redis01/
appendonly yes # 修改，启用AOF持久化
appendfilename "appendonly.aof" # 默认，AOF主文件名
appenddirname "appendonlydir" # 默认，AOF 分片文件目录
appendfsync everysec # 默认，同步策略（推荐值），每秒同步
no-appendfsync-on-rewrite no # 默认，重写时继续同步（保证数据安全）
auto-aof-rewrite-percentage 100 # 默认，文件增长100%触发重写
auto-aof-rewrite-min-size 64mb # 默认，最小重写大小
aof-load-truncated yes # 默认，允许加载截断的 AOF 文件
aof-use-rdb-preamble yes # 默认，开启混合持久化（AOF文件包含RDB前导）
aof-timestamp-enabled no # 默认，不在 AOF 中记录时间戳
aof-rewrite-incremental-fsync yes # 默认，增量式同步（优化重写性能）
#……
[root@redis01 ~]# systemctl restart redis-server.service
混合持久化模拟
写入测试数据
[root@redisclient ~]# redis-cli -h redis01 -p 6379
redis01:6379> SET user:1001 "rdb_persisted"
redis01:6379> SET user:1002 "rdb_persisted"
redis01:6379> SAVE
redis01:6379> SET user:1003 "aof_only_value"
redis01:6379> INCR counter
redis01:6379> INCR counter
redis01:6379> QUIT
模拟进程异常
- 检查持久化文件
[root@redis01 ~]# ls -lh /var/lib/redis/redis01/
total 4.0K
drwxr-xr-x 2 root root 103 Jul 12 14:12 appendonlydir
-rw-r--r-- 1 root root 143 Jul 12 14:17 dump.rdb
[root@redis01 ~]# ls -lh /var/lib/redis/redis01/appendonlydir/
total 12K
-rw-r--r-- 1 root root 88 Jul 12 14:12 appendonly.aof.1.base.rdb
-rw-r--r-- 1 root root 222 Jul 12 14:17 appendonly.aof.1.incr.aof
-rw-r--r-- 1 root root 102 Jul 12 14:12 appendonly.aof.manifest
[root@redis01 ~]# cat /var/lib/redis/redis01/appendonlydir/appendonly.aof.1.incr.aof
*2
$6
SELECT
$1
0
*3
$3
SET
$9
user:1001
$13
rdb_persisted
*3
$3
SET
$9
user:1002
$13
rdb_persisted
*3
$3
SET
$9
user:1003
$14
aof_only_value
*2
$4
INCR
$7
counter
*2
$4
INCR
$7
counter
- 模拟崩溃
手动模拟Redis进程异常。
[root@redis01 ~]# kill -9 $(pgrep -f "redis-server.*6379") #杀死redis进程
[root@redis01 ~]# systemctl status redis-server.service
● redis-server.service - Redis Server Manager
Loaded: loaded (/usr/lib/systemd/system/redis-server.service; enabled; preset: disabled)
Active: activating (auto-restart) (Result: signal) since Sat 2025-07-12 13:53:21 CST; 922ms ago
……
- 重启redis进程
[root@redis01 ~]# systemctl start redis-server.service
[root@redis01 ~]# ps -ef | grep redis
root 8231 1 0 01:26 ? 00:00:00 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root 8239 7881 0 01:26 pts/0 00:00:00 grep --color=auto redis
客户端查看写入的测试数据：
[root@redisclient ~]# redis-cli -h redis01 -p 6379
redis01:6379> GET user:1001
"rdb_persisted" # 来自RDB部分
redis01:6379> GET user:1003
"aof_only_value" # 来自AOF增量部分
redis01:6379> GET counter
"2" # 验证命令顺序