redis cluster 的通信机制

Redis Cluster 的通信机制是其分布式架构的核心，基于 Gossip 协议 和 Cluster Bus 实现节点间状态同步与数据协调。以下是其通信机制的核心要点：

二进制协议：数据以字节流形式编码（如Protobuf、Thrift、MQTT、Gossip）。
文本协议：数据以人类可读的字符形式表示（如JSON、XML、HTTP/1.1）。

集群元数据的维护有两种方式：集中式、Gossip 协议。

集中式：将集群元数据集中存储在一个节点上。
优点
元数据的读取和更新时效性好，元数据的变更都能立即更新到集中式存储节点中，其它节点读取的时候就可以感知到。
缺点
所有的元数据的更新压力全部集中在一个地方，可能会导致元数据的存储有压力。

Gossip：所有节点都持有一份元数据，不同的节点如果出现了元数据的变更，就不断将元数据发送给其它的节点，让其它节点也进行元数据的变更。
优点
元数据的更新比较分散，不是集中在一个节点，降低了压力。
缺点
元数据的更新有延时，可能导致集群中的一些操作会有一些滞后。

一、通信协议与方式

Gossip 协议
- 随机传播：每个节点周期性地随机选择其他节点发送消息（如 PING、PONG、MEET、FAIL），传播集群状态信息（节点存活、槽位分配、主从角色等）。
- 低负载扩展：节点通信频率不随集群规模线性增长，适合大规模集群（数千节点）。
- 最终一致性：信息通过多次传播逐步覆盖所有节点，可能存在短暂延迟，但最终达成一致。
Cluster Bus 端口
- 每个节点额外开放一个通信端口（默认 服务端口 + 10000，如服务端口 6379，则 Cluster Bus 端口为 16379）。
- 通过二进制协议传输高效的结构化数据（如槽位映射、节点元数据）和心跳检测（详见第二章：核心通信场景）。

二、核心通信场景

节点握手（Cluster Meet）
- 新节点加入：通过 CLUSTER MEET <IP> <PORT> 命令或自动发现机制，新节点与现有节点建立连接。
- 元数据交换：节点间交换 ID、IP、端口、角色（主/从）、负责的槽位等信息。
心跳检测（PING/PONG）
- 健康检查：节点定期发送 PING，接收方回复 PONG 确认存活。
- 故障判定：若节点在 cluster-node-timeout（默认 15 秒）内未响应，可能被标记为 FAIL。
槽位分配与迁移
- 槽位变更广播：当槽位分配调整时（如扩容/缩容），通过 Gossip 协议通知所有节点更新槽位映射。
- 迁移协调：迁移过程中，源节点和目标节点通过 ASKING 命令临时处理跨节点请求。
故障转移
- 主节点下线：从节点通过 Gossip 感知主节点故障，触发选举流程（Raft 变种），新主节点广播自身角色变更。
- 数据同步：新主节点通过异步复制与从节点同步数据。

三、客户端与集群通信

重定向机制
- MOVED 响应：客户端请求的 Key 不属于当前节点槽位时，返回 MOVED <slot> <target_ip:port>，客户端更新本地槽位缓存。
- ASK 响应：槽位迁移期间，目标节点可能返回 ASK 临时重定向，客户端需向目标节点发送 ASKING 后重试。
智能客户端
- 本地缓存槽位表：客户端首次连接任一节点获取全局槽位映射，后续直接路由请求至正确节点。
- 动态更新：收到 MOVED 或 ASK 时更新缓存，避免重复重定向。

四、优化与挑战

性能优化
- 批量消息：合并多个 Gossip 消息减少网络开销。
- CRC16 分片：通过 CRC16(key) % 16384 快速定位槽位，确保数据均匀分布。
挑战
- 网络分区：Gossip 的最终一致性可能导致分区时出现脑裂，需依赖 cluster-require-full-coverage 配置权衡可用性。
- 迁移性能：槽位迁移期间需协调数据复制与流量切换，可能影响吞吐量。

五、实际应用示例

# 节点 A（7000）与节点 B（7001）握手
CLUSTER MEET 127.0.0.1 7001# 查看集群节点信息
CLUSTER NODES
# 输出示例：
# d4b3... 127.0.0.1:7001 master - 0 1620000000000 1 connected 0-5460
# a1c2... 127.0.0.1:7000 myself,master - 0 0 2 connected 5461-10922