Redis Cluster 是 Redis 官方提供的分布式方案，它通过分片将键分散到多个节点，每个节点只承载一部分数据。在实际运维中，有时已经有一个集群正在运行，需要把一个新启动的 Redis 实例添加进去。redis-cli --cluster add-node 可以完成这个操作，但它的底层其实依赖了 CLUSTER MEET 命令。直接使用 CLUSTER MEET 能够更精细地控制节点加入过程，也适合用来理解集群的成员发现机制。在 Windows 系统里，可以借助单机多实例的方式模拟集群，Redis 程序通常放在 C:Redis 目录，每个实例使用独立的端口和配置文件。
CLUSTER MEET 命令的作用与原理
CLUSTER MEET 的完整语法是 CLUSTER MEET ip port，其中 ip 和 port 是要加入集群的目标节点地址。执行该命令的节点会主动向目标节点发送一个 MEET 消息，目标节点收到后会尝试与来源节点建立 TCP 连接，双方开始交换集群元数据。这个过程基于 Redis 的 Gossip 协议，节点之间会周期性传播自己所知的其他节点信息，因此只要一个节点成功认识了另一个节点，经过若干轮消息传播，整个集群的所有节点最终都会相互认识。
需要明确的是，CLUSTER MEET 只是建立节点间的成员关系，并不会自动进行槽位迁移。在 Redis Cluster 中，槽位是数据分布的核心，一共 16384 个哈希槽。如果新加入的节点没有分配任何槽位，它将处于主节点但无数据服务的状态，集群状态依然可能是 ok，因为槽位仍由原有节点覆盖。要让新节点真正承载数据，还需要使用 CLUSTER ADDSLOTS 或 CLUSTER SETSLOT 命令分配槽位，或者借助 redis-cli --cluster reshard 完成槽位迁移。
从节点发现的角度看，CLUSTER MEET 触发的是一次定向握手。Redis 节点在正常运行时也会定期通过 PING、PONG 消息交换已知节点列表，但这个过程依赖节点之间已经建立连接。当一个全新的节点启动后，它只认识自己，其他节点也不知道它的存在。CLUSTER MEET 打破了这种信息孤岛，让一个已有节点把新节点的地址告诉给目标节点，从而完成首次接触。后续的信息扩散则完全交给 Gossip 协议完成。
Windows 环境下准备多个 Redis 实例
在 Windows 上手动模拟 Redis Cluster，首先要准备 Redis 的可执行文件。推荐下载 Windows 版 Redis 的 zip 包，将其解压到 C:Redis 目录。复制多份配置文件，例如在 C:Redis7000 和 C:Redis7001 目录下分别放置 redis.windows.conf 文件。每个节点需要修改这几个关键参数：port 7000、cluster-enabled yes、cluster-config-file nodes-7000.conf、appendonly yes、logfile C:Redis7000redis.log。如果希望节点绑定本地地址，可以设置 bind 127.0.0.1，但注意不要设置 protected-mode yes 导致无法连接。
启动命令可以使用 redis-server.exe C:Redis7000redis.windows.conf。在 Windows 命令行中，路径分隔符必须是反斜杠，不能写成斜杠。用同样的方法启动 7001、7002 等多个端口实例。启动后，每个实例会在对应目录下生成 nodes-7000.conf 等文件，记录集群节点 ID 和槽位信息。如果之前有旧的节点文件，建议先删除，避免残留旧集群状态影响测试。
这里有一个常见坑：Windows 下 Redis 的 cluster-config-file 参数需要确保有写入权限。很多用户在 Program Files 目录下运行会报错，因此建议将 Redis 放在 C:Redis 或用户目录下，而不是 C:Program FilesRedis。同时要确认防火墙允许本地回环连接，或者直接使用 127.0.0.1。
使用 CLUSTER MEET 手动组建集群
启动三个实例后，可以先任选一个作为初始节点。打开一个新命令行窗口，进入 C:Redis 目录，执行：
redis-cli -h 127.0.0.1 -p 7000 cluster meet 127.0.0.1 7001
这条命令会告诉 7000 节点去认识 7001 节点。接着再执行：
redis-cli -h 127.0.0.1 -p 7000 cluster meet 127.0.0.1 7002
这样 7000 就与 7001、7002 建立了连接。由于 Gossip 协议会扩散成员信息，等几秒钟后查看任意一个节点的 CLUSTER NODES 输出，应该能看到三个节点都在列表中，并且彼此已连接。如果看到某个节点的状态是 fail，需要检查端口是否可访问、集群配置是否冲突。
完成成员加入后，集群的三个主节点之间还没有分配槽位。此时如果写入键，可能会收到 CLUSTERDOWN Hash slot not served 错误。可以使用 redis-cli --cluster fix 或手动分配槽位，例如连接到 7000 执行 CLUSTER ADDSLOTS 0 5460，连接到 7001 执行 CLUSTER ADDSLOTS 5461 10922，连接到 7002 执行 CLUSTER ADDSLOTS 10923 16383。也可以使用 redis-cli --cluster create 命令一次性分配，但如果是手动 meet 的场景，就需要自己处理槽位。
验证与常见问题
执行 redis-cli -h 127.0.0.1 -p 7000 cluster info 可以查看集群状态。cluster_state:ok 表示所有槽位都有节点负责且主从关系正常。cluster_known_nodes:3 表示当前节点认识 3 个节点。使用 cluster nodes 能列出每个节点的 ID、地址、角色、负责的槽位范围以及主从对应关系。如果某个节点没有槽位且不是从节点，它仍然可以存在于集群中，但无法正常服务数据，这在测试环境中比较常见。
手动加入节点时最容易忽视的是 cluster-config-file 路径问题。例如两个实例的 cluster-config-file 都写成 nodes.conf 且工作目录相同，会导致互相覆盖，集群状态混乱。务必为每个实例指定独立文件，如 nodes-7000.conf、nodes-7001.conf、nodes-7002.conf。另外，如果集群已经运行了一段时间，新节点加入后需要等待 Gossip 消息传播才能被所有节点认识，有时几十秒内 CLUSTER NODES 的信息可能存在短暂不一致，这是正常现象。
当需要把节点从集群中移除时，不能直接杀掉进程，否则其他节点会将其标记为 fail。应该使用 CLUSTER FORGET node-id 从每个节点中遗忘目标节点。如果只是临时下线，可以正常关闭 Redis 实例，集群会检测到连接断开，但不会立即标记 fail，因为有 node-timeout 参数控制超时时间。理解这些机制有助于在使用 CLUSTER MEET 后更好维护集群。
Redis ClusterCLUSTER MEET节点加入修改时间：2026-08-20 05:35:16