redis集群启动失败、节点无法握手、cluster nodes显示fail或connecting，大概率是bus端口（client port+10000）被占用；需确保各节点client port与其对应bus端口区间互不重叠，如7000→17000，则下一节点client port至少为17001。

Redis 集群启动失败、节点无法握手、CLUSTER NODES 显示 fail 或一直 connecting，大概率是端口冲突——尤其是 Bus 端口（非客户端端口）被占用了。

为什么 Redis 集群要额外开 Bus 端口？

Redis 集群节点之间用两种通信通道：tcp（客户端连接和部分命令）和 bus（集群内部心跳、故障检测、配置更新）。Bus 不复用 client port，而是默认在 client port 基础上 +10000。比如 redis-server --port 7000，它自动监听 17000 作为 bus 端口。

这个机制很隐蔽，但一旦多个实例的 client port 接近（如 6999 和 7000），它们的 bus 端口就会撞车（16999 和 17000 → 重叠或相邻冲突）；或者你手动启了其他服务占了 17000，redis-server 不报错，但集群发现不了彼此。

• Bus 端口不支持自定义名或复用，只能靠规划 client port 来间接控制
• 检查是否启用：启动后执行 redis-cli -p 7000 cluster nodes，若返回空或只有自己且状态为 noaddr，优先查 17000 是否被占用
• netstat -tuln | grep :17000 或 lsof -i :17000 是最直接的验证方式

如何安全规划 client port 以避开 bus 冲突？

核心原则：确保任意两个节点的 client_port 与 client_port + 10000 区间互不重叠。例如 7000 占用 7000–7000（client）和 17000–17000（bus），那下一个节点 client port 至少得 ≥ 17001，否则 bus 端口会和前者的 client port 撞上。

• 推荐方案：所有节点 client port 设为 7000, 7001, 7002, 7003, 7004, 7005 —— 它们的 bus 端口分别是 17000–17005，互不干扰，且远离常用端口段
• 危险组合：不要用 6999 和 7000 同时部署，因为 6999+10000=16999，和 7000 的 client port 就只差 1，某些内核或防火墙策略下仍可能误判为冲突
• 如果机器资源紧张，必须压缩端口范围，可改用 8000, 8001, 8002（bus 为 18000–18002），避开 10000–12000 这类常被 Docker/VM 占用的区间

启动时怎么确认 bus 端口已正确监听？

不能只看 redis-server 日志里有没有 “Ready to accept connections”，还要验证 bus 端口是否真在 LISTEN 状态。Redis 启动成功后，bus 端口必须出现在 netstat 输出中，且进程 PID 和 redis 实例一致。

• 启动命令后立刻执行：ss -tlnp | grep $(pgrep -f "redis-server.*7000")，应看到两行：一行 :7000，一行 :17000
• 如果只看到 client port，说明 bus 初始化失败——常见原因是 bind 配置错误（如 bind 127.0.0.1 但 bus 默认尝试 bind 所有接口），此时需显式设置 cluster-announce-ip 和 cluster-announce-port
• 日志里搜 "Failed to join the cluster" 或 "Unable to send PING"，基本指向 bus 通路不通，不是网络问题就是端口没起来

Bus 端口不像 client port 那样暴露在配置文件里，容易被当成“内部细节”忽略。但集群能否形成、故障转移是否及时，全依赖它。规划时多算一步 +10000，比上线后抓包查 MEET 请求超时省力得多。