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

TiKV 集群是 TiDB 數(shù)據(jù)庫(kù)的分布式 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ā)來(lái)的 raft log。了解了這些信息后，請(qǐng)思考下面這些問(wèn)題：

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

? 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ù)搬過(guò)來(lái)?

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

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

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

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

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

這些問(wèn)題單獨(dú)拿出可能都能找到簡(jiǎn)單的解決方案，但是混雜在一起，就不太好解決。有的問(wèn)題貌似只需要考慮單個(gè) Raft Group 內(nèi)部的情況，比如根據(jù)副本數(shù)量是否足夠多來(lái)決定是否需要添加副本。但是實(shí)際上這個(gè)副本添加在哪里，是需要考慮全局的信息。整個(gè)系統(tǒng)也是在動(dòng)態(tài)變化，Region 分裂、節(jié)點(diǎn)加入、節(jié)點(diǎn)失效、訪問(wè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)，來(lái)對(duì)系統(tǒng)的整體狀況進(jìn)行把控和調(diào)整，所以有了 PD 這個(gè)模塊。

調(diào)度的需求

上面羅列了一大堆問(wèn)題，我們先進(jìn)行分類和整理?？傮w來(lái)看，問(wèn)題有兩大類：

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

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

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

? 新加節(jié)點(diǎn)后，可以將其他節(jié)點(diǎn)上的副本遷移過(guò)來(lái)

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

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

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

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

? 維持訪問(wèn)熱點(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ù)訪問(wèn)操作的統(tǒng)計(jì)等;

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

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

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

上述調(diào)度需求看似復(fù)雜，但是整理下來(lái)最終落地的無(wú)非是下面三件事：

? 增加一個(gè) Replica

? 刪除一個(gè) Replica

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

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

信息收集

調(diào)度依賴于整個(gè)集群信息的收集，簡(jiǎn)單來(lái)說(shuō)，我們需要知道每個(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 通過(guò)心跳包檢測(cè)每個(gè) Store 是否存活，以及是否有新加入的 Store;另一方面，心跳包中也會(huì)攜帶這個(gè) Store 的狀態(tài)信息，主要包括：

? 總磁盤容量

? 可用磁盤容量

? 承載的 Region 數(shù)量

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

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

? 是否過(guò)載

? 標(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 不斷的通過(guò)這兩類心跳消息收集整個(gè)集群的信息，再以這些信息作為決策的依據(jù)。除此之外，PD 還可以通過(guò)管理接口接受額外的信息，用來(lái)做更準(zhǔn)確的決策。比如當(dāng)某個(gè) Store 的心跳包中斷的時(shí)候，PD 并不能判斷這個(gè)節(jié)點(diǎn)是臨時(shí)失效還是永久失效，只能經(jīng)過(guò)一段時(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í)候，可以通過(guò) PD 的管理接口通知 PD 該 Store 不可用，PD 就可以馬上判斷需要將這個(gè) Store 上面的 Region 都調(diào)度走。

調(diào)度的策略

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

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

當(dāng) PD 通過(guò)某個(gè) Region Leader 的心跳包發(fā)現(xiàn)這個(gè) Region 的 Replica 數(shù)量不滿足要求時(shí)，需要通過(guò) 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ù)量多過(guò)，需要?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 并且通過(guò)在 PD 上配置 location-labels 來(lái)指明哪些 lable 是位置標(biāo)識(shí)，需要在 Replica 分配的時(shí)候盡量保證不會(huì)有一個(gè) Region 的多個(gè) Replica 所在結(jié)點(diǎn)有相同的位置標(biāo)識(shí)。

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

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

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

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

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

每個(gè) Store 以及 Region Leader 在上報(bào)信息時(shí)攜帶了當(dāng)前訪問(wèn)負(fù)載的信息，比如 Key 的讀取/寫入速度。PD 會(huì)檢測(cè)出訪問(wèn)熱點(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)度)，那么可以通過(guò) pd-ctl 手動(dòng)加快調(diào)度速度。

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

當(dāng)通過(guò) 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)度

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

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

TiDB的核心特性有哪些？

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

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

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

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