Redis主从架构中如何防止从库误写入脏数据-Redis-PHP中文网

必须开replica-read-only yes，它是协议层拦截写命令的保险栓；redis 6.0+默认启用，但老版本或手动配置常设为no，导致从库可写引发数据不一致，需config set即时生效并持久化到redis.conf。

redis主从架构中如何防止从库误写入脏数据

必须开 replica-read-only yes，且不能只靠它拦住所有写入——服务端配置、客户端连接方式、应用逻辑三者缺一不可。

这个配置不是“让从库只读”，而是协议层拦截写命令的保险栓。Redis 6.0+ 默认是 yes，但老版本或手动改过 redis.conf 的实例常被设为 no，导致从库真能接收 SET、DEL 等写命令：

很多人以为设了 yes 就万事大吉，其实以下场景仍可能“写成功”或造成等效脏写：

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

本地连接（redis-cli -h 127.0.0.1）在某些 Redis 版本 + ACL 配置下可能绕过限制
EVAL 脚本：即使 replica-read-only yes，脚本里调用 redis.call('SET', ...) 会在运行时报错，但 GET+SET 组合逻辑可能已读到中间态
ACL 权限覆盖：如果用户有 +@all 或显式 +set 权限，会优先于 replica-read-only 生效
运维误操作：手动 CONFIG SET replica-read-only no 调试后忘记恢复，又没进配置中心流程，比配置本身更难追踪

服务端只拦命令，不拦连接。客户端若把从库当主库用，照样发 SET，错误只在执行时抛出，此时业务逻辑可能已崩：

Lettuce 必须用 ReadFrom.SLAVE_PREFERRED 或 ReadFrom.SLAVE，且禁止在该连接上调用 sync().set() 类方法
redis-py 不自动路由，需严格区分两个连接实例：redis.Redis(host="master") 专用于写，redis.Redis(host="slave") 实例禁用所有写方法封装
Spring Data Redis 中，RedisTemplate 若配了哨兵或集群，要确认 setEnableTransactionSupport(false)，事务在从库无意义且易掩盖问题

光设对配置远远不够。最容易被忽略的是监控盲区和临时改动：

定期用脚本检查所有从库的 CONFIG GET replica-read-only 和 INFO replication | grep role，值不是 yes 或角色不是 slave 就告警
禁止应用直连从库做任何写逻辑——这不是靠 replica-read-only 拦得住的，得在服务发现层（如 Nacos、Consul）或 SDK 层强制读写分离路由
对强一致 key（如库存、订单状态），不要依赖从库读，哪怕加了 WAIT；WAIT 只保证传播，不保证执行，从库卡在 BGSAVE 或慢查询时，DEL 仍在缓冲区排队