rdb和aof必须在主从节点上保持配置一致，否则重启后数据不一致会导致同步失败或加载错误；生产环境建议统一开启aof（appendonly yes），并确保持久化文件及时落地、路径可写、哨兵超时参数与fsync策略匹配。
RDB和AOF必须在主从节点上分别配置
哨兵不管数据怎么存，它只管谁活着、谁该切。持久化配置不一致会导致主从重启后数据对不上，比如主节点开了AOF而从节点只用RDB，从节点加载dump.rdb时可能比主节点少几秒写入的数据，同步一开始就会报错NOAUTH Authentication required或LOADING Redis is loading the dataset in memory。
实操建议：
- 所有节点（主、从、哨兵）的
redis.conf中，appendonly开关保持一致：生产环境建议统一设为yes，避免AOF重写期间出现ERR Background append only file rewriting started -
save规则可以不同，但主节点的RDB触发条件不能比从节点更宽松（例如主设save 60 10000，从设save 900 1），否则从节点可能长期不生成dump.rdb，全量同步失败 - 确认
dir路径存在且有写权限，尤其在Docker部署时，dir /data需映射到宿主机可写目录，否则bgsave会静默失败，日志里只有一行Failed to open .rdb for saving: Permission denied
哨兵启动前必须确保主从数据已持久化落地
哨兵本身不读写数据，但它依赖主从节点的持久化文件做故障恢复。如果主节点刚启动、还没执行过bgsave或AOF重写，dump.rdb或appendonly.aof是空或旧的，哨兵切主后，新主节点加载的可能是过期快照，导致客户端读到陈旧数据。
验证方法：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 登录主节点执行
redis-cli info persistence，检查rdb_last_bgsave_status:ok和aof_last_rewrite_status:ok - 查看文件时间：
ls -lh /var/lib/redis/dump.rdb，确保修改时间在最近5分钟内 - 从节点执行
redis-cli role，返回结果中slave字段的offset应持续增长，说明增量同步正常，不是卡在“loading”状态
哨兵配置里的down-after-milliseconds要大于AOF fsync周期
哨兵靠心跳判断节点是否宕机，如果down-after-milliseconds设得太小（比如100ms），而AOF正以appendfsync everysec工作，Linux内核可能因IO压力延迟刷盘，哨兵误判主节点响应超时，触发不必要的故障转移。
安全阈值参考：
- 若用
appendfsync everysec，down-after-milliseconds至少设为3000（3秒） - 若用
appendfsync no，可设为1000，但不推荐——丢失数据风险高 - 务必同步调整
failover-timeout，它默认是18000（18秒），应≥3×down-after-milliseconds，否则哨兵可能放弃切换
主从切换后AOF重写可能阻塞新主节点
哨兵完成切换后，原从节点升为主，会立刻触发AOF重写（bgrewriteaof）。如果此时并发写请求多，重写进程占用大量CPU和IO，新主节点响应变慢，哨兵又可能认为它“假死”，再次发起切换，形成脑裂。
规避方式：
- 在所有节点配置
auto-aof-rewrite-percentage 0，禁用自动重写，改为运维定时脚本在低峰期手动执行redis-cli bgrewriteaof - 监控
redis-cli info stats中的instantaneous_ops_per_sec和aof_delayed_fsync，后者>0说明AOF写入已排队，需立即干预 - 不要在
redis.conf里写appendfsync always——它会让每个写命令都等磁盘落盘，切换后QPS直接腰斩
appendonly开没开、appendfsync怎么配、dir路径有没有权限——这些细节漏掉一个，高可用就变成高不可用。
