[Redis小技巧27]Redis Cluster 全景指南：Gossip 协议、故障转移与生产避坑实战

一、核心原理解析：数据是如何分布的？

1. 去中心化架构与哈希槽（Hash Slots）

Redis Cluster 并非采用一致性哈希（Consistent Hashing），而是引入了哈希槽（Hash Slots）的概念。集群预分配了16384个槽（0∼163830 \sim 163830∼16383）。

• 映射规则：当客户端操作某个 Key 时，Redis 使用CRC16(key) % 16384计算该 Key 属于哪个槽。
• 节点承载：集群中的每个主节点负责维护一部分槽。例如，节点 A 负责0∼50000 \sim 50000∼5000，节点 B 负责5001∼100005001 \sim 100005001∼10000，节点 C 负责10001∼1638310001 \sim 1638310001∼16383。
• 元数据存储：每个节点都保存了集群的元数据（槽与节点的映射关系），因此任何节点都可以接收请求，若请求的槽不在本地，则返回MOVED或ASK重定向响应。
• 为什么是 16384？
  • 网络开销平衡：槽位信息需要通过 Gossip 协议在节点间同步。如果槽位过多（如2322^{32}232），心跳包负载过大；过少则导致数据分布不均。16384 是一个在内存占用（每个节点只需维护一个 16384 位的位图）和数据均衡性之间的最佳折中点。
  • 迁移粒度：在扩缩容时，数据迁移的最小单位是“槽”。16384 提供了足够细的粒度，使得迁移过程平滑，不会因单次迁移数据量过大而阻塞服务。

2. Gossip 协议：集群的神经系统

Redis Cluster 采用去中心化的 P2P 架构，所有节点通过Gossip 协议进行通信，以交换集群元数据、检测节点状态和选举主节点。

• 通信机制：每个节点定期（默认每秒 10 次）向随机选择的邻居节点发送PING消息，接收方回复PONG。消息中携带了发送节点的元数据（如节点状态、负责的槽位、配置纪元等）。
• 状态感知：通过频繁的元数据交换，集群内所有节点最终能达到状态一致（Eventual Consistency）。当某个节点宕机，其他节点通过超时机制（node-timeout）判定其失效，并触发故障转移流程。

下图展示了 Gossip 协议在节点间的典型通信与状态同步流程：

Gossip 协议在 Redis Cluster 中主要承担两大职责：集群元数据同步（谁是谁，谁负责哪些槽）和故障检测（谁挂了）。

（1）随机化传播与谣言扩散机制

想象在一个聚会上，每个人每隔一秒随机找一个人聊天，交换彼此认识的人的最新动态。

• Ping/Pong 交互：节点周期性（默认cluster-node-timeout的 1/10 或更短）向随机节点发送PING。接收方若正常，回复PONG。
• 信息扩散：每次PING或PONG都携带发送者视角的“部分真理”（Gossip Section）。接收者合并这些信息：如果收到更新的configEpoch或更严重的状态标记（如FAIL），则更新本地视图，并在下一次自己的PING中继续传播。
• 收敛性：数学证明表明，在O(log⁡N)O(\log N)O(logN)轮次内，信息可传播至全网。对于 Redis，这意味着即使在大集群中，元数据变更也能在秒级内达成一致。

（2）故障检测：从 PFAIL 到 FAIL

这是 Gossip 协议最精妙的设计，有效避免了单点误判导致的脑裂。

1. 主观下线 (PFAIL - Probably Fail)：
   • 节点 A 在cluster-node-timeout时间内未收到节点 B 的PONG。
   • 节点 A 将 B 标记为PFAIL。注意：此时仅是 A 的“主观”看法。
2. 客观下线 (FAIL - Actually Fail)：
   • 节点 A 在发出的PING的 Gossip 区中广播“我认为 B 是 PFAIL”。
   • 其他节点收到后，如果自己也无法联系 B，也会标记 B 为PFAIL。
   • 当某个主节点（通常是当前主节点或拥有较多槽的节点）收集到超过半数主节点对 B 的PFAIL报告时，它将 B 标记为FAIL。
   • 该节点广播FAIL消息。全网收到FAIL消息后，立即将 B 标记为下线，并触发故障转移流程。

（3）配置纪元 (Config Epoch) 与 脑裂防护

在故障转移时，从节点晋升为主节点需要获得唯一的configEpoch。Gossip 协议确保在任意时刻，同一个槽位（Slot）只能有一个有效的configEpoch。如果发生网络分区导致两个节点都认为自己升级成功（产生冲突纪元），后续通信中发现冲突时，拥有较大纪元的节点会存活，较小的会被回退，从而保证最终一致性。

3. 客户端路由与重定向（MOVED vs ASK）

Redis Cluster 的客户端分为两类：智能客户端（如 Jedis, Lettuce, redis-py-cluster）和普通客户端。
智能客户端会本地缓存槽位映射表，直接路由请求。
但当集群发生扩缩容或故障转移时，本地缓存可能过期，此时服务端会返回重定向错误。

• 深度解析：为什么需要ASK？
  在槽位迁移过程中，如果客户端直接收到MOVED并更新缓存，可能会在迁移未完成时反复横跳。ASK机制允许客户端临时访问新节点，而无需立即修改全局路由表，保证了迁移期间的平滑过渡。

4. Redis Cluster 总线与二进制协议详解

Redis Cluster 并非仅靠客户端重定向（MOVED/ASK）工作，其背后隐藏着一张密集的通信网——Cluster Bus。

（1）物理拓扑与端口约定

每个 Redis 实例在集群模式下会监听两个端口：

• 客户端端口（默认 6379）：处理客户端命令。
• 总线端口（默认 16379，即客户端端口 + 10000）：专门用于节点间通信。

所有节点通过 TCP 长连接两两互联（全互联或部分互联，取决于规模），形成一个网状拓扑。即便客户端只连接了一个节点，该节点也能通过总线感知整个集群的脉搏。

（2）二进制协议结构深度拆解

Cluster Bus 使用高效的二进制协议，而非人类可读的 RESP 协议。一个典型的总线消息包（Packet）结构如下：

+----------------+------------------+---------------------+------------------+ | Header | Payload | Gossip Section | Extension | | (固定长度) | (可变长度) | (核心：节点状态列表) | (预留/新特性) | +----------------+------------------+---------------------+------------------+

• Header (16 bytes):
  • sig[2]: 固定为 “RC” (Redis Cluster)，用于校验。
  • totlen[2]: 消息总长度。
  • type[2]: 消息类型（如CLUSTERMSG_TYPE_PING,PONG,MEET,FAIL等）。
  • port[2],flags[2],slot[2]等元数据。
• Payload: 携带特定消息类型的附加数据。例如在MEET消息中，这里包含目标节点的 IP 和端口；在FAIL消息中，包含被判定失效的节点 ID。
• Gossip Section (clusterMsgDataGossip): 这是协议的心脏。它是一个数组，包含发送节点当前所知的其他节点的状态摘要。
  • 每个条目包含：nodename(40 bytes),ip(4/16 bytes),port,flags(是否为主节点、从节点、疑似下线 PFAIL、确认下线 FAIL 等),epoch(配置纪元),slots(负责的槽位范围)。

关键点：由于消息大小受限于cluster-message-size-max(默认 2KB)，节点无法在一次消息中携带所有其他节点的信息。因此，节点会随机选择一部分节点状态放入 Gossip 区进行传播。这种“抽样传播”正是 Gossip 协议名字的由来，也是其能在大规模网络中控制带宽的关键。

5. 多键操作限制与 Hash Tags

由于数据分散在不同节点，原生 Redis Cluster不支持跨槽的多键操作（如MGET key1 key2，若 key1 和 key2 在不同槽）。

• 解决方案：Hash Tags
  通过在 Key 中使用花括号{}，可以强制指定哈希计算的依据。
  • 规则：只有{}内部的字符串参与 CRC16 计算。
  • 示例：user:{1001}:info和user:{1001}:order。
  • 结果：两者的槽位计算均基于1001，因此必然落在同一个槽位，从而可以在同一节点执行事务或多键操作。

二、架构与高可用：故障转移与脑裂处理

1. 故障检测与自动转移

Redis Cluster 的高可用依赖于主从复制和自动故障转移机制：

1. 主观下线 (PFAIL)：当节点 A 在cluster-node-timeout时间内未收到节点 B 的 PONG，将其标记为 PFAIL。
2. 客观下线 (FAIL)：节点 A 将 B 的 PFAIL 状态广播给其他主节点。当超过半数主节点确认 B 为 PFAIL 时，B 被标记为 FAIL。
3. 选举触发：若故障节点是主节点，其从节点会检测到主节点 FAIL，并发起选举。
4. 投票机制：从节点向所有主节点发送FAILOVER_AUTH_REQUEST。主节点根据配置纪元（Config Epoch）和离线时间判断是否投票。
5. 晋升为主：获得多数票的从节点晋升为新主节点，并接管原主节点的槽，广播新的配置版本。

2. 脑裂（Split-Brain）与数据丢失风险

在网络分区场景下，集群可能被分割为两部分。少数派主节点因无法联系到多数派，会停止写入（默认配置min-slaves-to-write和min-slaves-max-lag可控制此行为），而多数派继续提供服务。

注意：网络恢复后，少数派主节点重新加入集群时，其在分区期间写入的数据可能会被覆盖（因为多数派已经完成了故障转移并产生了新的数据）。这是基于 AP（可用性）优先的权衡，需在业务层做好幂等处理或接受短暂数据不一致。

三、实战指南：搭建、扩缩容与监控

1. 集群搭建与扩缩容流程

推荐使用redis-cli --cluster create进行一键搭建。扩缩容则是生产环境的高频操作。

在线扩缩容核心步骤：

1. 准备新节点：启动新的空节点，并将其MEET进集群。
2. 分配槽：使用redis-cli --cluster reshard命令，将旧节点的部分槽迁移到新节点。
3. 数据迁移：Redis 会自动将源槽上的数据异步迁移到目标节点。迁移期间，服务不中断。
4. 更新拓扑：迁移完成后，集群元数据自动更新，流量平滑切换。

2. 单机版 vs Cluster 版特性对比

五、批量操作与跨槽难题

在 Cluster 模式下，最容易遇到的陷阱是跨槽操作。

1. 批量操作限制

• 现象：执行MGET key1 key2 key3时，如果这些 Key 分布在不同的槽上，Redis 会返回错误(error) ERR CROSSSLOT Keys in request don't hash to the same slot。
• 解决方案：
  1. 应用层拆分：在代码中按槽对 Key 进行分组，多次请求。
  2. Hash Tag（推荐）：利用{}语法强制指定哈希计算部分。
     • 例如：user:{1001}:info和user:{1001}:order。
     • Redis 仅计算{}内的内容（即1001）的哈希值，确保它们落在同一个槽，从而支持事务和批量操作。

2. 事务与 Lua 脚本

• 限制：MULTI/EXEC和 Lua 脚本中的所有 Key 必须位于同一槽。
• 策略：设计数据模型时，将强关联的数据（如用户信息与订单）通过 Hash Tag 绑定在同一槽。对于弱关联数据，放弃事务一致性，采用最终一致性方案。

六、常用命令速查

七、高频面试题

Q1: Redis Cluster 为什么选择 16384 个槽？而不是更多或更少？

答：这是一个权衡结果。

1. 心跳包大小：节点间通过 Gossip 交换槽信息。若槽太多，心跳包过大，占用带宽；若太少，数据分布不够均匀。
2. 位图存储：16384 小于2142^{14}214，可以用 2KB 的位图（Bitmap）紧凑地表示所有槽的状态，极大节省了内存和传输开销。
3. 经验值：官方认为对于绝大多数集群（不超过 1000 个节点），16384 能提供足够好的负载均衡，且维护成本低。

Q2: 客户端收到MOVED和ASK重定向有什么区别？

答：

• MOVED：表示槽已经永久迁移完成。客户端应更新本地路由缓存，后续请求直接发往新节点。
• ASK：表示槽正在迁移中（数据尚未完全搬完）。客户端需先向新节点发送ASKING命令，然后重试当前请求。新节点会临时允许访问该槽，即使数据还没完全迁过来（它会去旧节点拉取缺失的 Key）。这保证了迁移过程中的平滑读写。

Q3: 在 Cluster 模式下，如何保证分布式事务的一致性？

答：Redis Cluster原生不支持跨节点的分布式事务。

• 方案一：业务层面通过 Hash Tag 将相关数据强行落入同一槽，利用单机事务保证。
• 方案二：若必须跨槽，需引入外部协调机制（如 TCC、Saga 模式）或利用 Redis 的 Lua 脚本配合应用层逻辑实现最终一致性，但这会牺牲性能。通常建议在设计阶段就规避跨槽事务需求。