首頁技術(shù)文章正文

TiDB為什么要進(jìn)行調(diào)度?TiDB調(diào)度全流程

更新時(shí)間:2021-11-24 來源:黑馬程序員 瀏覽量:

IT培訓(xùn)班

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

? 如何保證同一個(gè) Region 的多個(gè) Replica 分布在不同的節(jié)點(diǎn)上?更進(jìn)一步,如果在一臺(tái)機(jī)器上啟動(dòng)多個(gè) TiKV 實(shí)例,會(huì)有什么問題?

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

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

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

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

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

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

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

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

調(diào)度的需求

上面羅列了一大堆問題,我們先進(jìn)行分類和整理??傮w來看,問題有兩大類:

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

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

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

? 新加節(jié)點(diǎn)后,可以將其他節(jié)點(diǎn)上的副本遷移過來

? 節(jié)點(diǎn)下線后,需要將該節(jié)點(diǎn)的數(shù)據(jù)遷移走

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

? 維持整個(gè)集群的 Leader 分布均勻

? 維持每個(gè)節(jié)點(diǎn)的儲(chǔ)存容量均勻

? 維持訪問熱點(diǎn)分布均勻

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

? 管理節(jié)點(diǎn)狀態(tài),包括手動(dòng)上線/下線節(jié)點(diǎn),以及自動(dòng)下線失效節(jié)點(diǎn)

滿足第一類需求后,整個(gè)系統(tǒng)將具備多副本容錯(cuò)、動(dòng)態(tài)擴(kuò)容/縮容、容忍節(jié)點(diǎn)掉線以及自動(dòng)錯(cuò)誤恢復(fù)的功能。

滿足第二類需求后,可以使得整體系統(tǒng)的負(fù)載更加均勻、且可以方便的管理。

為了滿足這些需求,首先我們需要收集足夠的信息,比如每個(gè)節(jié)點(diǎn)的狀態(tài)、每個(gè) Raft Group 的信息、業(yè)務(wù)訪問操作的統(tǒng)計(jì)等;

其次需要設(shè)置一些策略,PD 根據(jù)這些信息以及調(diào)度的策略,制定出盡量滿足前面所述需求的調(diào)度計(jì)劃;最后需要一些基本的操作,來完成調(diào)度計(jì)劃。

調(diào)度的基本操作

為了滿足調(diào)度的策略,我們有哪些功能可以用。這是整個(gè)調(diào)度的基礎(chǔ),了解了手里有什么樣的錘子,才知道用什么樣的姿勢去砸釘子。

上述調(diào)度需求看似復(fù)雜,但是整理下來最終落地的無非是下面三件事:

? 增加一個(gè) Replica

? 刪除一個(gè) Replica

? 將 Leader 角色在一個(gè) Raft Group 的不同 Replica 之間 transfer

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


信息收集

調(diào)度依賴于整個(gè)集群信息的收集,簡單來說,我們需要知道每個(gè) TiKV 節(jié)點(diǎn)的狀態(tài)以及每個(gè) Region 的狀態(tài)。TiKV 集群會(huì)向 PD 匯報(bào)兩類消息:

每個(gè) TiKV 節(jié)點(diǎn)會(huì)定期向 PD 匯報(bào)節(jié)點(diǎn)的整體信息

TiKV 節(jié)點(diǎn)(Store)與 PD 之間存在心跳包,一方面 PD 通過心跳包檢測每個(gè) Store 是否存活,以及是否有新加入的 Store;另一方面,心跳包中也會(huì)攜帶這個(gè) Store 的狀態(tài)信息,主要包括:

? 總磁盤容量

? 可用磁盤容量

? 承載的 Region 數(shù)量

? 數(shù)據(jù)寫入速度

? 發(fā)送/接受的 Snapshot 數(shù)量(Replica 之間可能會(huì)通過 Snapshot 同步數(shù)據(jù))

? 是否過載

? 標(biāo)簽信息(標(biāo)簽是具備層級(jí)關(guān)系的一系列 Tag)

每個(gè) Raft Group 的 Leader 會(huì)定期向 PD 匯報(bào)信息

每個(gè) Raft Group 的 Leader 和 PD 之間存在心跳包,用于匯報(bào)這個(gè) Region 的狀態(tài),主要包括下面幾點(diǎn)信息:

? Leader 的位置

? Followers 的位置

? 掉線 Replica 的個(gè)數(shù)

? 數(shù)據(jù)寫入/讀取的速度

PD 不斷的通過這兩類心跳消息收集整個(gè)集群的信息,再以這些信息作為決策的依據(jù)。除此之外,PD 還可以通過管理接口接受額外的信息,用來做更準(zhǔn)確的決策。比如當(dāng)某個(gè) Store 的心跳包中斷的時(shí)候,PD 并不能判斷這個(gè)節(jié)點(diǎn)是臨時(shí)失效還是永久失效,只能經(jīng)過一段時(shí)間的等待(默認(rèn)是 30 分鐘),如果一直沒有心跳包,就認(rèn)為是 Store 已經(jīng)下線,再?zèng)Q定需要將這個(gè) Store 上面的 Region 都調(diào)度走。但是有的時(shí)候,是運(yùn)維人員主動(dòng)將某臺(tái)機(jī)器下線,這個(gè)時(shí)候,可以通過 PD 的管理接口通知 PD 該 Store 不可用,PD 就可以馬上判斷需要將這個(gè) Store 上面的 Region 都調(diào)度走。

調(diào)度的策略

PD 收集了這些信息后,還需要一些策略來制定具體的調(diào)度計(jì)劃。

1.一個(gè) Region 的 Replica 數(shù)量正確

當(dāng) PD 通過某個(gè) Region Leader 的心跳包發(fā)現(xiàn)這個(gè) Region 的 Replica 數(shù)量不滿足要求時(shí),需要通過 Add/Remove Replica 操作調(diào)整 Replica 數(shù)量。出現(xiàn)這種情況的可能原因是:

? 某個(gè)節(jié)點(diǎn)掉線,上面的數(shù)據(jù)全部丟失,導(dǎo)致一些 Region 的 Replica 數(shù)量不足

? 某個(gè)掉線節(jié)點(diǎn)又恢復(fù)服務(wù),自動(dòng)接入集群,這樣之前已經(jīng)補(bǔ)足了 Replica 的 Region 的 Replica 數(shù)量多過,需要?jiǎng)h除某個(gè) Replica

? 管理員調(diào)整了副本策略,修改了 max-replicas 的配置

2.一個(gè) Raft Group 中的多個(gè) Replica 不在同一個(gè)位置

注意第二點(diǎn),『一個(gè) Raft Group 中的多個(gè) Replica 不在同一個(gè)位置』,這里用的是『同一個(gè)位置』而不是『同一個(gè)節(jié)點(diǎn)』。在一般情況下,PD 只會(huì)保證多個(gè) Replica 不落在一個(gè)節(jié)點(diǎn)上,以避免單個(gè)節(jié)點(diǎn)失效導(dǎo)致多個(gè) Replica 丟失。在實(shí)際部署中,還可能出現(xiàn)下面這些需求:

? 多個(gè)節(jié)點(diǎn)部署在同一臺(tái)物理機(jī)器上

? TiKV 節(jié)點(diǎn)分布在多個(gè)機(jī)架上,希望單個(gè)機(jī)架掉電時(shí),也能保證系統(tǒng)可用性

? TiKV 節(jié)點(diǎn)分布在多個(gè) IDC 中,希望單個(gè)機(jī)房掉電時(shí),也能保證系統(tǒng)可用

這些需求本質(zhì)上都是某一個(gè)節(jié)點(diǎn)具備共同的位置屬性,構(gòu)成一個(gè)最小的容錯(cuò)單元,我們希望這個(gè)單元內(nèi)部不會(huì)存在一個(gè) Region 的多個(gè) Replica。這個(gè)時(shí)候,可以給節(jié)點(diǎn)配置 lables 并且通過在 PD 上配置 location-labels 來指明哪些 lable 是位置標(biāo)識(shí),需要在 Replica 分配的時(shí)候盡量保證不會(huì)有一個(gè) Region 的多個(gè) Replica 所在結(jié)點(diǎn)有相同的位置標(biāo)識(shí)。

3.副本在 Store 之間的分布均勻分配

前面說過,每個(gè)副本中存儲(chǔ)的數(shù)據(jù)容量上限是固定的,所以我們維持每個(gè)節(jié)點(diǎn)上面,副本數(shù)量的均衡,會(huì)使得總體的負(fù)載更均衡。

4.Leader 數(shù)量在 Store 之間均勻分配

Raft 協(xié)議要讀取和寫入都通過 Leader 進(jìn)行,所以計(jì)算的負(fù)載主要在 Leader 上面,PD 會(huì)盡可能將 Leader 在節(jié)點(diǎn)間分散開。

5.訪問熱點(diǎn)數(shù)量在 Store 之間均勻分配

每個(gè) Store 以及 Region Leader 在上報(bào)信息時(shí)攜帶了當(dāng)前訪問負(fù)載的信息,比如 Key 的讀取/寫入速度。PD 會(huì)檢測出訪問熱點(diǎn),且將其在節(jié)點(diǎn)之間分散開。

6.各個(gè) Store 的存儲(chǔ)空間占用大致相等

每個(gè) Store 啟動(dòng)的時(shí)候都會(huì)指定一個(gè) Capacity 參數(shù),表明這個(gè) Store 的存儲(chǔ)空間上限,PD 在做調(diào)度的時(shí)候,會(huì)考慮節(jié)點(diǎn)的存儲(chǔ)空間剩余量。

7.控制調(diào)度速度,避免影響在線服務(wù)

調(diào)度操作需要耗費(fèi) CPU、內(nèi)存、磁盤 IO 以及網(wǎng)絡(luò)帶寬,我們需要避免對(duì)線上服務(wù)造成太大影響。PD 會(huì)對(duì)當(dāng)前正在進(jìn)行的操作數(shù)量進(jìn)行控制,默認(rèn)的速度控制是比較保守的,如果希望加快調(diào)度(比如已經(jīng)停服務(wù)升級(jí),增加新節(jié)點(diǎn),希望盡快調(diào)度),那么可以通過 pd-ctl 手動(dòng)加快調(diào)度速度。

8.支持手動(dòng)下線節(jié)點(diǎn)

當(dāng)通過 pd-ctl 手動(dòng)下線節(jié)點(diǎn)后,PD 會(huì)在一定的速率控制下,將節(jié)點(diǎn)上的數(shù)據(jù)調(diào)度走。當(dāng)調(diào)度完成后,就會(huì)將這個(gè)節(jié)點(diǎn)置為下線狀態(tài)。


實(shí)現(xiàn)調(diào)度

接下來我們看一下整個(gè)調(diào)度的流程。

PD 不斷的通過 Store 或者 Leader 的心跳包收集信息,獲得整個(gè)集群的詳細(xì)數(shù)據(jù),并且根據(jù)這些信息以及調(diào)度策略生成調(diào)度操作序列,每次收到 Region Leader 發(fā)來的心跳包時(shí),PD 都會(huì)檢查是否有對(duì)這個(gè) Region 待進(jìn)行的操作,通過心跳包的回復(fù)消息,將需要進(jìn)行的操作返回給 Region Leader,并在后面的心跳包中監(jiān)測執(zhí)行結(jié)果。注意這里的操作只是給 Region Leader 的建議,并不保證一定能得到執(zhí)行,具體是否會(huì)執(zhí)行以及什么時(shí)候執(zhí)行,由 Region Leader 自己根據(jù)當(dāng)前自身狀態(tài)來定。






猜你喜歡:

TiDB的核心特性有哪些?

Kafka基準(zhǔn)測試的測試步驟有哪些?

使用MySQL數(shù)據(jù)庫,實(shí)現(xiàn)你的第一個(gè)JDBC程序

數(shù)據(jù)庫索引是什么意思?

黑馬程序員Python+大數(shù)據(jù)開發(fā)培訓(xùn)

分享到:
在線咨詢 我要報(bào)名
和我們?cè)诰€交談!