137｜Redis Cluster：哈希槽、Gossip、重定向、扩缩容和故障转移

┌──────────────────────────────────────┐
│         Sentinel 高可用架构           │
│                                      │
│   ┌──────┐    ┌──────┐    ┌──────┐  │
│   │Master│───▶│Slave1│    │Slave2│  │
│   │ 64GB │    │ 64GB │    │ 64GB │  │
│   └──────┘    └──────┘    └──────┘  │
│                                      │
│   总容量 = 64GB（不是 192GB）         │
│   从节点只是副本，不扩大容量           │
└──────────────────────────────────────┘

客户端分片（传统方案）：         Redis Cluster（官方方案）：
┌──────────┐                   ┌──────────────────────────┐
│  客户端   │                   │   Redis Cluster           │
│  ┌────┐  │                   │  ┌────┐ ┌────┐ ┌────┐   │
│  │路由│  │  ← 客户端负责     │  │N1  │ │N2  │ │N3  │   │
│  │逻辑│  │     数据路由      │  │0-5K│ │5K- │ │10K-│   │
│  └────┘  │                   │  │槽  │ │10K │ │16K │   │
│  /  \    │                   │  └────┘ └────┘ └────┘   │
│ ▼    ▼   │                   │   ↑ 服务端路由 + 重定向  │
│ R1   R2  │                   └──────────────────────────┘
└──────────┘

HASH_SLOT = CRC16(key) mod 16384

# 创建 3 主 3 从的集群
redis-cli --cluster create \
  192.168.1.1:6379 192.168.1.2:6379 192.168.1.3:6379 \
  192.168.1.4:6379 192.168.1.5:6379 192.168.1.6:6379 \
  --cluster-replicas 1

# 查看槽位分布
redis-cli -h 192.168.1.1 -p 6379 cluster nodes
# 输出示例：
# 节点ID ... 192.168.1.1:6379@16379 master - 0 1234567890 1 connected 0-5460
# 节点ID ... 192.168.1.2:6379@16379 master - 0 1234567890 2 connected 5461-10922
# 节点ID ... 192.168.1.3:6379@16379 master - 0 1234567890 3 connected 10923-16383

# 普通 key：对整个 key 做 CRC16
user:1001        → CRC16("user:1001") % 16384 → 槽位 X

# Hash Tag：只对 {} 中的部分做 CRC16
user:{1001}:name → CRC16("1001") % 16384 → 槽位 Y
user:{1001}:age  → CRC16("1001") % 16384 → 槽位 Y（同一槽！）

// Redis 源码中的 keyHashSlot 实现（简化版）
unsigned int keyHashSlot(char *key, int keylen) {
    int s, e; // {} 的起止下标

    for (s = 0; s < keylen; s++)
        if (key[s] == '{') break;

    // 没有找到 '{'，对整个 key 计算哈希
    if (s == keylen) return crc16(key, keylen) & 0x3FFF;

    for (e = s+1; e < keylen; e++)
        if (key[e] == '}') break;

    // 没有找到 '}' 或 {} 之间为空，对整个 key 计算哈希
    if (e == keylen || e == s+1) return crc16(key, keylen) & 0x3FFF;

    // 只对 {} 之间的部分计算哈希
    return crc16(key+s+1, e-s-1) & 0x3FFF;
}

typedef struct clusterState {
    clusterNode *myself;              // 本节点
    dict *nodes;                      // 所有节点（key=节点ID, value=clusterNode）
    clusterNode *slots[16384];        // 槽→节点映射（核心！O(1)查找）
    // ...
} clusterState;

typedef struct clusterNode {
    char name[40];                    // 节点ID（40字符随机hex串）
    int flags;                        // 节点状态标志
    unsigned char slots[16384/8];     // 本节点负责的槽位位图
    int numslots;                     // 负责的槽位数量
    // ...
} clusterNode;

┌──────────────────────────────────────────────────┐
│                PING/PONG 消息头                    │
│  ┌────────────────────────────────────────────┐  │
│  │ 发送者节点ID、currentEpoch、configEpoch     │  │
│  │ 发送者负责的槽位位图（2048 bytes）          │  │
│  │ 发送者节点的主从关系信息                     │  │
│  └────────────────────────────────────────────┘  │
│                                                    │
│  ┌────────────────────────────────────────────┐  │
│  │          Gossip 段（最多 1/10 节点数）       │  │
│  │  ┌──────┐ ┌──────┐ ┌──────┐                │  │
│  │  │节点A │ │节点B │ │节点C │  ...           │  │
│  │  │状态  │ │状态  │ │状态  │                │  │
│  │  └──────┘ └──────┘ └──────┘                │  │
│  └────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────┘

// clusterCron 中的简化逻辑
void clusterCron(void) {
    // 1. 随机选节点发 PING，优先选超时的
    clusterNode *node = /* 随机选一个节点 */;
    if (node->ping_sent && now - node->ping_sent > timeout/2) {
        // 优先 ping 这个节点
    }
    clusterSendPing(node);

    // 2. 检查所有节点是否超时
    for (each known node) {
        if (now - node->pong_received > cluster_node_timeout) {
            node->flags |= PFAIL;  // 标记疑似下线
        }
    }
}

客户端                    节点A（槽 0-5000）           节点B（槽 5001-10000）
  │                           │                          │
  │ SET user:9000 "alice"    │                          │
  │─────────────────────────▶│                          │
  │                           │ user:9000 → 槽 8000     │
  │                           │ 不归我管！               │
  │ MOVED 8000 192.168.1.2:6379                         │
  │◀─────────────────────────│                          │
  │                           │                          │
  │ SET user:9000 "alice"    │                          │
  │─────────────────────────────────────────────────────▶│
  │                           │                          │ OK
  │◀─────────────────────────────────────────────────────│
  │                           │                          │

- MOVED 8000 192.168.1.2:6379

- ASK 8000 192.168.1.2:6379

客户端                    节点A（槽迁移中）          节点B（槽迁移中）
  │                           │                          │
  │ GET user:9000             │                          │
  │─────────────────────────▶│                          │
  │                           │ key 已迁到 B            │
  │ -ASK 8000 192.168.1.2:6379                          │
  │◀─────────────────────────│                          │
  │                           │                          │
  │ ASKING                    │                          │
  │─────────────────────────────────────────────────────▶│
  │                           │                          │ OK
  │ GET user:9000             │                          │
  │─────────────────────────────────────────────────────▶│
  │                           │                          │ "alice"
  │◀─────────────────────────────────────────────────────│
  │                           │                          │

Smart Client 内部结构：
┌─────────────────────────────────────┐
│          JedisCluster               │
│  ┌───────────────────────────────┐  │
│  │     槽位路由表（本地缓存）      │  │
│  │  slot 0-5460   → 192.168.1.1 │  │
│  │  slot 5461-10922 → 192.168.1.2│  │
│  │  slot 10923-16383 → 192.168.1.3│ │
│  └───────────────────────────────┘  │
│  ┌───────────────────────────────┐  │
│  │     连接池（每节点一个）        │  │
│  │  [Pool:1.1] [Pool:1.2] [Pool:1.3] │
│  └───────────────────────────────┘  │
│                                      │
│  流程：                              │
│  1. key → CRC16 → slot → 路由表查节点│
│  2. 从对应连接池取连接，发送命令      │
│  3. 收到 MOVED → 更新路由表 → 重试   │
│  4. 收到 ASK  → 发 ASKING → 重试     │
└─────────────────────────────────────┘

阶段 1：目标节点准备接收
  节点B: CLUSTER SETSLOT <slot> IMPORTING <nodeA_id>
  → 节点B 进入 IMPORTING 状态，允许接收来自 A 的 ASK 请求

阶段 2：源节点准备迁出
  节点A: CLUSTER SETSLOT <slot> MIGRATING <nodeB_id>
  → 节点A 进入 MIGRATING 状态：
    - 如果 key 存在：正常处理
    - 如果 key 不存在：返回 -ASK 重定向到 B

阶段 3：逐 key 迁移
  节点A: CLUSTER GETKEYSINSLOT <slot> <count>  → 获取槽中的 key 列表
  节点A: MIGRATE <host> <port> <key> 0 <timeout>  → 原子迁移单个 key
  重复直到槽为空

阶段 4：槽位归属切换
  对节点A和B以及所有其他节点（广播）:
  CLUSTER SETSLOT <slot> NODE <nodeB_id>
  → 槽位正式归 B 所有

# MIGRATE 命令格式
MIGRATE 192.168.1.2 6379 "" 0 5000 KEYS key1 key2 key3

# 参数说明：
# 192.168.1.2 6379 → 目标节点地址
# "" → 目标数据库（空密码）
# 0 → 目标数据库编号
# 5000 → 超时时间（毫秒）
# KEYS key1 key2 → 要迁移的 key 列表

假设现有 3 主 3 从集群，扩容到 4 主 4 从

步骤 1：启动新节点
  redis-server --port 6380 --cluster-enabled yes --cluster-config-file nodes-6380.conf

步骤 2：将新节点加入集群
  redis-cli --cluster add-node 192.168.1.4:6380 192.168.1.1:6379

步骤 3：为新节点添加从节点（可选）
  redis-cli --cluster add-node 192.168.1.5:6381 192.168.1.1:6379 --cluster-slave --cluster-master-id <新主节点ID>

步骤 4：重新分配槽位
  redis-cli --cluster reshard 192.168.1.1:6379
  # 交互式输入：
  # How many slots do you want to move? 4096
  # What is the receiving node ID? <新主节点ID>
  # Source node? all  （从所有现有节点各匀一部分）

客户端请求 GET user:9000：
  → 路由表可能指向 A 或 B（取决于客户端刷新时间）
  
  情况 1：请求到达 A
    - key 在 A 上 → 正常返回
    - key 已迁走 → 返回 -ASK 8000 B
    
  情况 2：请求到达 B
    - B 在 IMPORTING 状态 → 先查本地，没有则返回 -ASK（但 key 在 A）
    - 实际上 B 会返回 -ASK 8000 A（因为 key 还没迁过来）
    - 客户端发 ASKING 到 A → A 正常返回（因为还在 MIGRATING 状态）

# 步骤 1：将待下线节点的槽全部迁出
redis-cli --cluster reshard 192.168.1.1:6379
# 源节点：待下线节点；目标节点：其他节点；数量：该节点的全部槽

# 步骤 2：验证槽位已清空
redis-cli -h 192.168.1.4 -p 6380 cluster nodes | grep "myself"
# 确认该节点 numslots=0

# 步骤 3：从集群中移除节点
redis-cli --cluster del-node 192.168.1.1:6379 <待下线节点ID>

节点A 持续 PING 节点B，超过 cluster-node-timeout 没有收到 PONG：
  → 节点A 将节点B 标记为 PFAIL
  → PFAIL 是"我怀疑 B 挂了"，不是"B 确认挂了"

节点A 将节点B 标记为 PFAIL 后：
  → 节点A 在 Gossip 消息中携带"节点B 是 PFAIL"的信息
  → 其他节点收到后，检查自己是否也认为 B 是 PFAIL
  → 如果某个节点（如 C）在 cluster-node-timeout * 2 时间内，
    收到超过半数主节点报告 B 是 PFAIL：
    → 节点C 将 B 标记为 FAIL
    → 节点C 广播 FAIL 消息给所有节点

1. 从节点发现自己的主节点被标记为 FAIL
2. 从节点等待 cluster-node-timeout * 2 后，发起选举
3. 从节点递增 currentEpoch，向所有主节点发送 FAILOVER_AUTH_REQUEST
4. 每个主节点在每个 epoch 中只能投票一次（先到先得）
5. 从节点收到 ≥ N/2+1 张主节点票 → 当选
6. 新主节点递增 configEpoch，执行 SLAVEOF NO ONE
7. 通过 Gossip 广播新的槽位归属

集群分裂为两个分区：
  分区1：3 主（含主A） + 2 从
  分区2：2 主 + 1 从（主A的从）

分区2 中的从节点发现主A 失联超过 timeout：
  → 发起选举 → 当选为新主A'
  → 两个主A 同时对外服务 → 脑裂！

# 失败：key1 和 key2 可能在不同槽
MGET key1 key2

# 成功：使用 Hash Tag 强制同槽
MGET {user:1001}:name {user:1001}:age

客户端在节点A 发布消息 → 节点A 广播 PUBLISH 到所有节点
→ 订阅该频道的客户端无论在哪个节点都能收到

# redis.conf 集群相关配置

cluster-enabled yes                    # 启用集群模式
cluster-config-file nodes-6379.conf    # 集群状态持久化文件（自动维护）
cluster-node-timeout 15000             # 节点超时时间（毫秒），默认15秒
cluster-slave-validity-factor 10       # 从节点有效性因子
cluster-migration-barrier 1            # 从节点迁移屏障
cluster-require-full-coverage yes      # 是否需要所有槽位都有主节点
cluster-allow-reads-when-down no       # 集群不可用时是否允许读

# 查看集群状态
redis-cli -h 192.168.1.1 -p 6379 cluster info
# 输出：
# cluster_state:ok
# cluster_slots_assigned:16384
# cluster_slots_ok:16384
# cluster_slots_pfail:0
# cluster_slots_fail:0
# cluster_known_nodes:6
# cluster_size:3

# 查看节点详情
redis-cli cluster nodes

# 查看槽位分布
redis-cli cluster slots

# 手动故障转移
redis-cli -h <slave_ip> -p <slave_port> cluster failover
# 选项：
#   FORCE：强制故障转移（不检查主节点状态）
#   TAKEOVER：直接接管（不进行选举，危险！）

# 修复槽位
redis-cli --cluster fix 192.168.1.1:6379

# 检查集群
redis-cli --cluster check 192.168.1.1:6379

原因：某些槽位没有节点负责
排查：
  redis-cli cluster nodes  → 检查哪些节点是 fail 状态
  redis-cli --cluster fix  → 尝试自动修复
解决：
  - 如果是主节点挂了从节点没触发故障转移：手动 failover
  - 如果槽位确实无主：手动 CLUSTER ADDSLOTS 或迁移槽位

现象：客户端日志大量 MOVED 错误
原因：路由表过期或刷新不及时
解决：
  - 检查客户端拓扑刷新配置
  - 确保 cluster-node-timeout 设置合理
  - 检查是否有频繁的扩缩容操作

原因：MIGRATE 大 key 时阻塞主线程
排查：
  redis-cli --bigkeys  → 找出大 key
  SLOWLOG GET 100     → 检查慢日志
解决：
  - 对大 key 先拆分再迁移
  - 在低峰期进行迁移操作
  - 使用 redis-cli --cluster reshard --pipeline 参数加速