Redis 集群节点间的内部通信机制

Redis 集群通过 gossip 协议实现节点间的通信，确保集群内所有节点的数据保持一致。与集中式中间件相比，gossip 协议的优势在于能分散元数据更新的压力，但也伴随着数据更新的延迟。以下将从基础通信原理、端口配置、信息交换、gossip 协议的具体实现以及高可用性切换等方面详细阐述。

基础通信原理

Redis 集群采用 gossip 协议进行节点间的通信，每个节点都维护自身的状态信息。集群内的元数据（如节点信息、故障状态等）通过 gossip 协议在节点间广播，确保所有节点保持一致。与集中式中间件（如Zookeeper）相比，gossip 协议的优势在于元数据更新压力分散，更新请求会陆续发送至所有节点，降低了单点压力。

集中式与gossip的对比

集中式：
- 优点：元数据更新及时，读取时效性好。一旦元数据发生变更，更新会立即生效。
- 缺点：元数据更新压力集中在单一节点，可能导致存储压力过大。

gossip：
- 优点：元数据更新压力分散，更新请求分散到多个节点，降低了单点压力。
- 缺点：元数据更新存在延迟，可能导致集群操作滞后。

两者的优缺点相互对应，选择取决于具体场景需求。

10000 端口配置

在 Redis 集群中，每个节点都配置了一个专门用于节点间通信的端口，计算方式为服务端口号 + 10000。例如，如果节点的服务端口是 7001，则用于通信的端口为 17001。

每个节点定期向其他节点发送 ping 消息，并接收 pong 响应，确保网络连接正常。ping 消息中携带节点状态信息和元数据，用于保持节点间的数据一致性。

信息交换内容

节点间通过 gossip 协议交换的信息包括：

故障信息：当某节点失效时，其他节点会立即通过 fail 消息通知集群。

节点状态：包括节点是否在线、是否为主节点等。

hash slot 信息：用于 Redis 集群的 keys 分配，确保数据分布合理。

gossip 协议详解

gossip 协议包含多种消息类型，主要包括：

meet：用于新节点加入集群时的欢迎消息，通知新节点开始与其他节点通信。

ping：频繁发送的节点状态消息，携带自身信息和其他节点信息，用于元数据交换。

pong：对应 ping 消息的确认响应，用于信息广播和状态同步。

fail：通知其他节点某节点失效。

ping 消息深入

每个节点每秒会发送 10 次 ping 消息，每次选择通信延迟最长的 5 个节点。若发现某节点通信延迟超过 cluster_node_timeout / 2，会立即发送 ping 确保数据同步。例如，若 cluster_node_timeout 为 10 分钟，则延迟超过 5 分钟会触发 ping。

每次 ping 消息至少携带 3 个节点信息，最多携带总节点数 - 2 个节点信息，确保数据交换的全面性。