redis从节点设为可写后执行set等命令会直接污染数据，导致主从逻辑不一致、类型冲突、复制中断且无法自动修复，必须人工清空并重同步。
从节点执行 SET 等写命令会直接污染数据
Redis 从节点默认是只读的（slave-read-only yes），但若被手动设为可写（CONFIG SET slave-read-only no），后续在从节点上执行 SET、HSET、LPUSH 等任何写命令，都会直接修改本地内存数据，而这些变更不会同步到主节点，也不会广播给其他从节点。此时主从数据立即出现逻辑性不一致——不是延迟问题，而是“根本就不是同一份数据”。
- 这种写入不触发复制流，主节点
INFO replication中的master_repl_offset完全不受影响 - 从节点自身
slave_repl_offset仍按主节点指令推进，但实际数据已偏离复制上下文 - 即使之后主从重连、offset 追平，这些人为写入的 key 依然残留，成为“幽灵脏数据”
slave-read-only no 后的写操作无法被自动清理
运行时执行 CONFIG SET slave-read-only no 不会清空已有数据，也不会标记哪些 key 是“非复制写入”。重启从节点后该配置失效（恢复为 yes），但之前写入的数据仍在——dump.rdb 或 appendonly.aof 文件里已经固化了这些非法变更。
- 没有机制区分“复制来的 key”和“人工写的 key”，Redis 不记录来源元信息
- 即使主节点 later 执行
DEL，该删除命令只会发给从节点执行一次；如果从节点此前自己写过同名 key，且 TTL 不同或类型冲突，结果不可预测 - 使用
REPLICAOF切换主节点时，旧写入数据不会被自动丢弃，反而可能干扰新同步流程
某些数据结构操作在从节点写入会引发类型错乱
比如在从节点执行 SET user:123 "abc"，而主节点对应 key 实际是 HASH 类型（HSET user:123 name "Alice" age 30）。此时从节点的字符串值与主节点的 HASH 值完全不兼容，后续主节点发来 HDEL 或 HGETALL 命令会在从节点报 WRONGTYPE Operation against a key holding the wrong kind of value 错误，复制中断，offset 停滞。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 错误不会回滚，从节点卡在失败命令处，不再继续处理后续命令流
- INFO replication 显示
slave_repl_offset滞后且不再增长，但连接状态仍是connected_slaves: 1 - 这种不一致无法靠等待或重连修复，必须人工介入清空数据并重做全量同步
验证从节点是否已被污染的最快方式
不要只看 connected_slaves 或 role:slave，关键查三件事：
- 执行
CONFIG GET slave-read-only—— 确认当前值是yes，不是no - 执行
INFO replication，比对master_replid是否与主节点一致（用redis-cli -h $MASTER info replication | grep master_replid获取） - 随机抽样几个业务 key，用
TYPE+GET/HGETALL对比主从返回结果是否完全一致，尤其注意 TTL 和编码类型（如ziplistvshashtable）
只要有一个 key 的 TYPE 或内容不一致，就说明从节点已被写入污染，不能继续用于读服务，必须走停机清空 + 全量重同步流程。
