Redis 持久化选型与混合持久化
RDB 与 AOF 各有优劣，Redis 5.0 起默认开启“混合持久化”：AOF 重写后把 base 部分存成 RDB，之后继续追加命令，兼顾恢复速度与丢数据窗口，是当前生产环境的主流组合。
三种方案怎么选
| 方案 | 配置要点 | 丢数据窗口 | 适用场景 |
|---|---|---|---|
| 仅 RDB | appendonly no，配 save 规则 | 最后一次快照之后 | 可容忍分钟级丢失的缓存 |
| 仅 AOF | appendonly yes | 取决于 fsync | 可靠性要求高、写入量不大 |
| RDB + AOF 混合 | 两者都开 | 1~2 秒 | 生产环境推荐 |
混合的关键配置是 aof-use-rdb-preamble，默认 yes：
save 900 1 # 900 秒内 ≥1 次写则快照
save 300 10
appendonly yes # 同时开 AOF
appendfsync everysec
aof-use-rdb-preamble yes # 重写时 base 文件用 RDB 格式
验证一下当前持久化状态：
127.0.0.1:6379> CONFIG GET save appendonly aof-use-rdb-preamble
# 输出：1) "save" 2) "900 1 300 10 60 10000"
# 3) "appendonly" 4) "yes"
# 5) "aof-use-rdb-preamble" 6) "yes"
灾难恢复步骤
恢复的本质是让 Redis 重新加载数据目录（dir 指向的目录）里的 RDB/AOF 文件：
redis-cli shutdown nosave # 停掉实例（nosave 不覆盖旧快照）
# 把备份的 dump.rdb 与 appendonly 相关文件放回数据目录
redis-server /etc/redis/redis.conf # 按原配置启动，自动加载
redis-cli INFO persistence # 检查 aof_enabled 等加载结果
注意：两者都开启时，Redis 启动以 AOF 为准恢复（其 base 已是 RDB，速度不慢）。恢复前建议先复制一份原文件留底，防止加载失败后无法回退。
主从 + 持久化的容灾组合
单独持久化还不够，典型生产组合是“一主多从 + 主从都做基本持久化 + 例行备份”：
- 主库：appendonly yes + everysec，承载写入并负责最新数据；
- 从库：可只开 RDB 定期快照，或关闭持久化专心做读副本与故障切换备胎；
- 例行：每天定时 BGSAVE 并把 dump.rdb 拷到异地存储，定期演练恢复流程。
常见误区：有从节点就不用持久化吗
不一定。若主库完全关闭持久化后宕机，重启会得到一个空库；此时从库一旦重连做全量同步，会被空主库“同步”清空，等于副本也丢了。结论：复制只能防“单点故障”，不能替代持久化，至少主库必须开启 AOF，从库的选择取决于能否接受上述风险。
小结：可靠性按“仅 RDB < 仅 AOF < RDB+AOF 混合”递增；生产建议开启混合持久化并让主库承担 AOF，再叠加从库与例行异地备份形成完整容灾，而不是依赖某一项单点方案。