redis集群通过gossip协议实现去中心化状态同步：节点每秒随机向5个节点发送ping，携带configepoch、slots映射及节点状态快照；pfail经多数主节点确认后升级为fail并广播；依靠高epoch触发同步、启动时批量拉取、变更带新epoch保障最终一致性。

Redis 集群节点间通过 Gossip 协议实现轻量、去中心化的状态同步，不依赖单点协调器，每个节点周期性地与部分其他节点交换集群元数据，逐步收敛至全局一致视图。

Gossip 的触发机制和通信对象

每个节点默认每秒向随机选出的 5 个其他节点（包括在线和疑似下线的）发起 PING 消息；若自身收到 PONG 回复较慢或发现某节点长时间无响应，会主动增加对该节点的探测频率。选择目标节点时优先避开最近刚通信过的节点，以提升信息扩散效率。

交换的核心信息内容

每次 Gossip 消息（PING 或 PONG）都携带以下关键字段：

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• 本节点的配置纪元（configEpoch）：标识该节点当前负责的槽位分配版本，用于冲突裁决
• 本节点已知的 slots 分配映射（bit array + 节点 ID）：标明自己认为哪些槽由谁负责
• 本节点记录的其他节点状态快照：包含最多 10 个它近期通信过的节点的 IP、端口、状态（fail/pong/pfail）、最新 configEpoch 和最后一次心跳时间
• 自身节点 ID 和 epoch：用于身份识别与防混淆

故障检测与状态传播逻辑

节点不会直接广播“某节点宕机”，而是采用两阶段判断：

• 若 A 节点在超时（cluster-node-timeout 默认 15s）内未收到 B 的有效 PONG，A 将 B 标记为 pfail（possible failure），仅本地标记，不通知他人
• 当 A 向其他节点 Gossip 时，会把 B 的 pfail 状态带过去；一旦有超过半数主节点也标记 B 为 pfail，A 就升级为 fail 状态，并向全集群广播 FAIL 消息
• 所有收到 FAIL 消息的节点立即更新本地拓扑，并开始跳过对 B 的请求路由

如何保证最终一致性

Gossip 不强求实时一致，但靠三个设计保障收敛：

• 消息携带“最高已知 configEpoch”——接收方若发现对方 epoch 更高，会主动请求完整槽映射（CLUSTER SETSLOT … NODE …）进行同步
• 节点启动或加入集群时，先通过 meet 命令建立连接，再批量拉取对方的 slots 分配表和节点列表
• 所有变更（如手动 reshard、failover、addnode）均由主节点发起并带上新 epoch，其他节点通过 Gossip 逐步感知并校验