CLUSTER FORGET 是唯一能主动抹除 Redis Cluster 节点记录的命令，但仅作用于当前节点本地表且要求目标 node_id 存在；必须按先从后主、逐节点串行执行，并验证 nodes 消失、known_nodes 一致、slots 全覆盖。
CLUSTER FORGET 是唯一能从 Redis Cluster 中主动“抹除”一个节点记录的命令，但它不是万能的删除键——用错时机或顺序，反而会让集群陷入持续广播、节点反复重连、甚至 cluster_state:fail 的状态。
为什么直接执行 CLUSTER FORGET 可能失败
常见现象是命令返回 (error) ERR Unknown node 或静默无响应，根本原因是：CLUSTER FORGET 只作用于**当前连接节点的本地节点表**，且要求目标 node_id 必须存在于该节点的 cluster nodes 输出中。
如果目标节点已彻底宕机超过 cluster-node-timeout（默认 15000ms），多数存活节点会将其标记为 fail 状态，但不会自动从节点列表中清除；而有些节点可能因网络分区或 gossip 延迟，压根没收到它的下线通知，导致其 node_id 在部分节点上仍显示为 handshake 或 noaddr ——这时 CLUSTER FORGET 就会失效。
- 必须先在至少一个仍能连通目标节点（哪怕只返回
noaddr）的节点上执行 - 若所有节点都已将它标记为
fail，但cluster nodes里还列着它，说明它卡在“已知但不可达”状态，此时可执行 - 不能在刚重启、尚未完成 handshake 的新节点上操作 —— 它的节点表是空的
CLUSTER FORGET 的正确执行顺序
清理一个已宕机主节点（含其从节点）时，顺序错误会导致槽位丢失或集群不可用。核心原则：先清从，再清主，且每个 CLUSTER FORGET 都要逐节点发起。
- 用
redis-cli -h {alive_node_ip} -p {port}连到任一健康节点 - 执行
cluster nodes，找到目标节点的完整node_id（如a8081e97862d9cf76c72d364f9a173187376f215） - 对目标节点的所有从节点（
slave行中末尾字段匹配该node_id的那些行），分别连接到它们所在机器，执行CLUSTER FORGET {master_node_id} - 最后，对目标主节点本身（或其
node_id出现在其他节点cluster nodes输出中的任意位置），在每个仍记录它的存活节点上执行CLUSTER FORGET {target_node_id} - 每执行一次
CLUSTER FORGET后，建议等 1–2 秒再执行下一条，避免 gossip 消息冲突
注意：CLUSTER RESET 不是替代方案 —— 它只重置本节点配置，不通知其他节点，极易引发配置分裂。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
批量清理多个失效节点的脚本要点
手动逐个 CLUSTER FORGET 效率低，但并发执行又容易触发节点间 gossip 冲突。稳妥做法是串行 + 节点级隔离：
- 脚本中不要用
redis-cli -c（集群模式会自动重定向，导致 forget 失效）—— 必须用直连模式：redis-cli -h {node_ip} -p {port} - 对每个待清理
node_id，遍历所有存活节点 IP:PORT 列表，向每个节点发送一次CLUSTER FORGET {node_id} - 每次发送后检查返回值，忽略
OK和ERR Unknown node，但遇到ERR Node is not empty要立即停止 —— 说明该节点仍有槽或 key，不能直接 forget - 推荐加
sleep 0.5间隔，防止 TCP 连接堆积
示例片段（Bash）：
for node in $ALIVE_NODES; do echo "FORGET $TARGET_ID on $node" echo "CLUSTER FORGET $TARGET_ID" | redis-cli -h $(echo $node | cut -d: -f1) -p $(echo $node | cut -d: -f2) 2>/dev/null | grep -q "OK" && echo "done" || echo "skip" sleep 0.5 done
清理后必须验证的三个状态
执行完所有 CLUSTER FORGET 并等待 10–20 秒后，不能只看 cluster info 的 cluster_state:ok —— 这个字段有时会假阳性。
- 在每个存活节点上运行
cluster nodes，确认目标node_id已完全消失（不是变成fail或noaddr） - 检查
cluster_known_nodes数值是否与实际存活节点数一致 - 运行
cluster slots，确认 16384 个槽仍全部被覆盖，且没有0-16383区间外的异常范围
最容易被忽略的是：即使 CLUSTER FORGET 成功，如果之前该节点负责的槽未被重新分配，集群仍会处于 cluster_state:fail。所以清理节点 ≠ 释放槽位 —— 槽迁移是独立步骤，别混为一谈。
