任何一個複雜的系統，使用者感知到的都只是冰山一角，資料庫也不例外。

前兩篇文章介紹了 TiKV、TiDB 的基本概念以及一些核心功能的實現原理，這兩個元件一個負責 KV 儲存，一個負責 SQL 引擎，都是大家看得見的東西。在這兩個元件的後面，還有一個叫做 PD（Placement Driver）的元件，雖然不直接和業務接觸，但是這個元件是整個叢集的核心，負責全域性元資訊的儲存以及 TiKV 叢集負載均衡排程。

本篇文章介紹一下這個神祕的模組。這部分比較複雜，很多東西大家平時不會想到，也很少在其他文章中見到類似的東西的描述。我們還是按照前兩篇的思路，先講我們需要什麼樣的功能，再講我們如何實現，大家帶著需求去看實現，會更容易的理解我們做這些設計時背後的考量。

為什麼要進行排程

先回憶一下第一篇文章提到的一些資訊，TiKV 叢集是 TiDB 資料庫的分散式 KV 儲存引擎，資料以 Region 為單位進行復制和管理，每個 Region 會有多個 Replica（副本），這些 Replica 會分佈在不同的 TiKV 節點上，其中 Leader 負責讀/寫，Follower 負責同步 Leader 發來的 raft log。瞭解了這些資訊後，請思考下面這些問題：

• 如何保證同一個 Region 的多個 Replica 分佈在不同的節點上？更進一步，如果在一臺機器上啟動多個 TiKV 例項，會有什麼問題？
• TiKV 叢集進行跨機房部署用於容災的時候，如何保證一個機房掉線，不會丟失 Raft Group 的多個 Replica？
• 新增一個節點進入 TiKV 叢集之後，如何將叢集中其他節點上的資料搬過來?
• 當一個節點掉線時，會出現什麼問題？整個叢集需要做什麼事情？如果節點只是短暫掉線（重啟服務），那麼如何處理？如果節點是長時間掉線（磁碟故障，資料全部丟失），需要如何處理？
• 假設叢集需要每個 Raft Group 有 N 個副本，那麼對於單個 Raft Group 來說，Replica 數量可能會不夠多（例如節點掉線，失去副本），也可能會 過於多（例如掉線的節點又回覆正常，自動加入叢集）。那麼如何調節 Replica 個數？
• 讀/寫都是通過 Leader 進行，如果 Leader 只集中在少量節點上，會對叢集有什麼影響？
• 並不是所有的 Region 都被頻繁的訪問，可能訪問熱點只在少數幾個 Region，這個時候我們需要做什麼？
• 叢集在做負載均衡的時候，往往需要搬遷資料，這種資料的遷移會不會佔用大量的網路頻寬、磁碟 IO 以及 CPU？進而影響線上服務？

這些問題單獨拿出可能都能找到簡單的解決方案，但是混雜在一起，就不太好解決。有的問題貌似只需要考慮單個 Raft Group 內部的情況，比如根據副本數量是否足夠多來決定是否需要新增副本。但是實際上這個副本新增在哪裡，是需要考慮全域性的資訊。整個系統也是在動態變化，Region 分裂、節點加入、節點失效、訪問熱點變化等情況會不斷髮生，整個排程系統也需要在動態中不斷向最優狀態前進，如果沒有一個掌握全域性資訊，可以對全域性進行排程，並且可以配置的元件，就很難滿足這些需求。因此我們需要一箇中心節點，來對系統的整體狀況進行把控和調整，所以有了 PD 這個模組。

排程的需求

上面羅列了一大堆問題，我們先進行分類和整理。總體來看，問題有兩大類：

作為一個分散式高可用儲存系統，必須滿足的需求，包括四種：

• 副本數量不能多也不能少
• 副本需要分佈在不同的機器上
• 新加節點後，可以將其他節點上的副本遷移過來
• 節點下線後，需要將該節點的資料遷移走

作為一個良好的分散式系統，需要優化的地方，包括：

• 維持整個叢集的 Leader 分佈均勻
• 維持每個節點的儲存容量均勻
• 維持訪問熱點分佈均勻
• 控制 Balance 的速度，避免影響線上服務
• 管理節點狀態，包括手動上線/下線節點，以及自動下線失效節點

滿足第一類需求後，整個系統將具備多副本容錯、動態擴容/縮容、容忍節點掉線以及自動錯誤恢復的功能。滿足第二類需求後，可以使得整體系統的負載更加均勻、且可以方便的管理。

為了滿足這些需求，首先我們需要收集足夠的資訊，比如每個節點的狀態、每個 Raft Group 的資訊、業務訪問操作的統計等；其次需要設定一些策略，PD 根據這些資訊以及排程的策略，制定出儘量滿足前面所述需求的排程計劃；最後需要一些基本的操作，來完成排程計劃。 排程的基本操作

我們先來介紹最簡單的一點，也就是排程的基本操作，也就是為了滿足排程的策略，我們有哪些功能可以用。這是整個排程的基礎，瞭解了手裡有什麼樣的錘子，才知道用什麼樣的姿勢去砸釘子。

上述排程需求看似複雜，但是整理下來最終落地的無非是下面三件事：

• 增加一個 Replica
• 刪除一個 Replica
• 將 Leader 角色在一個 Raft Group 的不同 Replica 之間 transfer

剛好 Raft 協議能夠滿足這三種需求，通過 AddReplica、RemoveReplica、TransferLeader 這三個命令，可以支撐上述三種基本操作。

資訊收集

排程依賴於整個叢集資訊的收集，簡單來說，我們需要知道每個 TiKV 節點的狀態以及每個 Region 的狀態。TiKV 叢集會向 PD 彙報兩類訊息：

每個 TiKV 節點會定期向 PD 彙報節點的整體資訊

TiKV 節點（Store）與 PD 之間存在心跳包，一方面 PD 通過心跳包檢測每個 Store 是否存活，以及是否有新加入的 Store；另一方面，心跳包中也會攜帶這個 [Store 的狀態資訊][1]，主要包括：

• 總磁碟容量
• 可用磁碟容量
• 承載的 Region 數量
• 資料寫入速度
• 傳送/接受的 Snapshot 數量（Replica 之間可能會通過 Snapshot 同步資料）
• 是否過載
• 標籤資訊（標籤是具備層級關係的一系列 Tag）

每個 Raft Group 的 Leader 會定期向 PD 彙報資訊

每個 Raft Group 的 Leader 和 PD 之間存在心跳包，用於彙報這個 [Region][2] 的狀態，主要包括下面幾點資訊：

• Leader 的位置
• Followers 的位置
• 掉線 Replica 的個數
• 資料寫入/讀取的速度

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 數量。出現這種情況的可能原因是：

• 某個節點掉線，上面的資料全部丟失，導致一些 Region 的 Replica 數量不足
• 某個掉線節點又恢復服務，自動接入叢集，這樣之前已經補足了 Replica 的 Region 的 Replica 數量多過，需要刪除某個 Replica
• 管理員調整了副本策略，修改了 [max-replicas][3] 的配置

一個 Raft Group 中的多個 Replica 不在同一個位置

注意第二點，『一個 Raft Group 中的多個 Replica 不在同一個位置』，這裡用的是『同一個位置』而不是『同一個節點』。在一般情況下，PD 只會保證多個 Replica 不落在一個節點上，以避免單個節點失效導致多個 Replica 丟失。在實際部署中，還可能出現下面這些需求：

• 多個節點部署在同一臺物理機器上
• TiKV 節點分佈在多個機架上，希望單個機架掉電時，也能保證系統可用性
• TiKV 節點分佈在多個 IDC 中，向單個機房掉電時，也能保證系統可用

這些需求本質上都是某一個節點具備共同的位置屬性，構成一個最小的容錯單元，我們希望這個單元內部不會存在一個 Region 的多個 Replica。這個時候，可以給節點配置 [lables][4] 並且通過在 PD 上配置 [location-labels][5] 來指名哪些 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 進行交流。（文／申礫）