一、槽的遷移
redis 提供redis-trlib 可以讓運維手工調整槽位分配情況，
set key 的時候可以通過在key字符串裏嵌入tag 標記，強制把key 所掛的槽位等於tag 所在的槽位
如圖 所示，Redis 客戶端向“緩存節點 1”發出請求，此時“緩存節點 1”正向“緩存節點 2”遷移數據，如果沒有命中對應的 Slot，它會返回客戶端一個 ASK 重定向請求並且告訴“緩存節點 2”的地址。
客戶端向“緩存節點 2”發送 Asking 命令，詢問需要的數據是否在“緩存節點 2”上，“緩存節點 2”接到消息以後返回數據是否存在的結果。
大致流程：
- 從源點獲取內容
- 保存到目標節點
- 從源節點刪除內容
詳細圖
注意：
redis-cluster 數據遷移是同步的，在目標節點執行restore 指令到源節點刪除key 之間，源節點主線程處於阻塞狀態，直達key 被成功刪除。
所以操作的時候，不能在白天，選擇夜深人靜的時候。
如果遷移過程中遇到網絡故障，整個槽的遷移進行到一半，這市兩個節點依舊處於中間過渡狀態，待下次遷移工具連接，會提示用戶繼續進行遷移。
遷移時的性能：
如果可以都很小 migrate 的指令執行的很快，不會影響正常客戶端訪問，如果可以的內容很大，migrate會阻塞指令，會同時導致源節點和目標節點卡頓，影響集羣的穩定性，在集羣狀態下業務邏輯儘可能避免產生很大的key
思考：redis 支持的最大key 是
key 最大值 512m
key是按照hash查找的 ,當然越小 ,理論上越快 。 並沒有必然要多長的限制 ，儘量短就可以了！
Redis key值是二進制安全的，這意味着可以用任何二進制序列作爲key值，從形如”foo”的簡單字符串到一個JPEG文件的內容都可以。空字符串也是有效key值。
關於key的幾條規則：
太長的鍵值不是個好主意，例如1024字節的鍵值就不是個好主意，不僅因爲消耗內存，而且在數據中查找這類鍵值的計算成本很高。
太短的鍵值通常也不是好主意，如果你要用”u:1000:pwd”來代替”user:1000:password”，這沒有什麼問題，但後者更易閱讀，並且由此增加的空間消耗相對於key
object和value object本身來說很小。當然，沒人阻止您一定要用更短的鍵值節省一丁點兒空間。
最好堅持一種模式。例如：”object-type🆔field”就是個不錯的注意，像這樣”user:1000:password”。我喜歡對多單詞的字段名中加上一個點，就像這樣：”comment🔢reply.to”。
遷移時客戶端的訪問流程
遷移過程中，兩個節點對應的槽位都存在部分key數據，客戶端首先嚐試訪問舊的節點，如果對應的數據還在舊節點裏，舊節點正常處理。
如果不在舊節點，分兩種情況 1,在新節點 2，不存在
舊節點不清楚，所以向客戶端返回 -ASK targetNodeAddr重定向指令
客戶單去目標節點執行一個ASKING 指令，然後再在新節點執行原先的操作指令
執行ASKING 避免形成重定向循環。
ASKING 告訴新節點，不能不理，當做自己的槽位來處理。
正常情況下:
一個指令 一個ttl
遷移情況下 三個ttl
參考書籍：《Redis 深度歷險》
未經作者同意，本文禁止任何形式的轉載。