Redis RDB 与 AOF 持久化配置指南
一、配置文件位置与生效方式
• 编辑配置文件：打开 redis.conf，在相应段落修改参数；保存后重启使配置永久生效。
• 动态生效：部分参数支持运行时修改，例如使用命令 CONFIG SET appendonly yes 在线开启 AOF（建议随后写入配置文件以免重启后丢失）。
• 验证参数：使用 CONFIG GET 参数名 或 INFO PERSISTENCE 查看当前持久化状态与细节。
二、RDB 配置要点
• 快照触发策略：使用 save
• 关键参数：
◦ dbfilename：快照文件名，如 dump.rdb。
◦ dir：持久化文件目录，务必设置为有充足空间且权限正确的绝对路径（如 /var/lib/redis）。
◦ stop-writes-on-bgsave-error yes：bgsave 失败时停止写入，避免数据空洞风险。
◦ rdbcompression yes：开启 LZF 压缩减少体积。
◦ rdbchecksum yes：写入 CRC64 校验和，提升加载安全性（有约 10% 性能开销）。
三、AOF 配置要点
• 启用与同步策略：
◦ 开启 AOF：appendonly yes。
◦ 同步策略 appendfsync：
▪ always：每次写都落盘，最安全、性能最低；▪ everysec：每秒落盘，性能与安全平衡（推荐）；▪ no：交由操作系统，性能最高、风险最大。
• 重写机制（减小体积、提升加载速度）：
◦ 自动重写：auto-aof-rewrite-percentage 100、auto-aof-rewrite-min-size 64mb（当 AOF 相比上次重写后增长 100% 且达到 64MB 时触发）。
◦ 手动重写：执行 BGREWRITEAOF。
• 异常与可用性：
◦ aof-load-truncated yes：AOF 尾部截断时仍尽力加载可用数据，避免启动失败。
四、同时启用 RDB 与 AOF（混合持久化）
• 同时开启两种机制可在重启时优先使用 AOF 恢复（数据更完整），同时保留 RDB 作为高效备份与快速恢复手段。
• 推荐配置组合示例（写入策略按业务取舍）：
◦ RDB：保留默认 save 3600 1 300 100 60 10000；或按需自定义如 save 900 1 300 10 60 10000。
◦ AOF：appendonly yes、appendfsync everysec、auto-aof-rewrite-percentage 100、auto-aof-rewrite-min-size 64mb。
◦ 混合持久化：开启 aof-use-rdb-preamble yes，在 AOF 重写时将 RDB 快照 + AOF 增量混合写入，兼顾恢复速度与数据完整性。
五、常用运维命令与验证
• 手动快照：BGSAVE（后台）不阻塞主进程；SAVE（前台）会阻塞，生产慎用。
• 状态与校验：
◦ INFO PERSISTENCE：查看 aof_enabled、aof_rewrite_in_progress、last_save 等关键指标。
◦ LASTSAVE：获取上次成功快照的 Unix 时间戳，用于校验是否落盘成功。
◦ BGREWRITEAOF：手动触发 AOF 重写。
◦ 文件修复：redis-check-aof --fix 修复损坏的 AOF；RDB 可用 redis-check-rdb 校验。
Redis 的 RDB 持久化、AOF 持久化、RDB-AOF 混合持久化 三种方式，实战配置和核心操作如下：
一、 RDB 持久化实战
-
核心原理：在指定时间间隔内，将内存中的数据集快照写入磁盘（.rdb 文件）。
-
配置方式（修改 redis.conf）
触发规则：save <秒数> <修改次数>，多条规则满足任意一条即触发
save 900 1 # 900秒内至少1个key被修改
save 300 10 # 300秒内至少10个key被修改
save 60 10000 # 60秒内至少10000个key被修改
禁用RDB：注释所有save行 + save ""
save ""
其他关键配置
dbfilename dump.rdb # RDB文件名
dir ./ # RDB文件存储目录
rdbcompression yes # 开启RDB压缩（默认yes）
rdbchecksum yes # 开启RDB校验和（默认yes）
3. 手动触发命令
◦ save：阻塞Redis主线程，直到RDB生成完成（生产环境慎用）。
◦ bgsave：fork子进程生成RDB，主线程不阻塞（生产环境推荐）。
- 恢复数据：将 .rdb 文件放入Redis配置的 dir 目录，启动Redis即可自动加载。
二、 AOF 持久化实战
-
核心原理：记录Redis的每一条写命令（如 set、hmset），重启时通过重放命令恢复数据。
-
配置方式（修改 redis.conf）
appendonly yes # 开启AOF（默认no）
appendfilename "appendonly.aof" # AOF文件名
dir ./ # AOF文件存储目录
AOF同步策略（核心）
appendfsync always # 每次写命令都同步到磁盘，数据最安全但性能最差
appendfsync everysec # 每秒同步一次，兼顾性能和安全性（默认）
appendfsync no # 由操作系统决定同步时机，性能最好但数据风险最高
AOF重写（解决AOF文件过大问题）
auto-aof-rewrite-percentage 100 # 当前AOF文件比上次重写后增大100%触发
auto-aof-rewrite-min-size 64mb # AOF文件最小64MB才触发重写
3. 手动触发重写
◦ bgrewriteaof：fork子进程执行AOF重写，主线程不阻塞。
- 恢复数据：开启AOF的情况下，Redis启动优先加载AOF文件；若AOF文件损坏，可执行 redis-check-aof --fix appendonly.aof 修复。
三、 RDB-AOF 混合持久化实战
-
核心原理：Redis 4.0+ 支持的模式，AOF文件前半部分是RDB快照，后半部分是增量的AOF命令，兼顾RDB的快速恢复和AOF的数据完整性。
-
配置方式（修改 redis.conf，需先开启AOF）
appendonly yes # 必须开启AOF
aof-use-rdb-preamble yes # 开启混合持久化（Redis 5.0+默认yes）
其他配置复用RDB和AOF的基础配置（如dir、rdbcompression、appendfsync等）
- 触发机制
◦ 自动触发：满足AOF重写规则时，重写后的AOF文件会自动生成「RDB快照 + 增量AOF」的混合格式。
◦ 手动触发：执行 bgrewriteaof 命令，直接生成混合格式的AOF文件。
- 恢复数据：Redis启动时，加载混合AOF文件——先加载前半部分RDB快照快速恢复大部分数据，再重放后半部分AOF命令补全增量数据。
四、 三种持久化方式核心对比
特性 RDB AOF 混合持久化
数据完整性 低（可能丢失最后一次快照后的数据） 高（取决于同步策略） 高（接近AOF）
恢复速度 快 慢（命令重放） 快（RDB+增量AOF）
文件体积 小（压缩快照） 大（命令日志） 中等（RDB压缩+增量命令）
性能影响 低（bgsave fork子进程） 中（同步磁盘消耗IO） 中（兼顾两者）
我可以帮你整理一份三种持久化方式的故障排查清单，包含文件损坏、加载失败、性能瓶颈的解决方法，需要吗？