Redis集群必须RDB与AOF协同工作：单用RDB易丢5分钟数据致集群校验失败，单用AOF则重写时CPU内存飙升、加载慢3–5倍致节点长期不可用；生产环境须双开并统一配置，7.0+混合模式在Codis中尚未适配。
Redis集群的持久化不能靠“选一个就好”来糊弄——RDB快照和AOF重写必须按角色分工，否则不是丢数据就是拖垮节点。
为什么不能只开RDB或只开AOF
只开RDB：在Codis或Redis Cluster中，若某个节点宕机后靠dump.rdb恢复，可能丢失最近5分钟所有变更（取决于save配置），而集群里slot迁移、failover过程又依赖数据一致性，这会直接触发校验失败或从节点拒绝同步。
只开AOF：高写入场景下appendonly.aof体积暴涨，重写时bgrewriteaof fork子进程+重放命令，CPU和内存双飙升；更麻烦的是，AOF加载比RDB慢3–5倍，主从全量同步或故障恢复时，节点长时间不可用。
常见错误现象：ERROR: Failed to load the AOF file: invalid argument（AOF损坏未修复）、Failed to open .rdb file for reading（RDB被截断但rdbchecksum yes校验失败）。
- 生产环境禁止单独启用任一模式，尤其在跨IDC部署或有金融类业务的集群中
- Redis 7.0+ 虽支持
aof-use-rdb-preamble yes混合格式，但Codis等中间件尚未完全适配，不建议在集群中开启 - 所有节点的
save规则和appendfsync策略必须统一，否则failover后新主节点可能因配置差异拒绝加载AOF
RDB配置要点：控制快照频率与资源抖动
RDB不是越勤快越好。默认save 60 10000在每秒写入超200次的集群节点上，1分钟内极易触发，导致频繁bgsave，fork开销叠加压缩压力，CPU使用率毛刺明显。
实操建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 将自动触发条件放宽至
save 300 100（5分钟100次变更），适用于日均写入 - 大数据集（>4GB）务必设
stop-writes-on-bgsave-error no，避免fork失败时整个节点拒绝写入 -
rdbcompression yes保持开启，但rdbchecksum yes必须启用——它能捕获磁盘静默错误，防止损坏RDB被静默加载 - 不要把
dir指向NFS或低IOPS云盘，RDB写入是密集顺序IO，慢盘会导致bgsave耗时翻倍甚至超时
AOF配置要点：用everysec + auto-rewrite防膨胀
appendfsync always在集群中基本不用——它让每个写命令都fsync，吞吐直接腰斩，且网络分区时主从AOF不同步风险陡增。
关键参数组合：
-
appendfsync everysec：平衡点，最多丢1秒数据，写入延迟可控 -
auto-aof-rewrite-percentage 100+auto-aof-rewrite-min-size 64mb：避免小文件频繁重写，也防止大文件（>2GB）重写卡住数分钟 -
aof-load-truncated yes：AOF尾部损坏时跳过非法命令继续加载，比直接启动失败更稳妥 - 禁用
no-appendfsync-on-rewrite yes：虽然能降低重写时延迟，但会把未刷盘的AOF缓冲积压到内存，OOM风险高
注意：bgrewriteaof触发后，旧AOF仍在追加，新AOF重写完成前两者并存——磁盘空间至少预留2倍AOF当前大小。
集群运维中最容易被忽略的三件事
第一，redis-cli --cluster check不会验证持久化配置一致性，得手动比对每个节点的CONFIG GET save和CONFIG GET appendonly输出。
第二，AOF重写生成的临时文件appendonly.aof.temp若因磁盘满中断，下次重写会沿用损坏的临时文件，必须定期清理残留。
第三，RDB+AOF双开时，Redis重启优先加载AOF；但如果AOF为空或损坏，它会退回到加载RDB——这个降级行为不报错也不打日志，只有通过INFO persistence里的loading字段为0且aof_enabled为0才能确认是否真的 fallback 了。
