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

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)