想了解Redis集群到底怎么连接的，怎么看它们之间的关系和结构呢？

想弄明白Redis集群是怎么连接和组织的,我们可以把它想象成一个分工明确的团队，这个团队为了处理海量的工作，不能只靠一个人单打独斗，所以它由多个成员（也就是多个Redis节点）组成，每个成员都有自己负责的一摊事儿，并且成员之间互相通气，共同协作。

最核心的问题是：这些“成员”是如何连接在一起，形成一个团队的？

这个连接不是随意的,也不是所有节点都两两直接相连，Redis集群采用了一种叫做“Gossip协议”（流言协议）的方式来维护成员之间的关系，这个名字很形象，你可以想象成办公室里的“小道消息”传播机制。

在一个办公室里,一个新同事入职（一个新节点要加入集群），他可能只认识HR（集群中已知的某个节点），HR会把这个新同事介绍给团队里的几个核心成员（与其他节点建立连接），这些核心成员在喝茶聊天时（节点间定期通信），就会把“我们组来了个新人”这个消息告诉其他自己熟悉的同事，一传十，十传百，很快，整个团队的所有成员都知道了新人的存在，并且都和他建立了联系，这个过程是自动的，不需要管理员手动去每个节点上配置新节点的地址。

每个Redis集群节点都会维护两个端口号：

1. 客户端通信端口：比如6379，这是给咱们的应用程序连接用的，用来执行读写命令。
2. 集群总线端口：通常是客户端端口加10000（比如16379），这个端口就是专门用于节点之间“说悄悄话”的，通过这个集群总线，节点之间会定期发送PING/PONG消息，这些消息里包含了自身的信息、所负责的数据槽位、以及其他已知节点的状态，通过这种方式，每个节点最终都拥有一份完整的集群“花名册”，知道集群里有哪些伙伴，各自负责什么。

我们看看这个团队内部的结构和关系是怎样的。

Redis集群最核心的结构设计是“数据分片”（Sharding），团队不能活儿一起干，那会乱套，所以要把工作分清楚，Redis集群把整个数据空间划分为16384个槽（slot），你可以把它们想象成16384个编号的“任务篮”。

当集群搭建好之后,这16384个任务篮会尽可能平均地分配给所有的主节点（Master Node），一个由3个主节点组成的集群，可能这样分配：

• 节点A：负责槽位0 - 5460
• 节点B：负责槽位5461 - 10922
• 节点C：负责槽位10923 - 16383

这样一来,每一条存入集群的数据，都会根据它的key计算一个哈希值，再对16384取模，最终决定它应该被放进哪个“任务篮”，进而决定由哪个主节点来负责存储，这就实现了数据的分布式存储，每个节点只承担一部分数据压力。

节点之间是什么关系呢？主要是主从关系。

为了保证团队的高可靠性,防止某个成员突然请假（节点宕机）导致他负责的工作没人做，Redis集群为每个主节点配置了一个或多个从节点（Slave Node），从节点就像是主节点的“备份”或“学徒”，它们会实时地复制主节点上的所有数据，平时，从节点不处理客户端的写请求，主要工作就是同步数据。

它们之间的关系是：

• 主节点：负责处理分配给自己的槽位的读写请求，并同步数据给其从节点。
• 从节点：复制主节点的数据，在主节点发生故障时，能够被集群“提拔”成新的主节点，接替原来的工作，从而保证服务不中断。

一个完整的Redis集群视图是这样的：一群通过集群总线互相连接、互相通信的节点，它们共同管理着16384个数据槽，这些槽被分配给几个主节点，每个主节点后面又跟着几个从节点作为备份，所有的节点共同维护着一份统一的集群配置信息，使得客户端无论连接到哪个节点，都能获取到正确的数据路由信息。

作为使用者，我们怎么看懂这个结构和关系呢？

你不需要去每个节点上翻日志,Redis提供了非常直观的命令行工具，当你连接上集群中的任意一个节点（需要使用-c参数以集群模式连接），执行命令 redis-cli -c -h [host] -p [port] cluster nodes。

这个命令会返回一个列表,清晰地展示出整个集群的全貌，每一行代表一个节点，信息通常包括：

• 节点ID（一个长字符串，是节点的唯一标识）
• 节点的IP地址和端口号
• 节点角色（master 或 slave）
• 如果是从节点,会显示它的主节点的ID
• 该节点负责的数据槽位范围（如果是主节点）
• 节点的状态（如connected表示正常连接）

通过阅读这个输出,你就能一眼看出集群里有多少个主节点、多少个从节点，谁是谁的备份，以及数据是怎么分布的，这就像拿到了这个团队的完整组织架构图。

Redis集群通过Gossip协议自动连接所有节点,通过数据分片（槽slot）来分配数据存储任务，通过主从复制来保证高可用，它的结构是一个去中心化的、主从分明的协作网络。