redis从库默认只读，slave-read-only yes是防意外写入的保险栓；设为no后从库可写但导致主从数据不一致，因写命令不回传主库且故障转移会扩散脏数据。
Redis 从库默认就是只读的，slave-read-only yes 不是“开启只读”的开关，而是防止意外写入的保险栓——关掉它，从库就真能被写，但数据立刻不一致。
为什么从库写入会导致数据不一致
主从复制是单向异步的：所有写命令只在主库执行，再通过 replication backlog 或 psync 同步给从库。如果人为在从库执行 SET、DEL 等写命令：
- 这些变更不会同步回主库，主库不知道自己“被改了”
- 主库宕机后若发生故障转移，该从库升为主库，脏数据就变成合法数据
- 其他从库重新同步时会拉取这个错误状态，扩散不一致
slave-read-only 的真实作用和常见误操作
这个配置不是“让从库只读”，而是“阻止客户端执行写命令”。它的行为受启动时机和配置方式影响：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须在从库启动前通过
redis.conf设置slave-read-only yes（默认值），运行中用CONFIG SET slave-read-only yes也生效 - 设为
no后，普通客户端（非MONITOR或DEBUG）可正常写入，但INFO replication里仍显示role:slave - 即使设为
yes，本地连接（127.0.0.1）或管理员用户（启用requirepass且有admin权限）仍可能绕过限制，取决于 Redis 版本和 ACL 配置
验证从库是否真正只读的实操检查项
别只看配置文件，要动手测：
- 用非本地地址连接从库（如
redis-cli -h 192.168.1.10 -p 6379），执行SET test 1—— 应返回(error) READONLY You can't write against a read only replica. - 检查
CONFIG GET slave-read-only和INFO replication | grep role，确认值为yes且角色是slave - 如果用了 Redis 6+ ACL，确认连接用户没有
+@all或显式+set权限；ACL 权限优先级高于slave-read-only
生产环境必须同步做的三件事
光设 slave-read-only yes 不够：
- 在
redis.conf中显式写死该配置，避免容器重启或配置中心下发时遗漏 - 监控脚本定期检查所有从库的
slave-read-only值和connected_slaves数量，异常立即告警 - 禁止应用直连从库做写操作——这不是靠配置拦得住的，得从服务发现和客户端 SDK 层面隔离读写路由逻辑
最危险的情况不是配置没开，而是开发测试时手动 CONFIG SET slave-read-only no 调试完忘了恢复，又没进配置管理流程。这种临时改动比配置本身更难追踪。
