- 键值槽位分配案例
当执行 SET {kaigejava}k1 v1 时，Redis 会提取 {} 内的有效部分 kaigejava，通过 CRC16 算法计算哈希值，再对 16384 取余得到槽位。例如：
若计算结果为 1495，则该键会被分配到槽位 1495 对应的节点。
若键为 num（无 {}），则直接对整个键计算哈希值，例如结果为 2765，则分配到对应槽位的节点。
2. 初始槽位分配示例
假设集群有 3 个主节点：
Node1：管理槽位 0-5460
Node2：管理槽位 5461-10922
Node3：管理槽位 10923-16383
此时，所有键根据哈希计算分配到对应槽位范围的节点上，实现数据分片存储。
例如，键 user:1001 计算后分配到槽位 8000，则由 Node2 负责存储。
3. 动态槽位迁移案例
当新增节点 Node4 时，集群会重新分配槽位。例如：
原由 Node3 管理的槽位 15001-16383 迁移到 Node4。
迁移过程中，Node3 将槽位内的键值逐步转移到 Node4，最终完成负载均衡和扩展。
操作命令示例：
bash
CLUSTER ADDSLOTS 15001-16383 # 将槽位分配给 Node4
- 跨槽操作限制案例
若执行 MGET key1 key2，且 key1 在槽位 100（Node1）、key2 在槽位 6000（Node2），Redis 会拒绝该操作并报错：
CROSSSLOT Keys in request don’t hash to the same slot
需确保多键操作的所有键映射到同一槽位。
- 槽位迁移流程示例
步骤1：目标节点准备接收槽位，命令 CLUSTER SETSLOT IMPORTING <source_id>。
步骤2：源节点启动迁移，命令 CLUSTER SETSLOT MIGRATING <target_id>。
步骤3：逐批迁移键值数据，最终更新集群各节点槽位映射表。
以上案例展示了槽位分片的实际应用场景，涵盖数据分布、动态扩缩容及操作限制等核心逻辑。
