redis集群无内置自动发现服务，新节点必须显式执行cluster meet命令向已有节点发起握手，之后依赖gossip协议在1–2秒内被动扩散节点信息，传播依赖集群总线端口连通性。
Redis集群本身没有“自动发现服务”，节点加入必须显式执行 CLUSTER MEET；所谓“自动”是Gossip协议驱动的被动传播，不是零配置即连。
CLUSTER MEET 是唯一手动入口
新节点启动后，不主动广播自己，也不监听其他节点。它必须由运维或脚本调用 CLUSTER MEET ip port 命令，向集群中一个已有节点发起握手请求。这个动作不可省略，也没有替代命令。
- 执行后，目标节点会将该新节点加入自己的
clusterNode列表，并在下次 Gossip 中携带其信息 - 如果集群有多个节点，仅对其中一个执行
CLUSTER MEET就够了——其余节点会在几秒内通过 Gossip 自动获知 - 误操作风险：对已存在的节点重复执行
CLUSTER MEET不报错但会重置连接状态，可能触发短暂的CLUSTERDOWN报警
Gossip 协议负责后续扩散
每个节点每秒随机选取最多 5 个已知节点，发送 ping 消息（含自身节点信息、槽位分配、配置纪元等）。接收方解析后，若发现未知节点，就将其加入本地节点表，并在下一轮 ping 中转发出去。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 传播延迟通常在 1–2 秒内，但不保证强实时；极端网络分区下，部分节点可能长期“看不见”新成员
-
ping和pong消息走的是集群总线端口（默认16379），不是客户端端口；防火墙必须放行该端口，否则 Gossip 断裂 - 节点不会主动拉取全量拓扑，只靠收到的增量消息拼凑视图；因此
CLUSTER NODES输出可能短暂不一致
从节点如何被集群识别？
主节点启动后，从节点不能靠自己“注册”。它必须由主节点通过 CLUSTER REPLICATE <node_id></node_id> 显式指定归属，之后主节点会在 Gossip 中广播这条复制关系。
- 从节点上线后，若未被任何主节点执行
CLUSTER REPLICATE，它始终处于孤立状态，CLUSTER NODES中显示为noaddr或fail - 主节点故障时，从节点能否被选举取决于它是否已在集群中被“看见”——即是否已通过
CLUSTER REPLICATE被纳入拓扑 - 注意：
replica-of配置项（redis.conf）仅控制启动时的复制源，不参与集群拓扑注册；必须配合CLUSTER REPLICATE才生效
真正容易被忽略的是：Gossip 的有效性完全依赖节点间双向通信畅通，而不仅仅是客户端能连通。集群总线端口不通、时钟不同步超 500ms、配置纪元冲突，都会导致节点“存在但不可见”。
