FLUSHALL在Redis集群中不会自动广播到所有节点，必须显式对每个主节点执行，否则数据清空不完整；实际只清除当前连接节点负责槽位的数据，其余节点数据完好，需通过脚本遍历所有主节点逐一执行。
FLUSHALL 在 Redis 集群中不会自动广播到所有节点，必须显式对每个主节点执行，否则数据清空不完整。
FLUSHALL 在集群里不是“一键全清”
很多人误以为连接任意一个节点执行 FLUSHALL 就能清掉整个集群——这是错的。Redis 集群本身不支持跨槽（cross-slot）命令，FLUSHALL 属于全局命令，但集群代理（如 redis-cli --cluster 或客户端库）**不会自动转发它到所有分片**。实际效果是：只清掉你当前连接的那个节点负责的哈希槽范围内的 key，其余节点数据完好无损。
常见错误现象：
- 执行
redis-cli -h 127.0.0.1 -p 7000 FLUSHALL后，用redis-cli -h 127.0.0.1 -p 7001 DBSIZE检查发现仍有大量 key 存在 - 监控显示部分节点
keys数为 0，另一些仍维持高位 - 业务侧缓存未失效，或下游报“数据还在但逻辑异常”，本质是数据残留导致状态不一致
正确做法：逐个向主节点发送 FLUSHALL
必须手动或脚本化地遍历所有主节点（master），分别建立连接并执行 FLUSHALL。不能依赖从节点，因为 FLUSHALL 只对主节点生效（从节点拒绝执行写命令）。
实操建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先用
redis-cli --cluster check 127.0.0.1:7000确认集群拓扑，提取所有主节点地址（含端口） - 避免用
--cluster call：虽然redis-cli --cluster call <host>:<port> FLUSHALL看似便捷，但它只对指定节点执行，不自动枚举全部；需配合 shell 循环 - Python 示例（使用
redis-py-cluster时注意：v2.x 已弃用StrictRedisCluster，改用RedisCluster）：
from redis.cluster import RedisCluster
rc = RedisCluster(startup_nodes=[{"host": "127.0.0.1", "port": "7000"}], decode_responses=True)
for node in rc.get_primaries(): # 只取主节点
node.flushall()⚠️ 注意：get_primaries() 返回的是主节点连接对象，不是字典；若用旧版 redis-py（CLUSTER NODES 输出。
权限与禁用配置会拦截 FLUSHALL
即使你连对了主节点，FLUSHALL 也可能被静默拒绝：
- 配置了
rename-command FLUSHALL ""→ 执行时报(error) ERR unknown command 'FLUSHALL' - 启用了 ACL（Redis 6+），用户没
@admin权限 → 报(error) NOPERM this user has no permissions to run the 'flushall' command - 华为云 DCS 等托管服务默认禁用
FLUSHALL，控制台“数据清空”功能底层也是逐节点调用，且仅限 Redis 4.0+
验证方式：连接后执行 COMMAND 查看返回列表是否含 flushall；或直接试跑，观察返回是否为 OK。
清空后从节点不会自动同步，需人工干预
主节点执行 FLUSHALL 后，从节点不会立刻清空——它们仍保留原有 RDB/AOF 数据，直到下一次全量同步（full sync）或部分重同步（PSYNC）发生。这意味着：
- 刚清完主节点，立刻读从节点可能拿到“脏数据”（旧 key）
- 如果从节点启用了
slave-read-only no，甚至可能接受写入，进一步加剧不一致 - 最稳妥的做法是：清完所有主节点后，对每个从节点也单独执行一次
FLUSHALL（需临时开启写权限）或重启从节点使其重新拉取空白状态
真正麻烦的从来不是“怎么清”，而是“清完之后，哪些地方还藏着旧数据”。尤其当集群混用读写分离、多级缓存或本地缓存时，FLUSHALL 只解决 Redis 层，其他层得另想办法。
