Redis Cluster 从5.0起集成于redis-cli，需正确配置cluster-enabled、cluster-config-file、cluster-node-timeout、bind和protected-mode，并用--cluster-replicas指定副本数，确保槽位全覆盖且开放服务端口与集群总线端口（+10000）。
原生 Redis Cluster 不依赖外部工具（比如旧版的 redis-trib.rb），从 Redis 5.0 起已完全集成进 redis-cli，只要版本 ≥5.0（推荐 6.2+ 或 7.x），就能用一条命令完成初始化。关键不是“能不能搭”，而是“节点配置对不对、网络通不通、槽位分没分完”。
redis.conf 必须开启 cluster-enabled 并配对 cluster-node-timeout
每个节点的 redis.conf 文件里，这几项是硬性门槛：
-
cluster-enabled yes—— 不开这个，redis-server启动后压根不进入集群模式，后续所有cluster meet或--cluster create都会失败 -
cluster-config-file nodes-6379.conf—— 必须可写，且不同端口节点不能共用同一文件（否则启动时会抢锁或覆盖） -
cluster-node-timeout 5000—— 建议设为 5000~15000 毫秒；太小（如 1000）会导致网络抖动时频繁误判节点下线；太大则故障转移延迟高 -
bind和protected-mode no—— 如果节点间走内网 IP（如192.168.57.100），必须显式bind 192.168.57.100，不能只留127.0.0.1；protected-mode no在内网环境必须关，否则其他节点连不上
redis-cli --cluster create 命令要带 --cluster-replicas 参数
这是最容易漏掉也最致命的一点：不加 --cluster-replicas 1（或对应数字），redis-cli 默认不会自动分配从节点，6 个节点全被当主节点用，导致槽位分配失败（报错 ERR Invalid argument: expected 'replicas' count 或卡在 “Waiting for the cluster to join…”）。
正确命令示例（3 主 3 从）：
redis-cli --cluster create \ 192.168.57.100:6379 \ 192.168.57.101:6379 \ 192.168.57.102:6379 \ 192.168.57.100:6380 \ 192.168.57.101:6380 \ 192.168.57.102:6380 \ --cluster-replicas 1
注意：
- IP:port 列表顺序无关，但总数必须是
主节点数 × (1 + replicas)，比如 3 主 × (1+1) = 6 个地址 - 它会自动把后一半节点设为前一半的从节点，不需要提前执行
cluster replicate <node-id> - 首次运行会提示
Can I set the above configuration?，输yes才真正写入nodes-*.conf
集群启动后必须检查 CLUSTER NODES 输出是否全覆盖 0-16383 槽位
哪怕 redis-cli --cluster create 显示 “All 16384 slots covered”，也不能信。得手动验证：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -c -h 192.168.57.100 -p 6379 cluster nodes | grep master
每行末尾应有类似 0-5460 5461-10922 10923-16383 的槽范围，且三行合起来正好覆盖 0-16383，无重叠、无空缺。
常见问题：
- 某 master 行末尾是
0-0或空 —— 说明槽没分进去，可能因为该节点启动时cluster-config-file被其他进程锁住，或磁盘满导致写失败 - 出现
fail?或handshake状态 —— 节点间 TCP 连通性有问题，重点查telnet 192.168.57.101 6379和集群总线端口（默认6379 + 10000 = 16379） -
redis-cli -c写入数据返回MOVED但不自动跳转 —— 客户端没启用集群模式，要用-c参数，或代码里用支持 Cluster 的 SDK（如 JedisCluster、redis-py-cluster）
防火墙和集群总线端口经常被忽略
Redis Cluster 节点之间不仅走服务端口（如 6379），还额外使用「集群总线端口」通信：默认是 服务端口 + 10000（即 6379 → 16379，7000 → 17000）。如果只开了 6379，握手能成功，但后续槽同步、故障检测、gossip 传播全卡死。
检查方式：
- 在任一节点执行
redis-cli -h 127.0.0.1 -p 6379 cluster nodes，看输出里各节点 IP:port 是否都可达 - 用
ss -tlnp | grep 16379确认总线端口确实在监听（绑定的是0.0.0.0:16379，不是127.0.0.1） - Linux 防火墙（firewalld/iptables）、云厂商安全组，都要放行服务端口 + 总线端口两个范围
实际部署中，80% 的“集群看起来起来了但不工作”问题，都卡在这两个端口之一没放开，或者 bind 写错了 IP 导致总线绑在了回环地址上。
