集群核心原理：哈希槽、分片规则、数据分布机制

Redis 集群（Redis Cluster）是 Redis 官方的分布式解决方案，核心目标是横向扩容、高可用、负载均衡。

它的底层完全围绕 哈希槽（Hash Slot） 实现数据分片与分布，我用最清晰、最容易理解的方式给你讲透。

---

一、核心一句话总结

Redis 集群把所有数据映射到 16384 个哈希槽中，然后把这些槽分配给不同节点。读写数据时，根据 key 计算出槽位 → 找到对应节点 → 完成操作。

---

二、什么是哈希槽（Hash Slot）？

固定数量

Redis 集群固定只有 16384 个哈希槽（2^14），不会多也不会少。

作用

哈希槽是数据与节点之间的中间层：

• 数据 → 映射到槽
• 槽 → 分配给节点

这样数据不直接绑定节点，方便扩容、缩容、迁移。

为什么是 16384？

官方原因：

• 心跳包大小控制（16384 用 2KB 就能表示槽状态）
• 集群节点上限 1000 个，16384 足够分配且性能最优

---

三、分片规则（数据 → 槽 的计算方式）

Redis 使用CRC16 算法 + 取模计算 key 属于哪个槽。

计算公式

plaintext

槽位 = CRC16(key) & 16383

流程

1. 对 key 做 CRC16 校验
2. 和 16383 做按位与
3. 得到 0~16383 之间的一个数字，就是哈希槽编号

特殊规则：键哈希标签（Hash Tag）

如果你想让多个 key 落在同一个槽（方便事务、多键操作），可以用 ​​{}​​：

plaintext

user:{100}:name
user:{100}:age

只会对 ​​100​​ 计算哈希，两个 key 会进入同一个槽、同一个节点。

---

四、数据分布机制：槽 → 节点 的分配规则

槽平均分配

集群会把 16384 个槽尽量平均分配到所有主节点。

示例：

• 3 主节点：

• 节点 A：0 ~ 5460
• 节点 B：5461 ~ 10922
• 节点 C：10923 ~ 16383

槽是连续区间分配，管理更高效。

数据分布规则

• 一个 key 永远只属于一个槽
• 一个槽永远只属于一个主节点
• 从节点只负责备份槽数据，不承担槽分配

数据读写流程（最核心）

1. 客户端连接任意节点
2. 节点计算 key 对应的槽
3. 如果槽属于本节点 → 直接处理
4. 如果不属于 → 返回 MOVED 重定向
5. 客户端缓存槽映射关系，下次直接访问正确节点

---

五、为什么要用哈希槽？（核心价值）

解耦数据与节点

数据 → 槽 → 节点，不是直接绑定节点。扩容 / 缩容只需要迁移槽，不用动整个节点。

无中心架构

不需要中心化路由，每个节点都保存完整槽映射表。

天然支持分片

自动把数据打散到不同节点，实现负载均衡。

高可用

主节点挂了，从节点自动接管它的哈希槽继续服务。

---

六、扩容与数据迁移原理（基于槽）

扩容新节点时：

1. 从其他老节点迁移一部分哈希槽到新节点
2. 迁移过程在线进行，不中断服务
3. 迁移完成后，集群重新分配槽映射

缩容下线节点时：

1. 把该节点的所有槽迁移到其他节点
2. 槽空了之后安全下线节点
3. 集群自动更新映射表

---

七、Redis 集群数据分布机制总结图

plaintext

客户端
   ↓
key → CRC16 → 哈希槽（0~16383）
   ↓
槽分配给主节点
   ↓
节点 A  节点 B  节点 C
(槽x)   (槽y)   (槽z)

---

八、超简记忆口诀

• 固定 16384 个槽
• key 算槽，槽归节点
• 分片靠 CRC16 取模
• 迁移只动槽，不动节点
• 从节点备份槽，不分配槽

---

总结

1. 哈希槽：Redis 集群的核心，共 16384 个，是数据分片的基础单位
2. 分片规则：CRC16(key) & 16383 计算槽位，支持 Hash Tag 强制同槽
3. 数据分布：槽平均分配给主节点，从节点只做备份；客户端通过重定向缓存槽映射
4. 优势：无中心、易扩容、高可用、天然分布式

三主三从、多主多从集群标准化搭建

Redis 原生集群采用无中心去中心化架构，核心要求：至少 3 个主节点（奇数主节点防止脑裂），三主三从是生产环境标准高可用配置；多主多从是在 3 主基础上扩展主节点（提升写吞吐量）+ 扩展从节点（提升读吞吐量 / 冗余）。

本教程基于 Redis 7.2（最新稳定版），采用单机多节点（测试）/ 多机多节点（生产通用）标准化搭建，覆盖：环境优化 → 节点配置 → 集群初始化 → 验证 → 扩容 → 运维规范。

---

一、核心架构定义

三主三从（标准高可用）

• 主节点：3 个（均分 0~16383 哈希槽，负责写请求）
• 从节点：3 个（每个主节点绑定 1 个从节点，负责读请求 + 故障自动切换）
• 高可用：任意主节点宕机，对应从节点自动升级为主节点

多主多从（性能扩展）

• 主节点：≥3 个（如 5 主、7 主，槽位重新均分，提升写能力）
• 从节点：每个主节点配 1~N 个从节点（提升读能力 + 冗余）

---

二、标准化环境准备（生产必做）

基础环境

• 系统：CentOS 7/8 / Ubuntu 20.04+
• Redis：7.2.4（稳定版，5.0+ 弃用 Ruby，原生支持集群）
• 网络：关闭防火墙 / 开放集群端口（节点端口 + 10000 为集群总线端口）
• 权限：使用普通用户，禁止 root 运行 Redis

系统内核优化（Redis 集群强制要求）

bash

运行

# 1. 关闭防火墙&SELinux
systemctl stop firewalld && systemctl disable firewalld
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config && setenforce 0# 2. 内核参数优化（解决内存/连接/性能问题）cat >> /etc/sysctl.conf << EOF
vm.overcommit_memory = 1    # Redis内存分配策略
net.core.somaxconn = 512    # 最大连接数
EOFsysctl -p  # 生效# 3. 关闭透明大页（Redis官方强制要求）echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo "echo never > /sys/kernel/mm/transparent_hugepage/enabled" >> /etc/rc.local
chmod +x /etc/rc.local

安装 Redis

bash

运行

# 下载&编译wget https://download.redis.io/releases/redis-7.2.4.tar.gz
tar -zxvf redis-7.2.4.tar.gz && cd redis-7.2.4
make && make PREFIX=/usr/local/redis install# 配置环境变量echo "export PATH=\$PATH:/usr/local/redis/bin" >> /etc/profile
source /etc/profile

---

三、三主三从集群 标准化搭建

节点规划（单机测试 / 多机生产通用）

我们用 6 个节点（端口：7001~7006），角色自动分配：

• 主节点：7001、7002、7003
• 从节点：7004、7005、7006（分别对应主节点）

标准化目录结构（生产规范）

bash

运行

# 创建集群根目录+6个节点目录（conf:配置 data:数据 log:日志）mkdir -p /opt/redis-cluster/{7001,7002,7003,7004,7005,7006}/{conf,data,log}

集群配置文件模板（核心！）

创建通用配置模板 ​​/opt/redis-cluster/redis-cluster.conf​​，后续批量修改端口：

ini

# 端口（批量替换）
port 7001
# 绑定所有IP（生产改为服务器内网IP）
bind 0.0.0.0
# 关闭保护模式
protected-mode no
# 后台运行
daemonize yes
# 集群开关（核心！）
cluster-enabled yes
# 集群节点配置文件（自动生成，禁止手动修改）
cluster-config-file nodes.conf
# 集群节点超时时间
cluster-node-timeout 5000
# 数据目录
dir /opt/redis-cluster/7001/data
# 日志目录
logfile /opt/redis-cluster/7001/log/redis.log
# 生产密码（所有节点密码必须一致！）
requirepass 123456
masterauth 123456
# 持久化（生产必开）
appendonly yes
appendfsync everysec

批量生成 6 个节点配置

bash

运行

# 循环替换端口，生成每个节点的redis.conffor port in {7001..7006};dosed \-e "s/7001/${port}/g" \
  /opt/redis-cluster/redis-cluster.conf \> /opt/redis-cluster/${port}/conf/redis.conf
done

启动所有节点

bash

运行

# 启动6个Redis节点for port in {7001..7006};do
  redis-server /opt/redis-cluster/${port}/conf/redis.conf
done# 检查进程（看到6个redis-server即为成功）ps -ef | grep redis

初始化三主三从集群（关键步骤）

Redis 5.0+ 原生集群命令，​​--cluster-replicas 1​​ 表示每个主节点配 1 个从节点：

bash

运行

# 替换为你的服务器IP（多机则填不同IP）
redis-cli -a 123456 --cluster create \192.168.1.100:7001 192.168.1.100:7002 192.168.1.100:7003 \192.168.1.100:7004 192.168.1.100:7005 192.168.1.100:7006 \
--cluster-replicas 1

执行后输入 ​​yes​​ 确认，等待集群初始化完成（自动分配哈希槽 + 主从关系）。

---

四、集群验证（标准化检查）

连接集群（-c 表示集群模式）

bash

运行

redis-cli -c -a 123456 -p 7001

核心验证命令

bash

运行

# 1. 查看集群状态（显示ok即为正常）
cluster status

# 2. 查看节点信息（主节点带master，从节点带slave）
cluster nodes

# 3. 数据分片验证（自动路由到对应节点）set test_redis hello
get test_redis

高可用验证

bash

运行

# 停止一个主节点（如7001）
redis-cli -a 123456 -p 7001 shutdown# 再次查看节点，原从节点会自动升级为主节点
redis-cli -c -a 123456 -p 7002 cluster nodes

---

五、多主多从集群 标准化扩容

在三主三从基础上，扩容为 5 主 5 从（通用多主多从流程）：

新增节点（7007~7010，2 主 2 从）

bash

运行

# 创建新节点目录mkdir -p /opt/redis-cluster/{7007,7008,7009,7010}/{conf,data,log}# 批量生成配置+启动for port in {7007..7010};dosed -e "s/7001/${port}/g" /opt/redis-cluster/redis-cluster.conf > /opt/redis-cluster/${port}/conf/redis.conf
  redis-server /opt/redis-cluster/${port}/conf/redis.conf
done

添加主节点到集群

bash

运行

# 添加7007作为主节点（连接任意现有主节点）
redis-cli -a 123456 --cluster add-node 192.168.1.100:7007 192.168.1.100:7001
# 添加7008作为主节点
redis-cli -a 123456 --cluster add-node 192.168.1.100:7008 192.168.1.100:7001

重新分配哈希槽（新主节点必须分配槽位才能存储数据）

bash

运行

# 自动均衡槽位（跟随指引操作）
redis-cli -a 123456 --cluster reshard 192.168.1.100:7001

添加从节点（绑定主节点）

bash

运行

# 7009作为7007的从节点（替换node_id为7007的节点ID）
redis-cli -a 123456 --cluster add-node 192.168.1.100:7009 192.168.1.100:7007 --cluster-slave --cluster-master-id 节点ID

# 7010作为7008的从节点
redis-cli -a 123456 --cluster add-node 192.168.1.100:7010 192.168.1.100:7008 --cluster-slave --cluster-master-id 节点ID

验证扩容

bash

运行

redis-cli -c -a 123456 -p 7001 cluster nodes

此时集群变为 5 主 5 从，完成多主多从搭建。

---

六、Redis 集群 标准化运维命令

bash

运行

# 1. 查看集群状态
redis-cli -a 123456 --cluster check 127.0.0.1:7001

# 2. 均衡集群槽位（生产定期执行）
redis-cli -a 123456 --cluster rebalance 127.0.0.1:7001

# 3. 删除节点（先删从节点，再删主节点）
redis-cli -a 123456 --cluster del-node 127.0.0.1:7001 节点ID

# 4. 手动主从切换
redis-cli -a 123456 -p 7004 cluster failover

---

七、生产标准化规范 & 避坑指南

强制规范

1. 所有节点密码一致（requirepass=masterauth）
2. 集群端口必须开放：业务端口（700x）+ 集群总线端口（1700x）
3. 禁止手动修改 nodes.conf（集群自动生成的节点配置文件）
4. 主节点数量必须为奇数（3、5、7），防止脑裂
5. 生产环境多机部署（一主一从分属不同物理机）

常见问题

1. 集群初始化失败：检查内核优化、端口、节点是否启动
2. 数据无法写入：新主节点未分配哈希槽
3. 主从不同步：密码不一致、总线端口未开放

---

总结

1. 三主三从是 Redis 集群标准高可用方案，满足 90% 生产场景；多主多从用于高并发写场景
2. 搭建核心：开启cluster-enabled yes + 统一密码 + 自动分配槽位
3. 生产必做：内核优化、多机部署、持久化、密码认证、集群监控

集群伸缩：在线扩容、缩容、节点上下线实操

本文基于 Redis 5.0+ 版本（使用​​redis-cli​​原生集群命令，弃用老旧 Ruby 脚本），以3 主 3 从标准集群为初始环境，手把手完成节点上线（扩容）、在线槽位迁移、节点下线（缩容） 全流程实操，全程无业务中断、在线无感操作。

---

一、前置环境准备

初始集群架构

我们以3 主 3 从 Redis 集群为基础：

• 主节点：7001、7002、7003
• 从节点：7004、7005、7006
• 哈希槽：0~16383 均匀分配给 3 个主节点
• 所有节点开启集群模式：cluster-enabled yes

核心基础命令（必记）

bash

运行

# 1. 检查集群状态、槽位分配、节点角色
redis-cli --cluster check 127.0.0.1 7001# 2. 查看集群节点详情（节点ID、角色、槽位）
redis-cli -p 7001 cluster nodes

所有操作前，优先执行集群检查，确保初始状态正常！

---

二、在线扩容（节点上线）

扩容分两种场景：扩容从节点（提升高可用）、扩容主节点（分担数据 / 算力），主节点扩容需要在线迁移哈希槽。

场景 1：扩容从节点（极简，无数据迁移）

直接新增从节点，挂载到指定主节点，提升集群冗余。

步骤 1：启动新从节点

配置新节点​​7007​​（端口、数据目录修改，集群配置保持一致），启动服务：

bash

运行

redis-server /usr/local/redis-cluster/7007/redis.conf

步骤 2：将新节点加入集群，指定主节点

bash

运行

# 命令格式：add-node 新节点 集群任意节点 --cluster-slave --cluster-master-id 主节点ID
redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7001 --cluster-slave --cluster-master-id 7001的节点ID

步骤 3：验证

执行​​cluster check​​，看到​​7007​​成为​​7001​​的从节点，扩容完成。

---

场景 2：扩容主节点（核心，在线槽位迁移）

新增主节点，在线将旧主节点的哈希槽迁移到新主节点，实现数据分流。

步骤 1：启动新主节点

配置并启动新主节点​​7008​​：

bash

运行

redis-server /usr/local/redis-cluster/7008/redis.conf

步骤 2：将新主节点加入集群

此时新节点无哈希槽、无数据，仅作为集群空节点：

bash

运行

# 命令格式：add-node 新主节点 集群任意节点
redis-cli --cluster add-node 127.0.0.1:7008 127.0.0.1:7001

步骤 3：在线迁移哈希槽（核心操作）

Redis 集群通过哈希槽分片数据，必须将槽位迁移到新主节点，它才能承载数据：

bash

运行

# 命令格式：reshard 集群任意节点
redis-cli --cluster reshard 127.0.0.1:7001

执行后按交互提示输入：

1. ​​How many slots do you want to move (from 1 to 16383)?​​输入要迁移的槽数（3 主扩容为 4 主，平均分配：5461）
2. ​​What is the receiving node ID?​​输入新主节点 7008 的 ID（接收槽位的节点）
3. ​​Please enter all the source node IDs: ​​输入all（从所有旧主节点抽取槽位），或指定旧主节点 ID
4. 最后输入yes确认迁移

步骤 4：验证扩容

执行​​cluster check​​，看到 4 个主节点均匀分配哈希槽，数据在线迁移完成，业务无感知。

可选：给新主节点添加从节点

重复【场景 1】，为​​7008​​挂载从节点​​7009​​，恢复高可用。

---

三、在线缩容（节点下线）

缩容分两种场景：下线从节点（直接删除）、下线主节点（必须先迁移槽位，再删除）。

场景 1：下线从节点（无风险，直接删除）

从节点无哈希槽，直接移除即可。

步骤 1：查询要下线的从节点 ID

bash

运行

redis-cli -p 7001 cluster nodes

步骤 2：删除从节点

bash

运行

# 命令格式：del-node 集群任意节点 要下线的节点ID
redis-cli --cluster del-node 127.0.0.1:7001 7007的节点ID

步骤 3：关闭节点服务

bash

运行

redis-cli -p 7007 shutdown

步骤 4：验证

集群检查显示从节点已移除，缩容完成。

---

场景 2：下线主节点（核心，先迁槽再下线）

主节点承载哈希槽和数据，绝对不能直接删除！必须先将其所有槽位迁移到其他主节点，再下线。

步骤 1：迁移下线主节点的全部槽位

假设下线主节点​​7003​​，将其槽位全量迁移到​​7001/7002​​：

bash

运行

redis-cli --cluster reshard 127.0.0.1:7001

交互输入：

1. 迁移槽数：7003的总槽数（check 命令可查）
2. 接收节点 ID：7001或7002的ID
3. 源节点 ID：7003的ID（仅从该节点抽取）
4. 输入yes确认迁移

步骤 2：验证主节点槽位为空

执行​​cluster check​​，确认​​7003​​无任何哈希槽。

步骤 3：删除主节点

bash

运行

redis-cli --cluster del-node 127.0.0.1:7001 7003的节点ID

步骤 4：关闭节点服务

bash

运行

redis-cli -p 7003 shutdown

步骤 5：验证缩容

集群恢复为2 主 2 从，槽位分配正常，数据无丢失。

---

四、业务数据验证（必做）

扩容 / 缩容完成后，验证数据读写正常，确保集群可用：

bash

运行

# 连接集群（加-c参数，自动路由槽位）
redis-cli -p 7001 -c# 写入测试数据set test_key hello_redis_cluster

# 读取数据
get test_key

# 查看键所在的槽位和节点
cluster keyslot test_key

---

五、核心命令速查表

表格

操作场景	命令模板
检查集群状态	redis-cli --cluster check IP 端口
添加从节点	add-node 新节点 集群节点 --cluster-slave --cluster-master-id 主节点ID
添加主节点	add-node 新主节点 集群节点
在线迁移哈希槽	reshard 集群节点
删除节点（从 / 空主）	del-node 集群节点 节点ID
查看集群节点	redis-cli -p 端口 cluster nodes

---

六、生产环境注意事项

1. 在线无中断：Redis 集群槽位迁移为异步在线操作，业务无需停机；
2. 主节点下线铁律：必须先迁移全部哈希槽，再删除节点；
3. 数据安全：缩容前备份数据，扩容后验证主从同步；
4. 槽位均匀：扩容 / 缩容后，保证哈希槽均匀分配，避免节点负载倾斜；
5. 从节点冗余：每个主节点至少保留 1 个从节点，保证高可用；
6. 版本统一：集群所有节点 Redis 版本必须一致，避免兼容性问题。

---

总结

1. Redis 集群伸缩核心是哈希槽在线迁移，全程无业务中断；
2. 从节点可直接上下线，主节点必须先迁槽、再下线；
3. 所有操作依赖redis-cli --cluster原生命令，简单高效；
4. 生产环境严格遵循「先检查→再操作→后验证」流程。

集群路由、重定向机制与客户端适配

Redis 集群（Redis Cluster）是 Redis 官方的分布式解决方案，核心解决数据分片、高可用、水平扩展问题。其正常工作的核心依赖 哈希槽路由 + 重定向机制，而客户端必须适配这两个机制才能正确访问集群。

本文会从基础原理→路由流程→重定向细节→客户端适配逐层讲解，覆盖核心知识点与实战用法。

---

一、核心基础：哈希槽分片（路由的依据）

Redis 集群采用哈希槽（Hash Slot） 实现数据分片，这是所有路由逻辑的基础：

1. 固定槽数：集群总共有 16384 个哈希槽（0~16383）。
2. 槽分配：所有哈希槽会均匀分配给集群中的主节点（从节点不负责槽，仅做备份）。例：3 主节点集群，节点 1 负责 0~5460，节点 2 负责 5461~10922，节点 3 负责 10923~16383。
3. key 与槽的映射：对 key 计算哈希值，取模得到槽位：
4. plaintext

槽位 = CRC16(key) & 16383

1. 数据归属：一个 key 永远属于计算出的槽位，也就属于负责该槽的主节点。

---

二、Redis 集群路由机制

路由的本质：客户端找到 key 对应的槽 → 找到负责该槽的节点 → 直接访问。

Redis 集群有两种路由模式，智能客户端优先使用第一种：

智能客户端直连路由（最优）

这是生产环境的标准模式，核心是客户端缓存集群拓扑：

1. 客户端初始化时，连接任意一个集群节点，拉取完整的「槽→节点」映射表并缓存到本地；
2. 每次操作 key 时，本地计算槽位，直接找到对应主节点发起请求；
3. 无额外网络跳转，性能最高，无重定向开销。

服务端转发路由（兼容模式）

非智能客户端随机连接一个节点，节点收到请求后：

1. 自己计算 key 的槽位；
2. 如果槽归自己处理，直接执行命令；
3. 如果槽不归自己，返回重定向指令，让客户端去正确节点访问。

---

三、Redis 集群重定向机制（核心难点）

当客户端访问的节点不负责目标 key 的槽时，节点会返回重定向错误，客户端根据错误类型处理。

Redis 定义了两种重定向：​​MOVED​​（永久重定向）、​​ASK​​（临时重定向），这是集群扩容 / 缩容 / 故障转移的关键。

MOVED 重定向（永久）

触发场景

槽的归属永久改变：

• 集群扩容 / 缩容，槽迁移完成；
• 主节点宕机，槽被故障转移到新主节点。

响应格式

plaintext

-MOVED <槽位> <目标节点IP:端口>

处理逻辑

1. 客户端收到 MOVED，说明槽的归属永久变更；
2. 更新本地缓存的槽映射表（同步最新集群拓扑）；
3. 直接向目标节点重新发起请求。

---

ASK 重定向（临时）

触发场景

槽正在迁移中（未完成）：

• 集群扩容，槽从旧主节点逐步迁移到新主节点；
• 部分 key 已经迁移，部分还在旧节点。

响应格式

plaintext

-ASK <槽位> <目标节点IP:端口>

处理逻辑

1. 客户端收到 ASK，说明槽仅临时迁移，未完成；
2. 不更新本地槽映射（保持原有拓扑）；
3. 先向目标节点发送 ASKING 命令（临时授权访问），再发起真实请求；
4. 下次其他 key 仍按旧映射访问。

---

MOVED vs ASK 核心区别

表格

特性	MOVED 重定向	ASK 重定向
性质	永久变更	临时迁移
客户端动作	更新本地槽映射缓存	不更新缓存
触发场景	槽迁移完成 / 故障转移	槽正在迁移中
额外命令	无需	必须先发送 ASKING

---

四、客户端适配方案

普通客户端无法直接使用 Redis 集群，必须适配路由 + 重定向机制。我们分工具客户端和开发语言客户端（重点 Java）讲解。

命令行工具：redis-cli

加 ​​-c​​ 参数即可自动跟随重定向，无需手动处理：

bash

运行

# 连接集群节点，自动处理 MOVED/ASK
redis-cli -c -p 7000

执行命令时，cli 会自动跳转至正确节点，控制台会打印重定向日志。

Java 客户端（生产主流）

Java 生态有三大集群客户端，全部自动适配路由和重定向，无需开发者手动处理：

（1）Lettuce（Spring Boot 默认客户端 ✅）

• 异步、非阻塞，性能最优；
• 自动缓存槽映射、处理 MOVED/ASK、刷新集群拓扑；
• Spring Data Redis 开箱即用，无需额外配置。

最简配置（application.yml）：

yaml

spring:redis:cluster:nodes: 192.168.1.10:7000,192.168.1.10:7001,192.168.1.10:7002

（2）Jedis

• 同步客户端，老牌稳定；
• 使用 JedisCluster 类实现集群适配，自动处理重定向。

核心代码：

java

运行

Set<HostAndPort> nodes = new HashSet<>();
nodes.add(new HostAndPort("192.168.1.10", 7000));// 创建集群客户端，自动适配路由JedisCluster cluster = new JedisCluster(nodes);
cluster.set("key", "value"); // 无感知路由

（3）Redisson

• 分布式框架，支持分布式锁、限流等；
• 底层自动适配 Redis 集群路由与重定向。

---

客户端适配的核心要求

所有智能客户端必须实现这 4 个能力：

1. 拉取集群拓扑：初始化时获取「槽→节点」映射；
2. 本地计算槽位：不依赖服务端，本地计算 key 槽位；
3. 自动处理重定向：区分 MOVED/ASK 执行不同逻辑；
4. 定时刷新拓扑：感知集群节点 / 槽的变化。

---

五、完整工作流程（总结）

1. 客户端初始化，拉取并缓存16384 个槽的节点映射表；
2. 执行 set name redis，客户端本地计算 name 的槽位；
3. 根据缓存映射，直接访问对应主节点；
4. 若节点返回：

1. ​​MOVED​​：更新缓存，重新请求新节点；
2. ​​ASK​​：发送 ASKING，临时请求新节点；

1. 集群扩容 / 缩容时，客户端无感知，自动适配。

---

六、常见问题

1. 直接用普通客户端连接单节点报错 MOVED？答：未使用集群客户端，普通客户端不处理重定向，必须用 JedisCluster/Lettuce 等集群客户端。
2. 集群路由会访问从节点吗？答：默认只路由到主节点，从节点仅做高可用备份；如需读写分离，需客户端额外配置。
3. 哈希槽可以手动分配吗？答：可以，Redis 支持手动迁移槽，用于定制化分片。

---

总结

1. 路由核心：基于 16384 个哈希槽，客户端本地计算槽位直连节点；
2. 重定向：MOVED（永久变更，更新缓存）、ASK（临时迁移，不更新）；
3. 客户端适配：生产必须用智能集群客户端（Lettuce/JedisCluster），自动处理所有路由逻辑；
4. 最佳实践：Spring Boot 直接使用默认 Lettuce，无需手动开发重定向逻辑。