Redis集群

文章目录

• [Redis Cluster：分片与高可用](#Redis Cluster：分片与高可用)
• • [1. 数据分片](#1. 数据分片)
  • • [1.1 哈希求余](#1.1 哈希求余)
    • [1.2 一致性哈希](#1.2 一致性哈希)
    • [1.3 哈希槽（Redis Cluster 采用）](#1.3 哈希槽（Redis Cluster 采用）)
  • [2. 某个主节点挂了怎么办？](#2. 某个主节点挂了怎么办？)
  • • [2.1 故障判定](#2.1 故障判定)
    • [2.2 故障迁移](#2.2 故障迁移)
  • [3. 集群扩容](#3. 集群扩容)

Redis Cluster：分片与高可用

主从 + 哨兵解决了自动故障转移 ，但数据仍在一套主从里，容量和 QPS 有上限.

Redis Cluster 在此基础上解决两件事：数据分片 + 集群内自动故障迁移（不依赖外部 Sentinel）。

进入客户端后,可通过cluster nodes查看集群结构

---

1. 数据分片

数据量大、访问量大时，需要把 key 分散到多台 Redis 上。常见三种思路：

1.1 哈希求余

slot = hash(key) % N，N 为节点数。

节点增减时 N 变化，几乎所有 key 都要重新映射，迁移成本极高。

1.2 一致性哈希

把节点和数据映射到一个环上，扩缩容只影响相邻区间，比哈希求余好。

但仍可能出现数据倾斜 ，迁移面也不如槽方案可控。

1.3 哈希槽（Redis Cluster 采用）

固定 16384 个 slot，slot = CRC16(key) % 16384，再把槽分配给各主节点。

扩缩容时迁移槽 ，而不是按节点数重新取模，代价可控、分布更均衡。

方案	扩缩容	Redis 是否采用
哈希求余	几乎全量迁移	否
一致性哈希	影响相邻区间	否
哈希槽	按槽迁移	是

---

2. 某个主节点挂了怎么办？

2.1 故障判定

集群节点通过 ping/pong 心跳互通。某节点长时间无响应，先被标为 PFAIL （主观下线）；经 Gossip 与其他节点确认，超过半数 节点也认为它挂了，则升为 FAIL （客观下线）并广播。

整集群不可用的常见情况：

• 某个分片主从全挂
• 某个分片主挂且无从节点
• 超过半数 master 都挂了
  核心原则：每个 slot 都要有可用节点负责。

2.2 故障迁移

• 挂的是从节点：不迁移
• 挂的是主节点 ：其从节点发起竞选升主
  简要流程：

1. 与旧主断开过久、数据差异太大的从节点，失去参选资格
2. 合格从节点先休眠一段时间（数据越新，越先醒来）
3. 先醒的从节点向集群拉票（只有主节点有投票权）
4. 票数超过主节点半数 → 升主，其余从节点改复制新主
5. 广播新拓扑，各节点更新集群结构

---

3. 集群扩容

扩容 = 新节点加入 + 从已有主节点迁移一部分 hash slot 到新节点。

缩容则相反：先把槽迁走，再下线节点。