Gossip 协议 = 节点之间"不断八卦彼此状态"的去中心化健康检测机制
**一、**Redis Cluster 中 Gossip 在干什么？
Gossip 主要负责 4 件事：
-
节点发现
-
节点健康检测
-
主从状态传播
-
故障信息达成一致
二、Gossip 是怎么通信的
Redis Cluster 使用两种端口：
| 端口 | 用途 |
|---|---|
| 普通端口（6379） | 客户端请求 |
| Cluster Bus（16379） | 节点间 Gossip |
Gossip 的基本通信模型
每个节点：
周期性随机选几个节点
发送 PING
对方返回 PONG
消息里不仅包含"我还活着"，还包含：
我知道的其他节点状态
消息里都带了什么？
一次 Gossip 消息里可能包含：
节点 ID
节点角色（主 / 从）
是否主观下线是否客观下线
slot 分配信息
复制关系
三、Redis Cluster 如何判断节点挂了？
第一步：主观下线（PFAIL）
某一个节点自己觉得：某节点可能挂了
条件：
连续一段时间 PING 不通
超过 cluster-node-timeout
结果：
给该节点打上 PFAIL
通过 Gossip 告诉其他节点
这一步不做任何故障转移
第二步：客观下线（FAIL）
足够多的主节点一致认为：它真的挂了
条件：
多个 主节点
都对同一节点标记 PFAIL
数量 ≥ quorum（法定人数）
结果：
升级为 FAIL
触发故障转移流程
四、故障转移是如何触发的？
M1（主） ─ S1（从）
故障流程：
-
多个主节点通过 Gossip 发现 M1 = FAIL
-
M1 的从节点（S1）开始竞选
-
每个主节点只能投 1 票
-
得票 ≥ 半数主节点
-
S1 升级为新主
-
重新分配 hash slot
五、为什么要奇数个主节点？
这是分布式系统的经典问题：多数派原则
假设你只有 2 个主节点
网络分区：
分区 A：M1
分区 B：M2
两边都只有 1 票
无法达到多数
整个集群不可写
假设你有 3 个主节点
分区 A：M1 + M2
分区 B：M3
A：2 票 → 多数
B：1 票 → 少数
只有一边能继续对外服务
六、为什么 Redis 选择 Gossip？
优点
无中心节点
可扩展
节点数大也能跑
容错强
缺点
状态收敛是"最终一致"
有传播延迟
短时间内可能认知不一致