一. ASK錯誤 集群上篇最後講到，對於重新分片由redis-trib負責執行，關於該工具以後再介紹。在進行重新分片期間，源節點向目標節點遷移一個槽的過程中，可以會出現該槽中的一部分鍵值對保存在源節點中，另一部份鍵值對則保存在目標節點中。 當客戶端向源節點發送一個與資料庫鍵有關的命令時，並且命令要處 ...
一. ASK錯誤
集群上篇最後講到，對於重新分片由redis-trib負責執行，關於該工具以後再介紹。在進行重新分片期間，源節點向目標節點遷移一個槽的過程中，可以會出現該槽中的一部分鍵值對保存在源節點中，另一部份鍵值對則保存在目標節點中。
當客戶端向源節點發送一個與資料庫鍵有關的命令時，並且命令要處理的資料庫鍵正好就是正在被遷移的槽時，會出現二種情況的一種：
(1) 源節點會先在自己的資料庫中查找指定的鍵，如果找到的話，就會直接執行客戶端發送的命令。
(2) 相反，如果在源節點找不到指定的鍵，那麼鍵有可能已經被遷移到了目標節點，源節點將向客戶端返回一個ASK錯誤，指引客戶端轉向正在導入槽的目標節點，並再次發送之前想要執行的命令。
註意：和接到Moved錯誤時的情況一樣，集群模式的redis-cli在接到ask錯誤時也不會列印錯誤，而是自動根據錯誤提供的ip和port進行轉向(Redirected to ..)動作。
1.1 cluster setslot importing 命令實現
在clusterState結構的importing_slots_from數組中，記錄了當前節點正在從其他節點導入的槽號。在集群進行重新分片的時候，向目標節點發送以下命令，格式為：
cluster setslot < slot > importing <node ID>
slot 和 node_id是指：源節點槽號和源節點ID。比如在上一篇結尾，原屬於7002節點的14042 號槽，遷移到了目標7003節點，在7003節點中內部clusterState結構的importing_slots_from數組下記錄了14042號槽，並且還記錄了源節點ip和埠（127.0.0.1 7002）。
1.2 cluster setslot migrating命令實現
在clusterState結構的 migrating_slots_to數組中，記錄了當前節點正在遷移至其他節點的槽。在集群進行重新分片的時候，向源節點發送命令以下命令，格式為：
cluster setslot < slot > migrating <node ID>
slot 和 node_id是指：目標節點槽號和目標節點ID。
下圖左邊7003目標節點 importing_slots_from數組 和 右邊7002源節點的migrating_slots_to數組：
1.3 ASK錯誤後的引導
如果節點收到一個關於鍵key的命令請求，並且鍵key所屬的槽i正好就指派給了這個節點， 如果節點沒有在自己的資料庫里找到鍵key，那麼節點會檢查自己的遷移數組clusterState.migrating_slots_to[i], 看鍵key所屬的槽i是否正在進行遷移，如果槽 i 的確在進行遷移，那麼節點會向客戶端發送一個ask錯誤，引導客戶端到正在導入槽 i 的節點去查找鍵key。
1.4 ASK錯誤和Moved錯誤的區別
ASK錯誤和Moved錯誤都會導致客戶端轉向，它們區別在於：
(1) Moved錯誤代表槽的負責權，已經從一個節點轉移到了另一個節點：在客戶端收到關於槽i的mvoed錯誤之後，客戶端每次遇到關於槽i的命令請求時，都可以直接將命令請求發送到moved錯誤所指向的節點，因為該節點就是目前負責槽i的節點。
(2) 與此相反，ASK錯誤只是兩個節點在遷移槽的過程中使用的一種臨時措施：在客戶端收到關於槽 i 的ASK錯誤之後，客戶端只會在接下來的一次命令請求中將關於槽 i 的命令請求發送到ASK錯誤所指示的節點。
二. 複製與故障轉移
集群中的節點分為主節點和從節點，主節點用於處理槽，而從節點則用於複製某個主節點，當主節點下線時，從節點代替主節點繼續處理命令請求。
複製設置從節點：在主節點將設置 node_id (node_id為從節點),腳本如下:
CLUSTER REPLICATE <node_id>
2.1 節點故障檢測
集群中的每個節點都會定期向群集中的其他節點發送ping消息，以此來檢測對方是否線上，如果接收ping消息的節點沒有在規定的時間內返回pong消息，那麼發送節點就會將接收節點標記為疑似下線pfail(probable fail)。
集群中的各個節點會通過互相發送消息的方式來交換集群中各個節點的狀態信息，來判斷節點是處於線上、疑似下線還是下線(fail) 狀態。
在集群中，負責處理槽的節點在半數以上都將某個主節點x 報告為疑似下線狀態時，那麼這個主節點x將標記為已下線 fail。 將主節點x標記為已下線的節點會向集群廣播一條關於主節點x的fail消息。
2.2 故障轉移實現步驟
當一個從節點發現自己正在複製的主節點進入已下線狀態時，從節點將開始對下線主節點進行故障轉移，步驟如下:
(1) 複製下線主節點的所有從節點，會有一個從節點被選中。
(2) 被選中的從節點會執行slaveof no one 命令，成為新的主節點。
(3) 新的主節點會撤消所有對已下線主節點的槽指派，並將這些槽指派給自己。
(4) 新的主節點向集群廣播一條pong消息，這條pong消息可以讓集群中的其他節點立即知道這個節點已經由從節點變成了主節點，並且接管了原本已下線的節點負責處理的槽。
(5) 新的主節點開始接收和自己負責處理的槽有關的命令請求，故障轉移完成。
2.3 節點之間的通信
集群中的各個節點通過發送和接收消息來進行通信，節點發送的消息主要以5種：
(1) meet消息: 發送者向接收者發送meet消息，請求接收者加入到發送者當前所處的集群中。
(2) ping消息:集群中每個節點預設每隔1秒就會從已知節點列表隨機選出5個節點，然後對這5個節點中最長時間沒有發送過ping消息的節點發送ping消息，以此來檢測被選中的節點是否線上。
(3) pong消息：當接收者收到meet或ping消息時，會向發送者返回一條pong消息，以此表明自己(接收者)節點是正常的。另外一個節點也可以通過向集群廣播自己的pong消息來讓集群中的其他節點刷新關於這個節點的認識。
(4) Fail消息: 當一個主節點A判斷另一個主節點B已經進入Fall狀態時，節點A會向集群廣播一條關於節點B的Fall消息，所有收到這條消息的節點都會立即將節點B標記為已下線。
(5) publish消息: 當節點接收到一個publish命令時，節點會執行這個命令，並向集群廣播一條publish消息，所有接收到這條publish消息的節點都會執行相同的publish命令。
三. 集群知識點總結
(1) 節點通過握手來將其他節點添加到自己所處的集群當中。
(2) 集群中的16384個槽可以分別指派給集群中的各個節點，通過cluster nodes命令可以看到節點的槽分佈。
(3) 節點在接到一個命令請求時，先檢查這個命令請求要處理的鍵所在的槽是否由自己負責，如果不是，節點向客戶端返回一個moved錯誤，moved錯誤攜帶的信息可以指引客戶端轉向至正在負責相關槽的節點繼續來處理。
(4)對Redis集群的重新分片工作是由redis-trib負責執行的，重新分片是將屬於某個槽的所有鍵值對從一個節點轉移至另一個節點。
(5)如果節點A正在遷移槽 i 到節點B，當節點A沒能在自己的資料庫中找到命令指定的鍵時，節點A向客戶端返回一個ASK錯誤，指引客戶端到節點B繼續查找指定鍵。
(6) Moved錯誤代表槽的負責權已經從一個節點轉移到了另一個節點，而ASK錯誤只是兩個節點在遷移槽的過程中使用的一種臨時措施。
(7) 集群中的從節點用於複製主節點，併在主節點下線時，代替主節點繼續處理命令請求。
(8) 集群中的節點通過發送和接收消息來進行通信，常見的消息包括meet;ping ;pong;publish;fail五種。
