- ?鍵值槽位分配案例?
當執行 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?：逐批遷移鍵值數據，最終更新集群各節點槽位映射表。
以上案例展示了槽位分片的實際應用場景，涵蓋數據分布、動態擴縮容及操作限制等核心邏輯。
