不能直接用 redis-cli --cluster create 跨子网初始化集群，必须用 cluster meet 手动握手，因跨子网时总线端口（port+10000）常被防火墙/nat阻断，而 cluster meet 仅需客户端端口可达即可触发 gossip 自动传播，是唯一绕过初始总线连通性硬依赖的方式。
不能直接用 redis-cli --cluster create 跨子网初始化集群，必须用 CLUSTER MEET 手动握手，否则节点间连不通总线端口（port + 10000），集群卡在 connecting 或反复 fail 状态。
为什么 CLUSTER MEET 是跨子网唯一可行的起点
自动工具如 redis-cli --cluster create 依赖所有节点能双向直连客户端端口和集群总线端口（比如 7000 和 17000），而跨子网时防火墙/NAT/路由策略常阻断 17000 端口。但 CLUSTER MEET 是纯应用层命令：只要目标节点的客户端端口（如 7000）可达，就能触发握手流程，后续靠 gossip 自动传播——这是唯一能绕过初始总线连通性硬依赖的方式。
- 前提是每个节点的
redis.conf已提前配置好cluster-announce-ip和cluster-announce-bus-port，否则握手成功后重定向或从节点加入仍会失败 -
CLUSTER MEET是单向命令：A 向 B 发送，只让 A 认识 B；要全网互通，需对每对节点补全双向MEET，或至少确保每个节点都MEET过集群中某个“枢纽节点” - 执行后立刻返回
OK，不代表握手完成——需等几秒再查CLUSTER NODES，看状态是否变为connected
CLUSTER MEET 前必须显式配置的三个参数
若跳过这步，节点广播的地址是本机 bind 地址（如 10.0.1.10），其他子网节点根本无法访问，导致后续 CLUSTER REPLICATE 失败或客户端重定向到错误 IP。
-
cluster-announce-ip 192.168.20.5：填其他子网节点能实际路由到的 IP，不是127.0.0.1或内网不可达地址 -
cluster-announce-port 7000：客户端端口，保持与port一致即可 -
cluster-announce-bus-port 17000：必须显式声明！默认按port + 10000算，但云厂商安全组常漏放此端口，显式写死便于统一开防火墙
配置完必须重启 Redis：CONFIG REWRITE 不会持久化这些 announce 参数。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
跨子网主从配对必须手动执行 CLUSTER REPLICATE
--cluster-replicas 1 会把主从全塞进同一子网，失去高可用意义。正确做法是先建主节点集群，再跨子网指定从节点。
- 先用
redis-cli -h 192.168.10.10 -p 7000 CLUSTER MEET 192.168.20.20 7003把所有主节点拉通（比如 3 个主节点，分别在不同子网） - 用
redis-cli -p 7000 CLUSTER NODES查出主节点 ID（第一列），例如d378ca9057747ed4643e9604de048c72b1e37ebc - 再登录从节点所在机器：
redis-cli -h 192.168.20.20 -p 7003 CLUSTER REPLICATE d378ca9057747ed4643e9604de048c72b1e37ebc - 检查：从节点执行
CLUSTER NODES应显示slave且有对应主节点 ID；主节点应显示该从节点为slave
验证连通性时最容易忽略的两个检查点
很多人卡在 “CLUSTER NODES 显示 connected，但 CLUSTER INFO 一直 cluster_state:fail”，问题往往不在命令本身。
- 用
telnet 192.168.20.20 17003和telnet 192.168.10.10 17000双向测试总线端口——这是最直接的连通性证据，比 ping 或客户端端口测试更关键 - 确认所有节点都禁用了
cluster-require-full-coverage yes，否则任一子网短暂中断就会让整个集群降级为fail状态
跨子网集群的脆弱点不在命令怎么敲，而在地址宣告是否真实、端口是否真正打通、主从是否人为跨网绑定——这三个环节漏掉任何一个，都会让集群看起来“活”着，实则无法承载故障转移。
