更新時(shí)間:2021-11-24 來源:黑馬程序員 瀏覽量:
TiKV 集群是 TiDB 數(shù)據(jù)庫的分布式 KV 存儲引擎,數(shù)據(jù)以 Region 為單位進(jìn)行復(fù)制和管理,每個(gè) Region 會有多個(gè)
Replica(副本),這些 Replica 會分布在不同的 TiKV 節(jié)點(diǎn)上,其中 Leader 負(fù)責(zé)讀/寫,F(xiàn)ollower 負(fù)責(zé)同步 Leader 發(fā)來的
raft log。了解了這些信息后,請思考下面這些問題:
? 如何保證同一個(gè) Region 的多個(gè) Replica 分布在不同的節(jié)點(diǎn)上?更進(jìn)一步,如果在一臺機(jī)器上啟動多個(gè) TiKV 實(shí)例,會有什么問題?
? TiKV 集群進(jìn)行跨機(jī)房部署用于容災(zāi)的時(shí)候,如何保證一個(gè)機(jī)房掉線,不會丟失 Raft Group 的多個(gè) Replica?
? 添加一個(gè)節(jié)點(diǎn)進(jìn)入 TiKV 集群之后,如何將集群中其他節(jié)點(diǎn)上的數(shù)據(jù)搬過來?
? 當(dāng)一個(gè)節(jié)點(diǎn)掉線時(shí),會出現(xiàn)什么問題?整個(gè)集群需要做什么事情?如果節(jié)點(diǎn)只是短暫掉線(重啟服務(wù)),那么如何處理?如果節(jié)點(diǎn)是長時(shí)間掉線(磁盤故障,數(shù)據(jù)全部丟失),需要如何處理?
? 假設(shè)集群需要每個(gè) Raft Group 有 N 個(gè)副本,那么對于單個(gè) Raft Group 來說,Replica 數(shù)量可能會不夠多(例如節(jié)點(diǎn)掉線,失去副本),也可能會過于多(例如掉線的節(jié)點(diǎn)又回復(fù)正常,自動加入集群)。那么如何調(diào)節(jié) Replica 個(gè)數(shù)?
? 讀/寫都是通過 Leader 進(jìn)行,如果 Leader 只集中在少量節(jié)點(diǎn)上,會對集群有什么影響?
? 并不是所有的 Region 都被頻繁的訪問,可能訪問熱點(diǎn)只在少數(shù)幾個(gè) Region,這個(gè)時(shí)候我們需要做什么?
? 集群在做負(fù)載均衡的時(shí)候,往往需要搬遷數(shù)據(jù),這種數(shù)據(jù)的遷移會不會占用大量的網(wǎng)絡(luò)帶寬、磁盤 IO 以及 CPU?進(jìn)而影響在線服務(wù)?
這些問題單獨(dú)拿出可能都能找到簡單的解決方案,但是混雜在一起,就不太好解決。有的問題貌似只需要考慮單個(gè) Raft Group 內(nèi)部的情況,比如根據(jù)副本數(shù)量是否足夠多來決定是否需要添加副本。但是實(shí)際上這個(gè)副本添加在哪里,是需要考慮全局的信息。整個(gè)系統(tǒng)也是在動態(tài)變化,Region 分裂、節(jié)點(diǎn)加入、節(jié)點(diǎn)失效、訪問熱點(diǎn)變化等情況會不斷發(fā)生,整個(gè)調(diào)度系統(tǒng)也需要在動態(tài)中不斷向最優(yōu)狀態(tài)前進(jìn),如果沒有一個(gè)掌握全局信息,可以對全局進(jìn)行調(diào)度,并且可以配置的組件,就很難滿足這些需求。因此我們需要一個(gè)中心節(jié)點(diǎn),來對系統(tǒng)的整體狀況進(jìn)行把控和調(diào)整,所以有了 PD 這個(gè)模塊。
調(diào)度的需求
上面羅列了一大堆問題,我們先進(jìn)行分類和整理。總體來看,問題有兩大類:
1.作為一個(gè)分布式高可用存儲系統(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)的儲存容量均勻
? 維持訪問熱點(diǎn)分布均勻
? 控制 Balance 的速度,避免影響在線服務(wù)
? 管理節(jié)點(diǎn)狀態(tài),包括手動上線/下線節(jié)點(diǎn),以及自動下線失效節(jié)點(diǎn)
滿足第一類需求后,整個(gè)系統(tǒng)將具備多副本容錯(cuò)、動態(tài)擴(kuò)容/縮容、容忍節(jié)點(diǎn)掉線以及自動錯(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 集群會向 PD 匯報(bào)兩類消息:
每個(gè) TiKV 節(jié)點(diǎn)會定期向 PD 匯報(bào)節(jié)點(diǎn)的整體信息
TiKV 節(jié)點(diǎn)(Store)與 PD 之間存在心跳包,一方面 PD 通過心跳包檢測每個(gè) Store 是否存活,以及是否有新加入的 Store;另一方面,心跳包中也會攜帶這個(gè) Store 的狀態(tài)信息,主要包括:
? 總磁盤容量
? 可用磁盤容量
? 承載的 Region 數(shù)量
? 數(shù)據(jù)寫入速度
? 發(fā)送/接受的 Snapshot 數(shù)量(Replica 之間可能會通過 Snapshot 同步數(shù)據(jù))
? 是否過載
? 標(biāo)簽信息(標(biāo)簽是具備層級關(guān)系的一系列 Tag)
每個(gè) Raft Group 的 Leader 會定期向 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)下線,再決定需要將這個(gè)
Store 上面的 Region 都調(diào)度走。但是有的時(shí)候,是運(yùn)維人員主動將某臺機(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ù),自動接入集群,這樣之前已經(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 只會保證多個(gè) Replica 不落在一個(gè)節(jié)點(diǎn)上,以避免單個(gè)節(jié)點(diǎn)失效導(dǎo)致多個(gè) Replica 丟失。在實(shí)際部署中,還可能出現(xiàn)下面這些需求:
? 多個(gè)節(jié)點(diǎn)部署在同一臺物理機(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)部不會存在一個(gè) Region 的多個(gè) Replica。這個(gè)時(shí)候,可以給節(jié)點(diǎn)配置 lables 并且通過在 PD 上配置 location-labels 來指明哪些 lable 是位置標(biāo)識,需要在 Replica 分配的時(shí)候盡量保證不會有一個(gè) Region 的多個(gè) Replica 所在結(jié)點(diǎn)有相同的位置標(biāo)識。
3.副本在 Store 之間的分布均勻分配
前面說過,每個(gè)副本中存儲的數(shù)據(jù)容量上限是固定的,所以我們維持每個(gè)節(jié)點(diǎn)上面,副本數(shù)量的均衡,會使得總體的負(fù)載更均衡。
4.Leader 數(shù)量在 Store 之間均勻分配
Raft 協(xié)議要讀取和寫入都通過 Leader 進(jìn)行,所以計(jì)算的負(fù)載主要在 Leader 上面,PD 會盡可能將 Leader 在節(jié)點(diǎn)間分散開。
5.訪問熱點(diǎn)數(shù)量在 Store 之間均勻分配
每個(gè) Store 以及 Region Leader 在上報(bào)信息時(shí)攜帶了當(dāng)前訪問負(fù)載的信息,比如 Key 的讀取/寫入速度。PD 會檢測出訪問熱點(diǎn),且將其在節(jié)點(diǎn)之間分散開。
6.各個(gè) Store 的存儲空間占用大致相等
每個(gè) Store 啟動的時(shí)候都會指定一個(gè) Capacity 參數(shù),表明這個(gè) Store 的存儲空間上限,PD 在做調(diào)度的時(shí)候,會考慮節(jié)點(diǎn)的存儲空間剩余量。
7.控制調(diào)度速度,避免影響在線服務(wù)
調(diào)度操作需要耗費(fèi) CPU、內(nèi)存、磁盤 IO 以及網(wǎng)絡(luò)帶寬,我們需要避免對線上服務(wù)造成太大影響。PD 會對當(dāng)前正在進(jìn)行的操作數(shù)量進(jìn)行控制,默認(rèn)的速度控制是比較保守的,如果希望加快調(diào)度(比如已經(jīng)停服務(wù)升級,增加新節(jié)點(diǎn),希望盡快調(diào)度),那么可以通過 pd-ctl 手動加快調(diào)度速度。
8.支持手動下線節(jié)點(diǎn)
當(dāng)通過 pd-ctl 手動下線節(jié)點(diǎn)后,PD 會在一定的速率控制下,將節(jié)點(diǎn)上的數(shù)據(jù)調(diào)度走。當(dāng)調(diào)度完成后,就會將這個(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 都會檢查是否有對這個(gè) Region 待進(jìn)行的操作,通過心跳包的回復(fù)消息,將需要進(jìn)行的操作返回給 Region Leader,并在后面的心跳包中監(jiān)測執(zhí)行結(jié)果。注意這里的操作只是給 Region Leader 的建議,并不保證一定能得到執(zhí)行,具體是否會執(zhí)行以及什么時(shí)候執(zhí)行,由 Region Leader 自己根據(jù)當(dāng)前自身狀態(tài)來定。