redis 6.0从节点开启replica-read-only yes后全局只读，不支持按key选择性写入；任何写命令均立即返回readonly错误，该限制在命令执行前硬拦截，与acl、lua、模块无关。
Redis 6.0 从节点默认是只读的，但不能“选择性写入”
直接说结论：replica-read-only yes（或 slave-read-only yes）开启后，整个从节点对所有客户端都是只读的；Redis 原生不支持“仅允许某些 Key 写入从节点”的机制。这不是配置遗漏，而是设计限制——从节点的数据必须严格跟随主节点，任何本地写入都会破坏复制一致性。
为什么不能在从节点上对特定 Key 执行 SET、INCR 等命令
尝试在开启了 replica-read-only yes 的从节点上执行写命令，会立即返回错误：
READONLY You can't write against a read only replica.
这个检查发生在命令执行前，由 server.masterhost != NULL 和 server.repl_slave_ro 共同触发，**不区分 Key、不走 ACL、不经过 Lua 或模块拦截**。即使你用 ACL SETUSER 赋予用户写权限，或用 Redis Module 注册命令，只要节点处于从属状态且 replica-read-only 为 yes，所有写命令一律拒绝。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
替代方案：用命名空间 + 主节点路由 + 客户端逻辑兜底
真正可行的做法，是把“看起来像从节点写入”的需求，拆解到客户端或代理层实现：
- 约定一类 Key 使用特殊前缀（如
local:或tmp:），客户端检测到该前缀时，**自动将请求发往主节点**，而非当前连接的从节点 - 在应用代码中封装统一的读写路由逻辑，例如：
cache.get("user:123")走从节点，cache.set("local:session:abc")强制走主节点 - 若使用 Redis Proxy（如 Twemproxy、RedisShake、或自研中间件），可在 proxy 层解析命令和 Key，对匹配模式的写命令重定向到 master
- 注意：不要依赖
READONLY命令切换从节点读写状态——它只影响当前连接，且 Redis 6.0+ 已标记为 deprecated；更关键的是，即使设为READWRITE，从节点写入也会在下一次全量同步或部分重同步时被主节点数据覆盖，导致数据丢失
容易被忽略的关键点
很多人试图用 CONFIG SET replica-read-only no 临时关闭只读，再配合 WATCH 或 EVAL 实现条件写入——这完全不可靠。一旦发生主从故障转移（比如哨兵切换或 Cluster failover），该从节点可能变成新主节点，而之前写入的“本地 Key”就变成了脏数据源；更糟的是，如果它又降级回从节点，这些 Key 会被主节点数据强制覆盖，造成静默丢失。
真正的边界在于：**Redis 复制协议不保证从节点的本地写入可收敛。只要节点身份是 replica，它的数据权威性就只来自 master —— 这不是配置问题，是模型约束。**
