Redis 从节点默认启用只读保护，该功能由sla ve-read-only（或replica-read-only）配置控制。运行时可通过INFO replication查看状态，当role=sla ve且sla ve_read_only=1时，就可以确认只读保护已经生效。此时，客户端执行写命令会直接报错“READONLY You can't write against a read only sla ve”。
可以，但必须明确：Redis 从节点是否禁止写入，核心只依赖 sla ve-read-only（或新版 replica-read-only）配置项，而且它只对客户端写命令有效，并不能阻止内部操作或管理类命令。
这个配置并不是“可有可无”的功能，而是 Redis 的默认安全机制——自 Redis 2.6 起，所有从节点默认就是 sla ve-read-only yes。只要主从复制开启，客户端执行 SET、DEL 等写入命令时，就会直接收到错误提示：(error) READONLY You can't write against a read only sla ve.
怎么确认从节点已启用只读保护
不要只看配置文件，最终以运行时状态为准：
- 先检查配置文件中是否设置了
sla ve-read-only yes（Redis < 5.0）或replica-read-only yes（Redis ≥ 5.0）。旧版参数名在新版本中通常仍可兼容，但建议统一使用新参数名，便于维护和排查 - 连接从节点后执行
CONFIG GET sla ve-read-only或CONFIG GET replica-read-only，确认返回值为"yes" - 再执行
INFO replication，确认当前实例为role:sla ve，且master_host不为空；如果显示的是role:master，说明它已经脱离主从复制关系，此时该只读配置自然不会继续生效
为什么改了配置还是能写？常见误判点
报错消失并不等于真正允许写入，很多所谓“从节点能写”的情况，其实是绕开了只读限制：
sla ve-read-only no属于高风险操作，通常只适用于极少数临时调试场景；如果没有写回配置文件并重新加载，重启后一般会失效CONFIG SET sla ve-read-only no可以在运行时动态关闭只读，但这个修改不会持久化，Redis 服务重启后仍会恢复默认的yesSLA VEOF NO ONE会让从节点提升为主节点，一旦实例角色发生变化，sla ve-read-only就不再生效——因为它此时已经不是从节点，而是可写的主节点CONFIG、DEBUG、MODULE等管理命令默认依然可执行，即便实例处于只读模式，也可能通过CONFIG SET修改自身配置，因此必须配合rename-command或 ACL 进行限制
Redis Cluster 中从节点的只读行为不一样
在 Cluster 模式下，并不存在传统意义上的 sla ve-read-only 配置项，它的只读机制是由系统逻辑直接控制的：
- Cluster 的从节点（replica）默认拒绝所有客户端写命令，不受配置项影响，
sla ve-read-only参数在 Cluster 模式下完全无效 - 只读状态会在通过
CLUSTER REPLICATE建立复制关系后自动生效，无法通过 config 命令关闭 - 如果想让 Cluster 从节点接受写入，常规方式不可行。唯一合规的方法是执行
CLUSTER FAILOVER触发故障转移，让该节点切换为 master——但这本质上是角色变更，而不是简单关闭只读
真正要防住写入，光靠 sla ve-read-only 不够
因为它只能拦截普通客户端写命令，无法覆盖以下三类风险：
- ACL 用户权限没有收紧：即使 Redis 从节点处于只读模式，只要用户仍拥有
+@all之类的高权限，就可能通过CONFIG SET关闭只读保护 - 危险命令未禁用：
CONFIG、DEBUG、MODULE等命令默认开放，建议通过rename-command CONFIG ""或 ACL 明确屏蔽 - 运维误操作：例如使用
redis-cli -h sla ve-host -p 6379直接连接后执行SLA VEOF NO ONE，会立即打破从节点的只读边界
在生产环境中，建议在配置文件里明确写入 sla ve-read-only yes，并结合 ACL 严格限制管理类命令。同时，要持续关注 INFO replication 中 role 与 sla ve_read_only 字段的变化。通常来说，任何“Redis 从节点变成可写”的现象，几乎都不是只读开关本身失效，而是角色切换、权限配置不当或管理操作失控所导致的。
