Redis集群不支持RDB+AOF混合持久化统一调度，各节点需独立配置；主节点建议RDB+AOF+appendfsync everysec，从节点应启用AOF（appendonly yes）并禁用RDB，且所有节点文件名须带端口号以避免冲突。
Redis集群不支持RDB+AOF混合持久化
Redis集群模式下，replicaof 和主从复制逻辑仍存在，但**集群自身不处理持久化策略的统一调度**——每个节点独立决定是否启用、用哪种方式持久化。这意味着你不能指望集群自动同步RDB快照或AOF重写进度；一旦某个节点宕机且未开启持久化，它的数据就彻底丢失。
常见错误现象：CLUSTER NODES 显示节点状态正常，但重启后该节点数据为空；或AOF文件持续增长却没触发bgrewriteaof，因为集群中部分节点appendonly no被默认继承。
- 必须为每个节点单独配置
save规则（如save 900 1）和/或启用appendonly yes - 禁用
appendfsync always——它在集群高写入场景下极易拖垮性能；推荐appendfsync everysec - 若使用AOF，务必打开
aof-rewrite-incremental-fsync yes，减少重写时的I/O抖动
主节点与从节点的持久化配置不能一刀切
从节点（replica）默认可配置为仅内存运行（save "" + appendonly no），靠实时复制主节点数据维持一致性。但这会带来单点风险：主节点宕机+无RDB/AOF → 整个分片数据归零。
真实生产中更稳妥的做法是让**所有节点都启用AOF**，哪怕从节点也设为appendonly yes。这样即使主节点故障，提升某个从节点为新主后，它能基于本地AOF恢复到最近秒级状态。
- 主节点建议：RDB定期快照 + AOF开启 +
appendfsync everysec - 从节点建议：关闭RDB（
save ""），但必须开启AOF（appendonly yes） - 避免从节点配置
replica-read-only no并混用写操作——这会破坏集群哈希槽映射，导致MOVED跳转异常
如何验证每个节点持久化实际生效
光改配置文件不够。Redis启动后是否真正加载了持久化设置，得看日志和运行时参数。很多团队部署完才发现某几个节点的appendonly仍是no，原因是配置未被正确reload或启动时指定了错误redis.conf路径。
执行以下检查步骤：
- 登录每个节点，运行
CONFIG GET appendonly和CONFIG GET save，确认返回值符合预期 - 查看
INFO persistence输出中的rdb_bgsave_in_progress、aof_enabled、aof_rewrite_in_progress字段 - 检查日志是否有
Failed to open the AOF file或Can't rewrite append only file in background: Permission denied等错误 - 手动触发一次
DEBUG RELOAD（仅限开发环境）或redis-cli -p 7001 BGREWRITEAOF，观察是否成功生成appendonly.aof
集群扩缩容时持久化文件容易被误删或覆盖
运维人员执行redis-cli --cluster add-node或reshard时，如果目标节点已有旧AOF/RDB文件，而新配置未清理或重命名，可能导致新主节点加载了过期快照，把刚迁移来的数据冲掉。
典型事故链：扩容新节点 → 复制旧节点dump.rdb过去 → 启动时因dbfilename dump.rdb未修改，Redis直接加载了旧快照 → 新节点上线后返回脏数据。
- 新节点首次启动前，清空数据目录下的
dump.rdb和appendonly.aof - 确保每个节点的
dbfilename和appendfilename带端口号，例如dbfilename dump_7001.rdb，避免多实例共用文件名冲突 - 不要依赖
CONFIG SET dbfilename xxx动态修改——它只影响下次BGSAVE，不改变当前加载行为
最易被忽略的是AOF重写期间节点重启：若appendonly.aof正在被重写成appendonly.aof.tmp，此时进程崩溃，tmp文件不会自动转正，下次启动仍读原AOF——这意味着重写失败不会报错，但你误以为“已优化”。
