Redis集群数据持久化时RDB与AOF应该如何选择？

Redis集群必须双开RDB+AOF且配置统一，因单开RDB会丢失快照后数据并触发CRC校验失败导致节点拒绝同步，单开AOF则因加载慢、重写开销大引发长时间不可用；混合模式依赖RDB提供基线、AOF补全最后1秒变更。

Redis集群不能只选RDB或只选AOF——必须双开，且配置必须统一，否则节点在failover或重启后大概率加载失败、拒绝同步甚至卡死。

为什么Redis集群里单开RDB会丢数据并触发校验失败

RDB是定时快照，中间变更全靠内存扛。默认save 60 10000在中高写入场景下极易每分钟触发一次bgsave，但一旦节点宕机，最近一次快照之后的所有变更（可能长达5分钟）就没了。而Redis Cluster的slot迁移、主从同步、故障转移都依赖数据一致性校验——比如从节点拉取dump.rdb后发现CRC校验失败，或与主节点的replication offset严重偏移，就会直接拒绝加入集群，报错Failed to load the RDB file: invalid argument或Replication buffer overflow。

1. 高频写入节点（如每秒200+写）建议放宽为save 300 100，避免频繁fork加剧CPU毛刺
2. rdbchecksum yes必须开启，否则静默损坏的RDB会被加载，导致后续命令执行异常
3. dir路径不能指向NFS或低IOPS云盘，RDB写入是密集顺序IO，慢盘会让bgsave超时甚至失败

为什么单开AOF会导致节点长时间不可用

AOF虽能保证最多丢1秒数据，但重写（bgrewriteaof）时会fork子进程+重放命令，CPU和内存双飙升；更关键的是，AOF加载比RDB慢3–5倍——集群节点重启时若只靠appendonly.aof恢复，动辄数分钟无法响应，期间所有请求失败，哨兵可能误判为节点宕机，触发不必要的failover。

1. 务必设appendfsync everysec，always在集群中基本不可用，吞吐腰斩且网络分区时主从AOF极易不一致
2. 用auto-aof-rewrite-percentage 100 + auto-aof-rewrite-min-size 64mb组合，防小文件反复重写，也防大文件（>2GB）卡住数分钟
3. 出现ERROR: Failed to load the AOF file: invalid argument，先用redis-check-aof --fix修复，别直接删AOF

生产环境必须双开RDB+AOF，且所有节点配置严格一致

Redis优先加载AOF（如果存在），但AOF重写依赖RDB快照做基线——bgrewriteaof内部会先生成一个临时RDB，再把增量命令追加进去。所以RDB和AOF不是互斥选项，而是分工协作：RDB提供快速加载基线，AOF补全最后1秒变更。

1. 所有节点的save规则、appendfsync、dir、dbfilename、appendfilename必须完全一致，否则failover后新主节点可能因AOF大小/时间戳不匹配拒绝加载
2. Redis 7.0+的aof-use-rdb-preamble yes混合模式目前在Codis、Twemproxy等主流中间件中尚未适配，集群中禁用
3. stop-writes-on-bgsave-error no建议开启，尤其大数据集（>4GB）节点，避免fork失败导致整个节点拒绝写入

最常被忽略的一点：RDB和AOF的dir路径必须指向同一块本地磁盘，且该磁盘剩余空间要大于两者峰值体积之和——AOF重写时会同时存在旧AOF、新AOF、临时RDB三个大文件，空间不足直接导致重写失败并停写。