在生产环境中，业务量的增长往往不可预测。今天我们的Redis集群可能只有3个节点，明天可能就需要扩展到10个节点。如果每次扩容都要停机迁移数据，那简直是运维的噩梦。
幸运的是，Redis Cluster天生就支持动态伸缩 。它允许我们在不中断服务的情况下，像搭积木一样增加或减少节点。今天，我们就来揭秘这一"弹性"背后的核心操作------Add-Node 与Reshard。
第一步：请新成员入队（Add-Node）
假设我们现有的集群运行在7001-7003端口，现在为了应对流量高峰，我们启动了一台新的Redis实例（端口7004）。此时，7004只是一个孤独的节点，它并不知道集群的存在。
我们需要用一条命令把它"拉"进群里：
redis-cli --cluster add-node 127.0.0.1:7004 127.0.0.1:7001这条命令包含两个关键信息：
- 新节点 ：
127.0.0.1:7004（我们要加入的新人）。 - 现有节点 ：
127.0.0.1:7001（集群里的老成员，用于获取集群元数据）。
执行后，7004成功加入了集群。但请注意，此时它只是一个没有插槽（Slot）的Master。它虽然身在集群，却"无地可耕"，无法存储任何数据。如果我们现在尝试写入数据，会发现数据依然只分布在老节点上。
第二步：划分地盘（Reshard）
新节点加入后，为了让它分担压力，我们需要从老节点那里"匀"一部分插槽给它。这个过程叫重分片。
我们使用reshard命令来执行这一操作：
redis-cli --cluster reshard 127.0.0.1:7001执行该命令后，系统会进入交互式问答，我们需要依次回答三个核心问题：
- How many slots?
你需要输入迁移的插槽数量。例如，如果你想让新节点承担约20%的流量，可以输入3000（总共有16384个槽）。 - Receiving node?
你需要输入接收者 的节点ID。也就是我们新加入的7004节点的ID（可以通过cluster nodes命令查看）。 - Source nodes?
你需要输入贡献者 的节点ID。你可以指定某个特定的老节点（如7001），也可以输入all让所有老节点共同分担。
输入done确认源节点，最后输入yes确认执行。此时，你会看到终端疯狂刷屏，Redis正在后台将数据从老节点平滑地搬运到新节点。
验证成果：数据去哪儿了？
迁移完成后，神奇的事情发生了。假设num这个键原本哈希到了2765号插槽，而这个插槽恰好被分配给了7004。
当我们执行SET num 10时：
- 客户端计算哈希，发现属于7004。
- 数据直接写入7004。
通过cluster nodes命令，我们可以清晰地看到7004已经持有了属于它的插槽范围。扩容完成，且全程业务无感知！
课后思考：如何优雅地"裁员"？
学会了"加法"，"减法"同样重要。如果业务量下降，我们需要下线某个节点，该怎么做？
- 提示 ：使用
redis-cli --cluster help查看帮助。 - 核心难点 ：你不能直接删除一个还有数据的节点。必须先使用
reshard将该节点上的所有插槽全部迁移走，把它变成"光杆司令"，然后才能使用del-node命令将其移除。
知识小结：核心考点速查表
为了方便大家复习，我将本文的重点整理成了下表：
| 知识点 | 核心内容 | 考试重点/易混淆点 | 难度系数 |
|---|---|---|---|
| Redis集群伸缩功能 | 动态增加或移除节点，支持集群规模调整 | add-node命令需同时指定新节点和集群现有节点信息 |
⭐⭐ |
| add-node命令参数 | new_host:new_port（新节点） + existing_host:port（集群现有节点） |
未加选项时默认新增主节点，--cluster-slave可指定为从节点 |
⭐⭐ |
| 插槽分配 | 数据通过哈希槽分布，新增主节点后需手动迁移插槽 | reshard命令实现插槽迁移，需指定源节点ID和目标节点ID |
⭐⭐⭐ |
| 案例：扩容并存储数据 | 1. 新增主节点（7004） 2. 通过reshard将7001的插槽（含number键的2765槽）迁移至7004 |
迁移后数据自动跟随插槽，set number=10成功写入新节点 |
⭐⭐⭐⭐ |
| 删除节点（作业） | 需通过帮助文档查找命令（如del-node），需先清空节点插槽 |
移除主节点前需重新分配其全部插槽 | ⭐⭐⭐ |
总结
Redis Cluster的伸缩性是其最大的亮点之一。通过add-node引入新成员，再通过reshard公平地分配工作（插槽），我们就能轻松应对业务的增长。记住，数据是跟着插槽走的，只要掌握了插槽的分配权，你就掌握了Redis集群的命脉。