Redis只读从库配置：replica-read-only防篡改指南

必须开，且默认就该是 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 就以为万事大吉，忘了它只锁住“此刻是从库”的那个实例，而不是锁住“永远不能写”。