stop-writes-on-bgsave-error 与脏读无关，因其仅控制RDB持久化失败时是否拒写，而脏读源于主从复制中过期键的异步删除与传播延迟；真正影响脏读的是hz、replica-serve-stale-data等配置及读写路由策略。
不能通过 stop-writes-on-bgsave-error 避免脏读，它和脏读完全无关，反而会制造服务雪崩。
为什么 stop-writes-on-bgsave-error 和脏读没关系
Redis 的脏读只发生在主从复制场景下：主库上 key 已过期并被删除（或尚未删除），但从库还没同步这个状态，客户端读从库就拿到过期数据。这个过程和 RDB 是否持久化、是否失败、是否拒绝写入，零关联。
stop-writes-on-bgsave-error 控制的是“RDB 写盘失败时是否拒写”，而脏读根源是过期策略的异步性（惰性+定期删除）与主从传播延迟。即使 RDB 持久化 100% 成功，脏读照样发生；即使关掉所有持久化，只要用了 EXPIRE + 读从库，脏读风险仍在。
- Redis 不在从库执行过期判断，
expireIfNeeded只在主库调用 - 从库收到
DEL命令才真正删 key，但这个命令依赖主库是否触发了惰性/定期删除 - 如果大量 key 集中过期，定期删除可能忙不过来，主库没发
DEL，从库就一直返回旧值
真正影响脏读的关键配置其实是这些
想降低脏读概率，得盯住过期策略和主从行为，而不是持久化开关：
-
hz：默认 10，即每秒调用 10 次activeExpireCycle。值越大，定期删除越积极，但 CPU 开销上升。生产环境可谨慎调到 20–30 -
maxmemory-policy：若设为noeviction，内存满时写失败，但不影响过期逻辑；若设为allkeys-lru等，淘汰可能提前触发 key 删除，间接影响从库一致性 -
replica-serve-stale-data yes（默认）：从库在断连期间仍提供可能过期的数据。设为no可让从库直接返回错误，避免脏读，但牺牲可用性 -
min-replicas-to-write和min-replicas-max-lag：不直接影响脏读，但能防止主库在从库严重滞后时继续写入，间接减少不一致窗口
遇到 MISCONF 错误时别乱关写入保护
当看到 (error) MISCONF Redis is configured to save RDB snapshots...，说明 stop-writes-on-bgsave-error yes 被触发，但这只是表象——背后是磁盘满、权限错、fork 失败等真实故障。此时强行 CONFIG SET stop-writes-on-bgsave-error no，等于掩盖问题，后续 RDB 仍会反复失败，且你根本不知道数据到底有没有落盘。
- 先查根本原因：
redis-cli INFO persistence看rdb_last_bgsave_status和rdb_last_bgsave_time_sec - 再看系统层：
df -h、ls -l $(redis-cli CONFIG GET dir | tail -n 1)、dmesg | grep -i "oom\|kill" - 确认 AOF 是否启用：
redis-cli CONFIG GET appendonly。如果appendonly yes且appendfsync everysec，RDB 失败本身不危及数据安全
要缓解脏读，得从应用层和部署层下手
配置层能做的有限，真正可控的是使用方式：
- 读关键业务数据时，强制打向主库，绕过从库（如用
READONLY OFF或连接池路由策略） - 对时效性敏感的 key，避免依赖 TTL 自动过期，改用业务主动
DEL或带时间戳的逻辑判断 - 用
WAIT 1 1000强制写后等待至少 1 个从库确认，缩短不一致窗口（注意性能代价） - 监控
expired_keys和evicted_keys指标突增，这是定期删除跟不上或内存压力大的信号
最常被忽略的一点：很多人以为调大 hz 就能消灭脏读，但实际中，hz 提高后，activeExpireCycle 单次执行时间上限（默认 25ms）也可能导致更多 key 被跳过——它不是线性增强，而是有内在取舍的。
