RDB快照
save同步阻塞
客户端
服务端
.conf配置文件
# The filename where to dump the DB
dbfilename dump.rdb# rdb-del-sync-files是Redis配置文件中的一个选项，它的作用是在主节点上执行BGSAVE或AOF持久化操作时，删除同步锁文件，以释放磁盘空间。当这个选项设置为yes时，Redis会自动删除同步锁文件；当这个选项设置为no时，Redis不会自动删除同步锁文件。
rdb-del-sync-files no# rdb文件保存路径
dir /Users/momoubin/install/redis.rdb快照文件
分析
执行save命令会手动触发RDB持久化，但是save命令会阻塞Redis服务，直到RDB持久化完成。当Redis服务储存大量数据时，会造成较长时间的阻塞，不建议使用。
bgsave
client
server
分析
执行bgsave命令也会手动触发RDB持久化，和save命令不同是：Redis服务一般不会阻塞。Redis进程会执行fork操作创建子进程，RDB持久化由子进程负责，不会阻塞Redis服务进程。
RDB优缺点
RDB文件是一个紧凑的二进制压缩文件，是Redis在某个时间点的全部数据快照。
| 优点 | 缺点 | |
| RDB | 使用RDB恢复数据的速度远远比AOF的快，非常适合备份、全量复制、灾难恢复等场景。 | 每次进行bgsave操作都要执行fork操作创建子经常，属于重量级操作，频繁执行成本过高，所以无法做到实时持久化，或者秒级持久化。 |
AOF日志
AOF（Append Only File）持久化是把每次写命令追加写入日志中，当需要恢复数据时重新执行AOF文件中的命令就可以了。
AOF解决了数据持久化的实时性，也是目前主流的Redis持久化方式，这里分为四个步骤。
四个步骤
命令追加（append）：所有写命令都会被追加到AOF缓存区（aof_buf）中。
文件同步（sync）：根据不同策略将AOF缓存区同步到AOF文件中。
文件重写（rewrite）：定期对AOF文件进行重写，以达到压缩的目的。
数据加载（load）：当需要恢复数据时，重新执行AOF文件中的命令。
文件同步策略
AOF持久化流程中的文件同步有以下几个策略：
always：每次写入缓存区都要同步到AOF文件中，硬盘的操作比较慢，限制了Redis高并发，不建议配置。
no：每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件的周期不可控，而且增大了每次同步的硬盘的数据量。
eversec：每次写入缓存区后，由专门的线程每秒钟同步一次，做到了兼顾性能和数据安全。是建议的同步策略，也是默认的策略。
配置文件
conf配置文件
# appendonly改为yes，开启AOF
appendonly yes
# AOF文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 运行AOF重写时AOF文件大小的增长率的最小值
auto-aof-rewrite-percentage 100
# 运行AOF重写时文件大小的最小值
auto-aof-rewrite-min-size 64mb手动触发
client
Background append only file rewriting started
127.0.0.1:6379> Set 1 1
OK
127.0.0.1:6379> set name bryant
OK
127.0.0.1:6379> hset name-list bryant mo
(integer) 1server
AOF文件
AOF备份的优缺点
AOF持久化流程中的文件重写可以手动触发，也可以自动触发。
优点 | 缺点 | |
AOF-数据完整性 |
|
|
可重写性 |
|
|
支持不同的同步策略 |
|
|
手动触发：使用bgrewriteaof命令。
自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置确定自动触发的时机。
auto-aof-rewrite-min-size：表示运行AOF重写时文件大小的最小值，默认为64MB；
auto-aof-rewrite-percentage：表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认为100。只有前两者同时超过时才会自动触发文件重写。
总结
在真实环境中，Redis确实可以同时使用AOF（Append Only File）和RDB（Redis DataBase）两种持久化方式。这种混合使用的方式可以充分利用两者的优势，以达到更好的数据安全性和性能平衡。
AOF与RDB混用的优势
数据安全性增强：
AOF提供了持久化的日志记录，能够保证数据的完整性，即使在系统崩溃的情况下也能最大程度地恢复数据。
RDB则提供了定期的快照备份，可以在短时间内快速恢复大量数据。
性能优化：
RDB的快照机制可以在后台异步执行，对Redis的性能影响较小。
AOF的日志追加操作相对较轻量，但在高并发写入场景下可能会产生较大的磁盘I/O压力。通过RDB快照，可以减少AOF文件的大小，从而降低后续的日志重写和恢复成本。
灵活性提升：
结合使用AOF和RDB可以根据实际需求调整持久化策略，如在业务低峰期执行RDB快照，在高峰期依赖AOF日志保证数据实时性。
实施步骤与注意事项
配置启用AOF和RDB：
在Redis配置文件中同时开启save指令（用于触发RDB快照）和appendonly yes指令（启用AOF持久化）。
设置合理的同步策略：
调整appendfsync参数以控制AOF日志同步到磁盘的频率，默认走everysec（每秒同步一次）。
监控与维护：
故障恢复流程：
在发生故障时，首先尝试加载最新的RDB快照以快速恢复大部分数据。
随后应用AOF日志中的增量更新，以达到数据的最终一致性。
其他文章
Kafka消息堆积问题排查
基于SpringMVC的API灰度方案
理解到位：灾备和只读数据库
SQL治理经验谈：索引覆盖
Mybatis链路分析：JDK动态代理和责任链模式的应用
大模型安装部署、测试、接入SpringCloud应用体系
Mybatis插件-租户ID的注入&拦截应用
