必须开，且默认就该是 yes；Redis 6.0+ 默认启用，老版本或手动配置常误设为 no，导致从库可写引发数据不一致；需 CONFIG SET replica-read-only yes 并持久化到 redis.conf。
replica-read-only 配置到底开不开？
开。必须开，且默认就该是 yes。Redis 6.0+ 默认已是 replica-read-only yes，但老版本或手动配置过 redis.conf 的实例常被改成 no，导致从库可写——这不是“功能”，是安全隐患。
从库可写最直接的后果：应用误连从库执行 SET、DEL 或 FLUSHDB，数据瞬间不一致，主从复制不报错，但业务读到脏数据或空值，排查时往往卡在“为什么从库有数据主库没有”。
实操建议：
- 检查当前值：
redis-cli CONFIG GET replica-read-only，返回1) "replica-read-only" 2) "no"就得改 - 运行时启用：
redis-cli CONFIG SET replica-read-only yes（立即生效，无需重启） - 持久化配置：在
redis.conf中确保有replica-read-only yes，避免重启后回退 - 注意：该配置只影响 Redis 自身命令写入，不阻止客户端用
EVAL执行恶意 Lua 脚本绕过（见下一条）
从库能执行 EVAL 吗？replica-read-only 拦不住
replica-read-only yes 只禁用普通写命令（SET、HSET、LPUSH 等），但 EVAL 和 EVALSHA 默认仍可执行——只要脚本里没调用写命令，Redis 就不拦；而一旦脚本里含 redis.call('SET', ...)，它会直接报错 ERR Write commands are not allowed on a read-only replica，但这个报错发生在脚本运行中，不是语法校验阶段。
风险在于：攻击者或误操作的运维可能用 EVAL 读取键再拼接写逻辑，或依赖脚本原子性做非幂等操作，结果在从库上留下中间状态。
实操建议：
- 生产环境从库务必禁用 Lua 写能力：
redis-cli CONFIG SET lua-replicate-commands no（Redis 3.2+） - 更彻底的做法：在
redis.conf加lua-replicate-commands no+replica-read-only yes双保险 - 注意：
lua-replicate-commands no不影响只读脚本（如GET、EXISTS），但会拒绝任何含写操作的EVAL，包括redis.call('INCR')
客户端连错从库还写了数据，怎么快速发现？
没有自动告警。Redis 本身不记录“谁在从库上写了什么”，MONITOR 开销大不能常开，SLOWLOG 也不区分主从上下文。真正能抓到问题的是日志和监控链路。
关键线索藏在 Redis 日志里：当从库收到写命令时，会记一条 Write commands are not allowed on a read-only replica 的 warning，但前提是 replica-read-only yes 已生效；如果它是 no，那就真写了，日志里反而安静无声。
实操建议：
- 所有从库必须开启慢日志并过滤写操作：
slowlog-log-slower-than 0+ 定期 grep"command: (SET|DEL|HSET|LPUSH)" - 用
CLIENT LIST抓活跃连接，结合CLIENT GETNAME或应用层打标（如连接名设为app:order-writer），快速定位异常写来源 - Zabbix/Prometheus 监控
rejected_connections和total_commands_processed的突增，比单看错误日志更早暴露问题
哨兵/集群模式下 replica-read-only 还管用吗？
管用，但只对当前角色生效。哨兵切换后，原主库变从库，replica-read-only 配置依然有效；原从库升主库，该配置自动失效（主库天然可写）。集群模式同理：每个节点按自身角色判断是否只读，不继承集群级策略。
容易踩的坑是：哨兵 failover 后，运维手动改了新主库的 replica-read-only yes（以为要“加固”），结果新主库变只读，整个集群写入中断，且哨兵不会自动纠正这个配置。
实操建议：
- 哨兵部署时，确保
sentinel.conf中sentinel failover-timeout足够长，给主从角色切换留出配置同步窗口 - 禁止在哨兵管理的实例上手动
CONFIG SET replica-read-only—— 改了也白改，下次切换又重置 - 集群模式下，用
CLUSTER NODES查节点 role 字段，比依赖配置文件更可靠
配置本身很简单，麻烦的是角色动态变化时的预期管理。很多人调完 replica-read-only yes 就以为万事大吉，忘了它只锁住“此刻是从库”的那个实例，而不是锁住“永远不能写”。
