Gossip 协议通信

什么是 Gossip 协议

Gossip 协议是一种去中心化的分布式通信协议，灵感来源于社交网络中的”八卦传播”模式。在 Redis Cluster 中，节点之间通过 Gossip 协议来交换集群状态信息，包括：节点存活状态、槽位分配信息、主从关系等。

为什么需要 Gossip

在 Redis Cluster 中，每个节点都需要知道集群中所有其他节点的状态。如果使用集中式的配置中心：

• 会引入单点故障
• 需要额外的维护成本
• 在大规模集群中成为性能瓶颈

Gossip 协议的核心优势是去中心化——不需要专门的配置服务器，每个节点都平等地参与状态同步，系统的健壮性更高。

通信机制

通信周期

每个 Redis Cluster 节点每秒执行一次 PING 操作：

1. 从已知节点列表中随机选择 5 个节点
2. 从上次 PONG 回复时间最久的节点中选择1 个未被选中的
3. 总共发送 6 个 PING（5 个随机 + 1 个最旧的）

如果某个节点超过 cluster-node-timeout 的一半都没有回应 PING，该节点会被立即 PING 一次。

消息内容

PING 和 PONG 消息的格式如下：

消息头：
┌──────────────────────────────┐
│    消息类型（PING/PONG）        │
│    发送节点 ID                 │
│    当前纪元（epoch）            │
│    发送节点槽位位图（2048 字节）  │
└──────────────────────────────┘

消息体（Gossip 条目，最多包含约 3 个其他节点的信息）：
┌──────────────────────────────┐
│   节点 ID                     │
│   节点状态（上线/下线/PFAIL...）│
│   节点地址（IP:Port）           │
│   节点角色（主/从）             │
│   槽位范围                     │
└──────────────────────────────┘

传播方式（Gossip 条目）

节点在 PING 消息中不仅携带自己的信息，还会捎带其他节点的状态信息（称为 Gossip 条目）。收到消息的节点可以：

1. 更新本地维护的集群节点信息
2. 发现之前不知道的新节点
3. 感知其他节点的故障状态

这种方式实现了”一传十、十传百”的信息扩散效果。

故障发现：PFAIL → FAIL

Gossip 协议在故障发现中的角色：

PFAIL（疑似下线）

当节点 A 在 cluster-node-timeout 时间内无法联系到节点 B，A 将 B 标记为 PFAIL（Possible Fail，疑似下线）。这是局部判定。

FAIL（确认下线）

节点 A 通过 Gossip 消息将 B 的 PFAIL 状态传播给其他节点。如果集群中半数以上的主节点都认为 B 挂了（或者从其他节点的 Gossip 消息中获知），B 的状态就会从 PFAIL 升级为 FAIL。

特点

• PFAIL 到 FAIL 的升级可快可慢，取决于 Gossip 传播速度
• 没有像哨兵那样的显式投票机制
• 依靠 Gossip 信息的自然扩散达到”多数同意”的效果

Gossip vs. 集中式心跳

带宽优化：消息压缩

Redis Cluster 在发送 Gossip 消息时采用了多种优化手段：

1. 只发送变化信息：如果节点状态没有变化，Gossip 条目中只会包含少量信息
2. 二进制编码：使用紧凑的二进制格式，而非文本协议
3. 槽位位图优化：16384 个槽仅需 2048 字节位图，而非全量槽列表
4. 选择性发送：不发送所有节点信息，只选择部分节点

总结

Gossip 协议是 Redis Cluster 实现去中心化集群管理的关键技术。通过 PING/PONG 消息中的 Gossip 条目，节点之间能够以”八卦传播”的方式同步集群状态。它的最终一致性模型虽然不如强一致模型精确，但在大规模分布式系统中提供了更好的可扩展性和容错性。