直接kill -9会导致redis集群节点不执行持久化、不通知下线、不清理nodes.conf，引发clusterdown错误、心跳刷屏及槽位分配失败；重置为干净单机状态须删除nodes.conf、dump.rdb或appendonly.aof，并执行cluster reset hard清除内存集群状态。
redis-cli 发起 SHUTDOWN 是唯一真正“优雅”的起点，其他方式都可能丢数据或破坏集群状态。
为什么不能直接 kill -9？
Redis 集群节点在 kill -9 时不会执行 RDB/AOF 持久化、不通知其他节点下线、不清理 nodes.conf 中的握手状态。后果包括：
• 启动后节点仍认为自己是集群成员，但实际已失联 → 报错 CLUSTERDOWN Hash slot not served
• 其他节点持续尝试向它发送心跳 → 日志刷屏 Node X is suspected to be down
• 即使后续手动 CLUSTER FORGET，也可能因元数据不一致导致槽位分配失败
必须清空哪些文件才能重置为干净单机状态？
仅停服务不够，残留元数据会让新启动的节点“以为自己还在集群里”。每台节点都要删掉：
• nodes.conf（默认在 Redis 工作目录，由 cluster-config-file 配置项指定）
• dump.rdb 或 appendonly.aof（取决于你是否启用 AOF；若要保留数据则跳过此项，但此时不属于“重启集群”，而是“恢复集群”）
• 不要删整个 data 目录——除非你确认里面只有 Redis 文件；有些部署会混放日志或 pid 文件
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
重启顺序和命令怎么写才不出错？
按以下顺序逐台操作（不要并行）：
• 先用 redis-cli -h 127.0.0.1 -p 6379 shutdown 停节点
• 确认进程消失：ps -ef | grep redis-server | grep -v grep 输出为空
• 删除 nodes.conf 和持久化文件
• 启动：redis-server /path/to/redis.conf（确保配置中 cluster-enabled yes 且端口、bind 正确）
• 连上刚启的节点，执行：CLUSTER RESET HARD（这步关键：清除内存里的集群状态，否则它会读取旧 nodes.conf 失败后卡住）
• 再次 shutdown，等所有节点都做完这轮“启动→重置→停机”，再统一执行 redis-cli --cluster create
密码、副本数、IP 写法这些细节容易翻车
--cluster create 命令对参数极其敏感：
• 密码必须用 -a，不能写进 URL（redis://:pwd@host:port 不被支持）
• 所有节点地址必须可互相访问（DNS 要通，防火墙放开端口 + 集群总线端口 = redis_port + 10000）
• --cluster-replicas 1 表示每个 master 配 1 个 slave，总节点数必须满足：master_num * (1 + replicas) == total_nodes
• IP 地址建议全用内网 IP，别混用 hostname 和 IP，redis-cli 解析 hostname 失败时不会报明确错误，只会卡在 “Waiting for the cluster to join…”
真正麻烦的不是命令本身，而是节点间状态不同步：一台漏了 CLUSTER RESET HARD，整条链就挂；一台 nodes.conf 没删干净，新集群初始化会反复失败。动手前最好先在单台机器上跑通全流程。
