溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
先回憶一下第一篇文章提到的一些信息，TiKV 集群是 TiDB 數據庫的分布式 KV 存儲引擎，數據以 Region 為單位進行復制和管理，每個 Region 會有多個 Replica（副本），這些 Replica 會分布在不同的 TiKV 節點上，其中 Leader 負責讀/寫，Follower 負責同步 Leader 發來的 raft log。了解了這些信息后，請思考下面這些問題：
這些問題單獨拿出可能都能找到簡單的解決方案，但是混雜在一起，就不太好解決。有的問題貌似只需要考慮單個 Raft Group 內部的情況，比如根據副本數量是否足夠多來決定是否需要添加副本。但是實際上這個副本添加在哪里，是需要考慮全局的信息。整個系統也是在動態變化，Region 分裂、節點加入、節點失效、訪問熱點變化等情況會不斷發生，整個調度系統也需要在動態中不斷向最優狀態前進，如果沒有一個掌握全局信息，可以對全局進行調度，并且可以配置的組件，就很難滿足這些需求。因此我們需要一個中心節點，來對系統的整體狀況進行把控和調整，所以有了 PD 這個模塊。
上面羅列了一大堆問題，我們先進行分類和整理。總體來看，問題有兩大類：
作為一個分布式高可用存儲系統，必須滿足的需求，包括四種：
作為一個良好的分布式系統，需要優化的地方，包括：
滿足第一類需求后，整個系統將具備多副本容錯、動態擴容/縮容、容忍節點掉線以及自動錯誤恢復的功能。滿足第二類需求后，可以使得整體系統的負載更加均勻、且可以方便的管理。
為了滿足這些需求，首先我們需要收集足夠的信息，比如每個節點的狀態、每個 Raft Group 的信息、業務訪問操作的統計等；其次需要設置一些策略，PD 根據這些信息以及調度的策略，制定出盡量滿足前面所述需求的調度計劃；最后需要一些基本的操作，來完成調度計劃。
我們先來介紹最簡單的一點，也就是調度的基本操作，也就是為了滿足調度的策略，我們有哪些功能可以用。這是整個調度的基礎，了解了手里有什么樣的錘子，才知道用什么樣的姿勢去砸釘子。
上述調度需求看似復雜，但是整理下來最終落地的無非是下面三件事：
剛好 Raft 協議能夠滿足這三種需求，通過 AddReplica、RemoveReplica、TransferLeader 這三個命令，可以支撐上述三種基本操作。
調度依賴于整個集群信息的收集，簡單來說，我們需要知道每個 TiKV 節點的狀態以及每個 Region 的狀態。TiKV 集群會向 PD 匯報兩類消息：
每個 TiKV 節點會定期向 PD 匯報節點的整體信息
TiKV 節點（Store）與 PD 之間存在心跳包，一方面 PD 通過心跳包檢測每個 Store 是否存活，以及是否有新加入的 Store；另一方面，心跳包中也會攜帶這個 Store 的狀態信息，主要包括：
每個 Raft Group 的 Leader 會定期向 PD 匯報信息
每個 Raft Group 的 Leader 和 PD 之間存在心跳包，用于匯報這個 Region 的狀態，主要包括下面幾點信息：
PD 不斷的通過這兩類心跳消息收集整個集群的信息，再以這些信息作為決策的依據。除此之外，PD 還可以通過管理接口接受額外的信息，用來做更準確的決策。比如當某個 Store 的心跳包中斷的時候，PD 并不能判斷這個節點是臨時失效還是永久失效，只能經過一段時間的等待（默認是 30 分鐘），如果一直沒有心跳包，就認為是 Store 已經下線，再決定需要將這個 Store 上面的 Region 都調度走。但是有的時候，是運維人員主動將某臺機器下線，這個時候，可以通過 PD 的管理接口通知 PD 該 Store 不可用，PD 就可以馬上判斷需要將這個 Store 上面的 Region 都調度走。
PD 收集了這些信息后，還需要一些策略來制定具體的調度計劃。
一個 Region 的 Replica 數量正確
當 PD 通過某個 Region Leader 的心跳包發現這個 Region 的 Replica 數量不滿足要求時，需要通過 Add/Remove Replica 操作調整 Replica 數量。出現這種情況的可能原因是：
一個 Raft Group 中的多個 Replica 不在同一個位置
注意第二點，『一個 Raft Group 中的多個 Replica 不在同一個位置』，這里用的是『同一個位置』而不是『同一個節點』。在一般情況下，PD 只會保證多個 Replica 不落在一個節點上，以避免單個節點失效導致多個 Replica 丟失。在實際部署中，還可能出現下面這些需求：
這些需求本質上都是某一個節點具備共同的位置屬性，構成一個最小的容錯單元，我們希望這個單元內部不會存在一個 Region 的多個 Replica。這個時候，可以給節點配置 lables 并且通過在 PD 上配置 location-labels 來指明哪些 lable 是位置標識，需要在 Replica 分配的時候盡量保證不會有一個 Region 的多個 Replica 所在結點有相同的位置標識。
副本在 Store 之間的分布均勻分配
前面說過，每個副本中存儲的數據容量上限是固定的，所以我們維持每個節點上面，副本數量的均衡，會使得總體的負載更均衡。
Leader 數量在 Store 之間均勻分配
Raft 協議要讀取和寫入都通過 Leader 進行，所以計算的負載主要在 Leader 上面，PD 會盡可能將 Leader 在節點間分散開。
訪問熱點數量在 Store 之間均勻分配
每個 Store 以及 Region Leader 在上報信息時攜帶了當前訪問負載的信息，比如 Key 的讀取/寫入速度。PD 會檢測出訪問熱點，且將其在節點之間分散開。
各個 Store 的存儲空間占用大致相等
每個 Store 啟動的時候都會指定一個 Capacity 參數，表明這個 Store 的存儲空間上限，PD 在做調度的時候，會考慮節點的存儲空間剩余量。
控制調度速度，避免影響在線服務
調度操作需要耗費 CPU、內存、磁盤 IO 以及網絡帶寬，我們需要避免對線上服務造成太大影響。PD 會對當前正在進行的操作數量進行控制，默認的速度控制是比較保守的，如果希望加快調度(比如已經停服務升級，增加新節點，希望盡快調度)，那么可以通過 pd-ctl 手動加快調度速度。
支持手動下線節點
當通過 pd-ctl 手動下線節點后，PD 會在一定的速率控制下，將節點上的數據調度走。當調度完成后，就會將這個節點置為下線狀態。
了解了上面這些信息后，接下來我們看一下整個調度的流程。
PD 不斷的通過 Store 或者 Leader 的心跳包收集信息，獲得整個集群的詳細數據，并且根據這些信息以及調度策略生成調度操作序列，每次收到 Region Leader 發來的心跳包時，PD 都會檢查是否有對這個 Region 待進行的操作，通過心跳包的回復消息，將需要進行的操作返回給 Region Leader，并在后面的心跳包中監測執行結果。注意這里的操作只是給 Region Leader 的建議，并不保證一定能得到執行，具體是否會執行以及什么時候執行，由 Region Leader 自己根據當前自身狀態來定。
本篇文章講的東西，大家可能平時很少會在其他文章中看到，每一個設計都有背后的考量，希望大家能了解到一個分布式存儲系統在做調度的時候，需要考慮哪些東西，如何將策略、實現進行解耦，更靈活的支持策略的擴展。
至此三篇文章已經講完，希望大家能夠對整個 TiDB 的基本概念和實現原理有了解，后續我們還會寫更多的文章，從架構以及代碼級別介紹 TiDB 的更多內幕。如果大家有問題，歡迎發郵件到 shenli@pingcap.com 進行交流。
-----------------------------------End[Tony.Tang]2018.3.8------------------------------------------------------------
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
