数据能否恢复取决于磁盘上是否存在权限正确、路径可达的持久化文件；RDB仅保存快照易丢数据，AOF最多丢1秒且可人工修复，混合持久化兼顾速度与完整性，但需正确配置dir、appendfilename及aof-use-rdb-preamble。
主从节点同时宕机时，如果没有持久化，所有数据彻底丢失——这不是小概率事件，而是真实生产环境中反复发生过的故障场景。
主从同步不是数据保险箱
Redis 主从复制是异步的，从节点的数据永远滞后于主节点。即使配置了 repl-backlog-size，它也只是环形缓冲区，容量有限；一旦网络抖动、从节点重启或复制偏移量追不上，就会触发全量同步（PSYNC 或 SYNC），期间新写入命令可能被覆盖。更关键的是：主从都只存内存数据时，只要两者在同一台物理机、同一机柜、同一机房断电或内核崩溃，数据就归零。
- 主节点宕机 + 从节点尚未完成 RDB 加载 → 无可用数据
- 主从容器共用宿主机并同时被 OOM kill → 内存数据全失
- 运维误操作同时停掉两个实例（如批量
docker stop）→ 零恢复点
RDB 和 AOF 在主从宕机后的作用完全不同
当主从全部不可用，恢复依赖的是磁盘上是否留有可加载的数据文件。RDB 是快照，AOF 是操作日志，二者恢复能力差异极大：
-
RDB文件（如dump.rdb）能直接redis-server启动即用，但只反映某个时间点状态，中间写入全丢 -
AOF（尤其appendfsync everysec）最多丢 1 秒数据，且文件本身是纯文本协议格式，紧急时可人工截断、编辑、重放 - 若仅开启 RDB，而
save配置为save 900 1（15 分钟 1 次变更才保存），那一次宕机可能丢失十几分钟业务订单
混合持久化（aof-use-rdb-preamble yes）是当前最稳妥的选择
Redis 4.0+ 支持在 AOF 文件开头嵌入一个 RDB 快照，后续再追加 AOF 日志。这种格式兼顾了 RDB 的加载速度和 AOF 的数据完整性：
- 重启时先载入 RDB 段，再重放 AOF 段，比纯 AOF 快数倍
- 文件体积比纯 AOF 小很多，避免
auto-aof-rewrite-percentage频繁触发 - 必须配合
appendonly yes和aof-use-rdb-preamble yes两行配置生效，缺一不可 - 注意：
redis-check-aof --fix无法修复混合格式，出问题只能靠备份恢复
最容易被忽略的配置陷阱
很多人开了 AOF 却没生效，或者开了却不敢关 RDB，根源在于几个硬性依赖没满足：
-
dir配置路径必须有写权限，否则appendonly.aof根本创建不了（日志里只报Can't open the append only file: Permission denied） -
appendfilename若含路径（如./logs/appendonly.aof），会相对于dir拼接，极易写错位置 - 使用
CONFIG SET appendonly yes是临时生效，进程重启后失效，必须写入redis.conf并确保启动时加载该文件 - Docker 环境下，
dir必须映射到宿主机持久卷，否则容器删掉，AOF 文件也跟着消失
真正决定数据能否活下来的关键，从来不是“有没有从节点”，而是“磁盘上有没有那一份可执行的、带时间戳的、权限正确的、路径可达的持久化文件”。主从只是冗余手段，持久化才是底线。
