實驗環境（3主3從的Redis-Cluster）
一、Redis重定向基礎篇
1、MOVED重定向
Redis Custer 中，客戶端可以向集群中任意節點發送請求。此時當前節點先對 Key 進行 CRC 16 計算，然后按 16384 取模確定 Slot 槽。確定該 Slot 槽所對應的節點，如果該 Slot 是當前節點負責，且該 Key 存在于該 Slot 中，則直接返回該 Key 對應的結果；如果該 Slot 不是當前節點負責，則返回 MOVED 重定向告知客戶端對應的節點地址信息。
2、測試
連接到redis-cluster
cd /opt
./redis-6.2.14/src/redis-cli -h 192.168.14.121 -p 18001
查詢key a
192.168.14.121:18001> get a
此時MOVED重定向告訴我們key a應該去192.168.14.123節點獲取
./redis-6.2.14/src/redis-cli -h 192.168.14.123 -p 18003
192.168.14.123:18003> get a
(正常獲取到數據)
3、測試（自動處理MOVED重定向）
在連接Redis時加上 -c 參數
-c Enable cluster mode (follow -ASK and -MOVED redirections).
cd /opt
./redis-6.2.14/src/redis-cli -h 192.168.14.121 -p 18001 -c
###還是查詢key a
192.168.14.121:18001> get a
直接幫我們重定向到key a 所在槽位的節點并返回數據。
此時可以總結出MOVED重定向的邏輯
同時還需要注意MOVED的核心原理
- Redis客戶端記錄的是槽與Redis服務器的對應關系，不是key與服務器的關系
二、Redis重定向進階篇
1、ASK重定向
Ask 重定向發生于 Redis 集群進行伸縮（擴容 / 縮容）時，由于此時會進行 Slot 槽遷移。當我們去源節點訪問時，數據可能已經遷移到目標節點中。故此時需要借助 Ask 重定向來解決該問題。
為什么不能繼續使用MOVED重定向？
因為Redis集群中槽的遷移的時候，是槽對應的多個Key分批次進行移動，不是一次性將某個槽內的key整體遷移，因此遷移的槽對應的Key，存在一部分在老的服務節點，一部分在新的服務節點。
所以當訪問的Key正在發生遷移時，判斷其位置需要比MOVED多一次判斷
彩蛋
有一種畫蛇添足的路子，讓Redis的客戶緩存Key的位置而不是槽的位置，這樣在重定向的時候性能不是大大提升了？，好像是提升了，但是Redis本身也廢了。
)
)