Redis集群不支持FLUSHALL和FLUSHDB命令，因其无法跨slot执行，属协议层面硬性限制；必须逐个连接主节点，用SCAN+DEL分批清理。
直接执行 FLUSHALL 在集群中会失败
Redis 集群不支持 FLUSHALL 或 FLUSHDB 这类全局命令，因为它们无法跨 slot 执行。任意节点上执行 FLUSHALL 会报错 ERR unknown command 'flushall' or not supported in cluster mode。这不是权限或配置问题，而是集群协议层面的硬性限制。
所以别试 redis-cli -c -h node:port flushall —— 它根本不会生效，只会返回错误或静默失败（取决于客户端实现）。
- 集群中每个 key 属于固定 slot，而
FLUSHALL要求遍历所有 db 和所有 slot，这与去中心化设计冲突 - 即使你连的是主节点，它也无法协调其他分片执行清空操作
- 某些封装库（如 Node.js 的
ioredis）在 cluster 模式下会自动降级或抛异常，但底层仍是协议拒绝
SCAN + DEL 分批删除是唯一通用方案
必须用 SCAN 遍历每个节点上的 key，再分批 DEL。不能依赖 KEYS *，否则单次扫描可能阻塞整个节点数秒甚至更久，尤其当 key 数量 > 百万级时。
关键不是“能不能删”，而是“怎么删不拖垮集群”。实操要点：
- 对每个主节点单独连接（不要用 cluster client），用
redis-cli -h ip -p port直连其地址 - 用
redis-cli --scan --pattern "your:prefix:*"流式获取 key，避免内存爆掉 - 用
xargs -n 1000 redis-cli -h ip -p port del控制每批最多删 1000 个，防止单次命令包过大或超时 - 若需全量清空，pattern 用
*，但务必加--scan（等价于SCAN命令），而非keys * - 从节点只读，
DEL会返回(error) READONLY You can't write against a read only replica，跳过即可
Lua 脚本能减少 RTT，但要注意超时和 OOM
把 SCAN + DEL 逻辑写进 Lua 脚本，在服务端一次性执行，确实能省掉网络往返。但生产环境要谨慎：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 脚本运行期间会阻塞当前节点的其他请求，单次执行超过
lua-time-limit（默认 5 秒）会被强制中断并报错BUSY - 如果匹配 key 过多（比如百万级），脚本内部 table 存储所有 key 可能触发内存溢出，Redis 会 kill 掉该脚本
- 集群模式下 Lua 脚本只能操作当前节点的 key，仍需逐个节点调用，无法“一键集群清理”
- 示例安全写法：每次
SCAN最多取 100 个 key，DEL后立即return，靠外部循环驱动
典型调用：redis-cli -h 10.0.1.10 -p 7001 --eval script.lua 0 prefix，其中 script.lua 不得包含大数组或无限循环。
哨兵模式和单节点可直接用 FLUSHALL，但集群不行
这是最容易混淆的点：哨兵（Sentinel）只是高可用架构，底层仍是单主多从，FLUSHALL 在主节点上完全合法；而集群（Cluster）是分片架构，FLUSHALL 天然不可用。
如果你误把集群当哨兵用，连上某个节点后发现 FLUSHALL 报错，第一反应不该是“密码不对”或“权限不够”，而是确认部署模式：
- 执行
redis-cli -h node info | grep cluster，看cluster_enabled:1就是集群 - 执行
redis-cli -h node role，返回master+connected_slaves是哨兵或单机主从 - 集群节点的
redis-cli -c连接会显示127.0.0.1:7001>，而哨兵模式通常直连主节点 IP，无-c参数
真正麻烦的不是技术方案，而是搞错架构类型后反复踩同一个坑——删不掉不是命令写错了，是压根没走对路。
