TiDB為什么要需要調(diào)度？調(diào)度的基本需求是什么？

更新時間:2021年10月21日16時53分來源:傳智教育瀏覽次數(shù):

　　TiKV 集群是 TiDB 數(shù)據(jù)庫的分布式 KV 存儲引擎，數(shù)據(jù)以 Region 為單位進(jìn)行復(fù)制和管理，每個 Region 會有多個 Replica(副本)，這些 Replica 會分布在不同的 TiKV 節(jié)點上，其中 Leader 負(fù)責(zé)讀/寫，F(xiàn)ollower 負(fù)責(zé)同步 Leader 發(fā)來的 raft log。了解了這些信息后，請思考下面這些問題：

　　• 如何保證同一個 Region 的多個 Replica 分布在不同的節(jié)點上?更進(jìn)一步，如果在一臺機(jī)器上啟動多個 TiKV 實例，會有什么問題?

　　• TiKV 集群進(jìn)行跨機(jī)房部署用于容災(zāi)的時候，如何保證一個機(jī)房掉線，不會丟失 Raft Group 的多個 Replica?

　　• 添加一個節(jié)點進(jìn)入 TiKV 集群之后，如何將集群中其他節(jié)點上的數(shù)據(jù)搬過來?

　　• 當(dāng)一個節(jié)點掉線時，會出現(xiàn)什么問題?整個集群需要做什么事情?如果節(jié)點只是短暫掉線(重啟服務(wù))，那么如何處理?如果節(jié)點是長時間掉線(磁盤故障，數(shù)據(jù)全部丟失)，需要如何處理?

　　• 假設(shè)集群需要每個 Raft Group 有 N 個副本，那么對于單個 Raft Group 來說，Replica 數(shù)量可能會不夠多(例如節(jié)點掉線，失去副本)，也可能會過于多(例如掉線的節(jié)點又回復(fù)正常，自動加入集群)。那么如何調(diào)節(jié) Replica 個數(shù)?

　　• 讀/寫都是通過 Leader 進(jìn)行，如果 Leader 只集中在少量節(jié)點上，會對集群有什么影響?

　　• 并不是所有的 Region 都被頻繁的訪問，可能訪問熱點只在少數(shù)幾個 Region，這個時候我們需要做什么?

　　• 集群在做負(fù)載均衡的時候，往往需要搬遷數(shù)據(jù)，這種數(shù)據(jù)的遷移會不會占用大量的網(wǎng)絡(luò)帶寬、磁盤 IO 以及 CPU?進(jìn)而影響在線服務(wù)?

　　這些問題單獨拿出可能都能找到簡單的解決方案，但是混雜在一起，就不太好解決。有的問題貌似只需要考慮單個 Raft Group 內(nèi)部的情況，比如根據(jù)副本數(shù)量是否足夠多來決定是否需要添加副本。但是實際上這個副本添加在哪里，是需要考慮全局的信息。整個系統(tǒng)也是在動態(tài)變化，Region 分裂、節(jié)點加入、節(jié)點失效、訪問熱點變化等情況會不斷發(fā)生，整個調(diào)度系統(tǒng)也需要在動態(tài)中不斷向最優(yōu)狀態(tài)前進(jìn)，如果沒有一個掌握全局信息，可以對全局進(jìn)行調(diào)度，并且可以配置的組件，就很難滿足這些需求。因此我們需要一個中心節(jié)點，來對系統(tǒng)的整體狀況進(jìn)行把控和調(diào)整，所以有了 PD 這個模塊。

　　調(diào)度的基本需求：

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

　　1.作為一個分布式高可用存儲系統(tǒng)，必須滿足的需求，包括四種：

　　• 副本數(shù)量不能多也不能少

　　• 副本需要分布在不同的機(jī)器上

　　• 新加節(jié)點后，可以將其他節(jié)點上的副本遷移過來

　　• 節(jié)點下線后，需要將該節(jié)點的數(shù)據(jù)遷移走

　　2.作為一個良好的分布式系統(tǒng)，需要優(yōu)化的地方，包括：

　　• 維持整個集群的 Leader 分布均勻

　　• 維持每個節(jié)點的儲存容量均勻

　　• 維持訪問熱點分布均勻

　　• 控制 Balance 的速度，避免影響在線服務(wù)