主库必须配持久化，从库一般不配；因主库是写入唯一入口，无持久化会导致进程异常退出时数据全丢，而从库配持久化易引发数据不一致或同步阻塞。
主库必须配持久化，从库一般不配 —— 但不是因为“从库不需要”，而是因为配了反而可能引发数据不一致或同步阻塞。
为什么主库必须开启 AOF 或 RDB
主库是写入唯一入口，所有变更都从它发出。如果主库没开持久化，进程意外退出（比如 OOM kill、kill -9、宿主机宕机），内存数据彻底丢失，从库同步的只是“空状态”或上一次快照之后的脏数据，根本无法回溯。
常见错误现象：redis-server 重启后 KEYS * 返回空，但业务日志显示刚写入过数据；哨兵切换后新主节点数据比旧主还少。
- RDB 适合做冷备和快速恢复，但默认配置下可能几分钟才触发一次，中间写入全丢
- AOF 更安全，建议设为
appendfsync everysec：兼顾性能与最多 1 秒数据丢失 - 4.0+ 版本可启用混合持久化（
aof-use-rdb-preamble yes），重启加载更快，推荐生产环境使用
从库开启持久化反而容易出问题
从库的定位是“只读副本”，它的数据应完全由主库同步而来。一旦从库自己也落盘，就可能出现两种危险情况：
- 主库故障前未同步完的命令，被从库 AOF 记录下来；故障转移后它升为主，这些“孤立项”会污染数据逻辑（比如重复发券、多扣库存）
- 从库 AOF rewrite 或 RDB save 过程中，fork 子进程占用大量内存和 CPU，导致
repl-backlog积压、复制延迟飙升，甚至触发master_link_down_since_seconds告警 - 运维误操作：手动在从库执行
CONFIG SET appendonly yes后忘记关，后续升级或重启导致行为突变
真实案例：某电商大促期间，一个从库因磁盘满导致 AOF write 失败，Redis 进程自动 shutdown，哨兵误判为节点失联，反复尝试 failover，最终引发读服务抖动。
例外场景：从库需开启持久化的三种情况
极少数业务强依赖从库独立存活能力，才考虑开启，但必须配套约束：
- 该从库明确标记为“热备主”，且业务已实现写请求路由切换逻辑（非哨兵自动接管）
- 配置
replica-read-only yes+appendonly no为默认，仅对该实例单独打开，并关闭save配置项，避免 RDB 干扰 - 监控必须覆盖
aof_last_write_status和aof_pending_rewrite，任何 write error 都要立即告警
注意：slaveof 命令动态挂载的从库，其持久化配置继承自启动时的 redis.conf，不会随主库配置变化而同步更新 —— 这点常被忽略。
真正该关注的是复制链路本身是否可靠
比起纠结“从库要不要落盘”，更关键的是让主从之间同步稳、断连后恢复快：
- 调大
repl-backlog-size（建议 ≥ 512mb），防止网络抖动时从库重连触发全量同步 - 检查
repl-ping-replica-period和repl-timeout，避免因内核net.ipv4.tcp_keepalive_*参数过松导致假断连 - 禁用
slave-serve-stale-data yes（默认值），当从库与主库断连超时，直接拒绝读请求，而不是返回陈旧数据
持久化解决的是“进程级”数据保全，复制解决的是“节点级”数据冗余 —— 两者目标不同，不能互相替代，也不该混为一谈。
