分布式架構(gòu)下，傳統(tǒng)數(shù)據(jù)庫(kù)運(yùn)維究竟要面對(duì)哪些變化？

作者：孔再華 2020-03-23 07:30:57

運(yùn)維

數(shù)據(jù)庫(kù)運(yùn)維

分布式 分布式架構(gòu)可能是近幾年最火的話(huà)題。從集中式、SOA到分布式架構(gòu)，本文回顧了這些年金融行業(yè)經(jīng)歷的架構(gòu)演變;結(jié)合當(dāng)下一些較典型的分布式數(shù)據(jù)庫(kù)的實(shí)現(xiàn)原理，分析了分布式數(shù)據(jù)庫(kù)的三個(gè)發(fā)展階段。

創(chuàng)新互聯(lián)建站主要從事成都做網(wǎng)站、網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)鼎城,10年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專(zhuān)業(yè),歡迎來(lái)電咨詢(xún)建站服務(wù):18980820575

分布式架構(gòu)可能是近幾年最火的話(huà)題。從集中式、SOA到分布式架構(gòu)，本文回顧了這些年金融行業(yè)經(jīng)歷的架構(gòu)演變;結(jié)合當(dāng)下一些較典型的分布式數(shù)據(jù)庫(kù)的實(shí)現(xiàn)原理，分析了分布式數(shù)據(jù)庫(kù)的三個(gè)發(fā)展階段。分布式數(shù)據(jù)庫(kù)的應(yīng)用解決了傳統(tǒng)數(shù)據(jù)庫(kù)性能擴(kuò)展問(wèn)題的同時(shí)，也給運(yùn)維人員帶來(lái)了挑戰(zhàn)。那么，分布式數(shù)據(jù)庫(kù)的管理究竟多了些什么?如何管理好?未來(lái)數(shù)據(jù)庫(kù)和數(shù)據(jù)庫(kù)運(yùn)維又將去往何方?讀過(guò)本文，你可以找到答案。

一、金融行業(yè)這些年經(jīng)歷了怎樣的架構(gòu)演變?

1. 集中式架構(gòu)

分布式架構(gòu)可能是近幾年最火的話(huà)題，與之相對(duì)的則是集中式架構(gòu)，后者是傳統(tǒng)金融行業(yè)如銀行最常見(jiàn)的部署架構(gòu)。在“去IOE”之前，各大銀行的目標(biāo)還停留在將集中式單點(diǎn)做強(qiáng)做大，不少銀行采用IBM的主機(jī)系統(tǒng)就是鮮明的例子。數(shù)據(jù)庫(kù)服務(wù)器更是如此，通常都是采用最好的機(jī)器。

近幾年，隨著銀行業(yè)務(wù)增長(zhǎng)，互聯(lián)網(wǎng)行業(yè)爆發(fā)，用戶(hù)行為模式發(fā)生變化，集中式架構(gòu)的系統(tǒng)面臨很大的挑戰(zhàn)。問(wèn)題主要體現(xiàn)在擴(kuò)展性和可用性這兩方面：

1. 擴(kuò)展性

集中式架構(gòu)的橫向水平擴(kuò)展能力非常低。面對(duì)性能不足，用戶(hù)能做的就是加CPU、加內(nèi)存、換存儲(chǔ)、換機(jī)器等方式。

2. 可用性

集中式架構(gòu)的服務(wù)能力依賴(lài)高性能的主機(jī)。然而一旦主機(jī)出現(xiàn)故障，上面的服務(wù)就會(huì)受到影響。應(yīng)對(duì)這個(gè)問(wèn)題的方案就是搭建高可用架構(gòu)。每一個(gè)環(huán)節(jié)都需要考慮冗余和HA。集中式架構(gòu)下這幾乎是最好的方式了。然而無(wú)論哪個(gè)環(huán)節(jié)出故障，影響的都是全局服務(wù)。

這種架構(gòu)下的數(shù)據(jù)庫(kù)也是通過(guò)做主備機(jī)冗余，HA服務(wù)自動(dòng)管理切換滿(mǎn)足高可用性。性能方面通常也是采用縱向擴(kuò)容的方式。然而縱向擴(kuò)容是有限制的。如果最強(qiáng)的主機(jī)都搞不定了怎么辦?

圖 1. 集中式架構(gòu)

在集中式架構(gòu)的數(shù)據(jù)庫(kù)里面有一個(gè)例外，那就是MPP數(shù)據(jù)庫(kù)。為了解決單節(jié)點(diǎn)數(shù)據(jù)庫(kù)性能上限問(wèn)題，某些數(shù)據(jù)庫(kù)廠商開(kāi)發(fā)出來(lái)MPP數(shù)據(jù)庫(kù)。這種數(shù)據(jù)庫(kù)算是一套集群，數(shù)據(jù)分布在這些集群的節(jié)點(diǎn)上，數(shù)據(jù)查詢(xún)服務(wù)也能下推到這些節(jié)點(diǎn)完成。通過(guò)數(shù)據(jù)分發(fā)和功能分發(fā)，充分利用多節(jié)點(diǎn)的處理能力，這簡(jiǎn)直就是現(xiàn)在的分布式先驅(qū)。

圖 2. 集中式MPP架構(gòu)

圖中協(xié)調(diào)節(jié)點(diǎn)CN并非是一個(gè)特殊組件，這可以是任何一個(gè)DN。不過(guò)這類(lèi)產(chǎn)品是面向OLAP的，是為了解決大查詢(xún)問(wèn)題，和現(xiàn)在分布式的方向并不一樣。

2. 面向服務(wù)的架構(gòu)(SOA)

在互聯(lián)網(wǎng)浪潮還沒(méi)到來(lái)，分布式架構(gòu)還未興起的時(shí)候，為了解決單機(jī)性能瓶頸和全局服務(wù)可用性問(wèn)題，最初的方案是業(yè)務(wù)拆分，也就是面向服務(wù)的架構(gòu)(SOA)開(kāi)始應(yīng)用起來(lái)。純粹的SOA其實(shí)是一個(gè)組件模型，它將應(yīng)用程序的不同功能單元(稱(chēng)為服務(wù))進(jìn)行拆分，并通過(guò)這些服務(wù)之間定義良好的接口和協(xié)議聯(lián)系起來(lái)。SOA架構(gòu)曾經(jīng)流行了一段時(shí)間，當(dāng)然現(xiàn)在更火的是微服務(wù)模式。

圖 3. SOA架構(gòu)

當(dāng)時(shí)有很多銀行將自己的核心系統(tǒng)依照這個(gè)思路拆分，一個(gè)大系統(tǒng)拆成多個(gè)小系統(tǒng)或者是組件。優(yōu)點(diǎn)是服務(wù)拆分之后實(shí)現(xiàn)了部分性能擴(kuò)展。之所以說(shuō)是部分，是因?yàn)榭傆行┖诵姆?wù)是熱點(diǎn)，沒(méi)有辦法做到拆分的。隨之帶來(lái)的缺點(diǎn)是系統(tǒng)調(diào)用鏈復(fù)雜程度增加了，數(shù)據(jù)在不同服務(wù)間的同步要求變多變復(fù)雜，然后系統(tǒng)和服務(wù)器的數(shù)量增多了。即便是采用了SOA的思路，還是沒(méi)有徹底解決熱點(diǎn)功能的性能問(wèn)題和可用性問(wèn)題：

1. 沒(méi)有實(shí)現(xiàn)核心功能的水平擴(kuò)展，單個(gè)功能還是屬于集中式架構(gòu)部署。

2. 沒(méi)有實(shí)現(xiàn)數(shù)據(jù)水平拆分，解決不了大數(shù)據(jù)量的問(wèn)題，反而帶來(lái)了不同系統(tǒng)數(shù)據(jù)同步的復(fù)雜需求。

3. 分布式架構(gòu)

就在金融行業(yè)還在忙著為系統(tǒng)功能拆分改造，給新的小機(jī)打預(yù)算的同時(shí)，中國(guó)的互聯(lián)網(wǎng)科技行業(yè)正在發(fā)生大的變革。

大數(shù)據(jù)技術(shù)發(fā)展：第一大變革是各種分布式開(kāi)源軟件走向成熟并被充分利用。分布式存儲(chǔ)、分布式計(jì)算、分布式消息中間件引領(lǐng)大數(shù)據(jù)行業(yè)變革。這些分布式技術(shù)簡(jiǎn)單粗暴的解決了大數(shù)據(jù)量、高吞吐量和高可用性的難題。這些難題對(duì)業(yè)務(wù)系統(tǒng)和后臺(tái)的數(shù)據(jù)庫(kù)同樣存在。看起來(lái)數(shù)據(jù)庫(kù)走向分布式才是終極解決方案。然數(shù)據(jù)庫(kù)行業(yè)的領(lǐng)先者們并沒(méi)有像擁抱云技術(shù)那樣去擁抱分布式數(shù)據(jù)庫(kù)，反而給了眾多初創(chuàng)數(shù)據(jù)庫(kù)企業(yè)機(jī)會(huì)。

互聯(lián)網(wǎng)消費(fèi)行為：另外一大變革是互聯(lián)網(wǎng)行業(yè)改變了用戶(hù)的消費(fèi)行為。這幾年網(wǎng)絡(luò)運(yùn)營(yíng)商在提速降費(fèi)，互聯(lián)網(wǎng)移動(dòng)設(shè)備出貨量飆升，用戶(hù)的消費(fèi)習(xí)慣也大量從線(xiàn)下轉(zhuǎn)移到線(xiàn)上。中國(guó)的人口紅利在互聯(lián)網(wǎng)產(chǎn)業(yè)發(fā)揮的淋漓盡致。對(duì)于金融行業(yè)來(lái)說(shuō)，用戶(hù)消費(fèi)行為的變化帶來(lái)的是對(duì)金融科技的挑戰(zhàn)。交易量和數(shù)據(jù)量都在不停攀升高峰。尤其是網(wǎng)銀，手機(jī)銀行等渠道類(lèi)業(yè)務(wù)都將面臨集中式架構(gòu)性能瓶頸問(wèn)題。

其中最典型的就是阿里。阿里從2011年開(kāi)始基于成本因素的考慮逐步去IOE，同時(shí)年年祭出了雙十一成績(jī)單。高帥富的小機(jī)替換成了PC機(jī)，Oracle數(shù)據(jù)庫(kù)換成了開(kāi)源MySQL數(shù)據(jù)庫(kù)，同時(shí)自研分布式中間件TDDL實(shí)現(xiàn)橫向擴(kuò)展。阿里通過(guò)堆砌廉價(jià)的PC機(jī)來(lái)支撐龐大的雙十一促銷(xiāo)業(yè)務(wù)，最終交出了交易量、峰值、金額等漂亮的成績(jī)單?，F(xiàn)在阿里的分布式中間件發(fā)展成了關(guān)系型數(shù)據(jù)庫(kù) DRDS。同時(shí)阿里還有面向金融領(lǐng)域全自研內(nèi)核的OceanBase，主打云數(shù)據(jù)庫(kù)存儲(chǔ)計(jì)算分離架構(gòu)的PolarDB。

技術(shù)自主可控：這幾年國(guó)際關(guān)系大環(huán)境也在發(fā)生變化，國(guó)內(nèi)尋求自主可控的聲音越來(lái)越響。相應(yīng)的國(guó)內(nèi)也涌現(xiàn)出了很多主打數(shù)據(jù)庫(kù)產(chǎn)品和服務(wù)的企業(yè)。尤其是分布式數(shù)據(jù)庫(kù)技術(shù)，在國(guó)際數(shù)據(jù)庫(kù)領(lǐng)頭羊們還沒(méi)有全力投入拿出作品的時(shí)候，國(guó)內(nèi)很多企業(yè)借鑒開(kāi)源分布式技術(shù)方案，研發(fā)出了自己的分布式數(shù)據(jù)庫(kù)。因?yàn)闆](méi)有作業(yè)可抄，所以大家做的作業(yè)也很不一樣。

綜上所述，內(nèi)有金融行業(yè)對(duì)于大數(shù)據(jù)量、高吞吐量和高可用性的迫切需求以及自主可控的需求，外有大數(shù)據(jù)分布式技術(shù)方案得到肯定，再加上互聯(lián)網(wǎng)行業(yè)解決方案引領(lǐng)，金融行業(yè)對(duì)國(guó)內(nèi)優(yōu)秀的分布式數(shù)據(jù)庫(kù)的需求持續(xù)走強(qiáng)。

二、分布式數(shù)據(jù)庫(kù)經(jīng)歷了哪幾個(gè)發(fā)展階段?

分布式數(shù)據(jù)庫(kù)是為了解決大數(shù)據(jù)量、高吞吐量和高可用性的問(wèn)題，通過(guò)數(shù)據(jù)和計(jì)算分片的方式提供橫向擴(kuò)展能力。然而思路很明確，實(shí)現(xiàn)很復(fù)雜。為了更清楚當(dāng)前一些分布式數(shù)據(jù)庫(kù)的實(shí)現(xiàn)原理，我們首先將要數(shù)據(jù)庫(kù)分為三層來(lái)看待：解析層，計(jì)算層，存儲(chǔ)層。而分布式的實(shí)現(xiàn)就是在解決這幾層的實(shí)現(xiàn)問(wèn)題。我把分布式數(shù)據(jù)庫(kù)的發(fā)展分為三個(gè)階段。

1. 讀寫(xiě)分離

為了解決集中式架構(gòu)下的單節(jié)點(diǎn)計(jì)算性能問(wèn)題，首先出現(xiàn)的方案是讀寫(xiě)分離模式。當(dāng)時(shí)MySQL開(kāi)源數(shù)據(jù)庫(kù)比較流行。然而MySQL單節(jié)點(diǎn)的處理性能很容易遇到瓶頸。MySQL主從復(fù)制的架構(gòu)下，主庫(kù)可讀寫(xiě)，然而備庫(kù)建議只讀。因此如果SQL解析層能夠做到讀寫(xiě)分離，那么主庫(kù)的壓力將會(huì)大大降低。

圖 4. 讀寫(xiě)分離架構(gòu)

這種架構(gòu)曾經(jīng)流行一段時(shí)間，這個(gè)階段MySQL發(fā)展勢(shì)頭也很迅猛，開(kāi)始挑戰(zhàn)商業(yè)數(shù)據(jù)庫(kù)的地位。商業(yè)數(shù)據(jù)庫(kù)的用戶(hù)也向IBM和Oracle等提出了相關(guān)的需求。這種架構(gòu)下每個(gè)數(shù)據(jù)節(jié)點(diǎn)的數(shù)據(jù)是全量的?？蛻?hù)端或者是數(shù)據(jù)庫(kù)中間件需要解決SQL的讀寫(xiě)分發(fā)問(wèn)題：如何保證數(shù)據(jù)一致性，如何設(shè)計(jì)SQL的隔離級(jí)別，如何解決鎖問(wèn)題等等。

• 解析層

解析層需要實(shí)現(xiàn)讀寫(xiě)分發(fā)。

• 計(jì)算層

實(shí)現(xiàn)了從庫(kù)接受讀交易，一定程度分散了壓力。

• 存儲(chǔ)層

單節(jié)點(diǎn)是全量數(shù)據(jù)。數(shù)據(jù)同步通過(guò)數(shù)據(jù)庫(kù)的主從復(fù)制技術(shù)實(shí)現(xiàn)。

如果存儲(chǔ)計(jì)算分離，然后實(shí)現(xiàn)分布式存儲(chǔ)。那么這種架構(gòu)又可以進(jìn)一步解決存儲(chǔ)層的壓力問(wèn)題?，F(xiàn)在最典型的是阿里云的polardb。

圖 5. 阿里云polardb分布式存儲(chǔ)

阿里云的polardb實(shí)現(xiàn)遠(yuǎn)遠(yuǎn)比簡(jiǎn)單的讀寫(xiě)分離要豐富的多。首先這是個(gè)面向云的原生數(shù)據(jù)庫(kù)，是屬于軟硬一體的解決方案。

• 解析層

實(shí)現(xiàn)讀寫(xiě)分離和負(fù)載均衡。

• 計(jì)算層

縱向擴(kuò)展單節(jié)點(diǎn)性能，橫向擴(kuò)展讀性能。

• 存儲(chǔ)層

分布式存儲(chǔ)，分片方式對(duì)應(yīng)用透明。通過(guò)FPGA，RDMA等硬件技術(shù)加速性能。

個(gè)人認(rèn)為云數(shù)據(jù)庫(kù)是未來(lái)的趨勢(shì)，阿里polardb和騰訊tdsql會(huì)大放異彩。

2. 分布式中間件模式

讀寫(xiě)分離還是不能滿(mǎn)足中國(guó)互聯(lián)網(wǎng)龐大的用戶(hù)體量。銀行有幾千萬(wàn)上億的用戶(hù)，互聯(lián)網(wǎng)更多。但凡來(lái)個(gè)促銷(xiāo)活動(dòng)，運(yùn)維人員就心驚肉跳。僅僅靠讀寫(xiě)分離其實(shí)不能滿(mǎn)足這種集中并發(fā)式的性能瓶頸。那么能不能將這些用戶(hù)的交易數(shù)據(jù)分開(kāi)放在不同的節(jié)點(diǎn)上，讓這些用戶(hù)只在對(duì)應(yīng)的節(jié)點(diǎn)處理數(shù)據(jù)呢?這就是現(xiàn)在分布式的主流思路：數(shù)據(jù)分片。

圖 6. 數(shù)據(jù)庫(kù)中間件

圖中的每個(gè)分片都可以是一套主從架構(gòu)的數(shù)據(jù)庫(kù)，不僅僅是一個(gè)物理節(jié)點(diǎn)。

• 解析層

實(shí)現(xiàn)sql分發(fā)查詢(xún)以及結(jié)果匯聚。數(shù)據(jù)分片的定義需要在這一層保存。對(duì)于跨節(jié)點(diǎn)的分布式事務(wù)支持能力很單薄。這個(gè)主要看分布式中間件的產(chǎn)品能力。

• 計(jì)算層

通過(guò)底層數(shù)據(jù)的分片，計(jì)算層已經(jīng)完全實(shí)現(xiàn)了負(fù)載分離。

• 存儲(chǔ)層

數(shù)據(jù)分片后，存儲(chǔ)層的性能問(wèn)題也完美解決。

這種架構(gòu)的典型代表是阿里最初的TDDL數(shù)據(jù)庫(kù)中間件產(chǎn)品和開(kāi)源數(shù)據(jù)庫(kù)中間件Mycat。阿里的TDDL數(shù)據(jù)庫(kù)中間件已經(jīng)演變成現(xiàn)在的DRDS集群。

首先我們來(lái)看看Mycat的解決方案。

圖 7. Mycat數(shù)據(jù)庫(kù)中間件

Mycat數(shù)據(jù)庫(kù)中間件架設(shè)在應(yīng)用和底層數(shù)據(jù)庫(kù)之間。應(yīng)用SQL會(huì)解析轉(zhuǎn)化并路由到底層多個(gè)數(shù)據(jù)庫(kù)主備集群里。這種方案不需要底層數(shù)據(jù)庫(kù)做任何改動(dòng)。然而支持復(fù)雜SQL的能力有限。使用這種架構(gòu)要避免分布式事務(wù)。

下面看看阿里云的DRDS解決方案。DRDS雖然是中間件模式，不過(guò)現(xiàn)在推出的解決方案更像是個(gè)完整的分布式集群數(shù)據(jù)庫(kù)。DRDS是分布式中間件，底層是RDS數(shù)據(jù)庫(kù)集群(mysql)。RDS數(shù)據(jù)庫(kù)服務(wù)是阿里云提供的關(guān)系型數(shù)據(jù)庫(kù)服務(wù)統(tǒng)稱(chēng)，主要是MySQL。DRDS通過(guò)兩階段提交來(lái)實(shí)現(xiàn)分布式事務(wù)。

圖 8. 阿里云DRDS

如果存在分布式的事務(wù)，那么在這種架構(gòu)下最好由應(yīng)用層面去解決。這方面我覺(jué)得做的最好的是招商銀行。招行一開(kāi)始就將分布式事務(wù)和分片的角色都放在業(yè)務(wù)應(yīng)用開(kāi)發(fā)層面，因此不需要依賴(lài)底層數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)分庫(kù)分表。

3. 分布式集群模式

中間件模式其實(shí)還是和數(shù)據(jù)庫(kù)引擎脫離的。分布式中間件如果將中間件和底層數(shù)據(jù)庫(kù)揉在一起，當(dāng)做一個(gè)產(chǎn)品去開(kāi)發(fā)使用，這就是現(xiàn)在的分布式集群數(shù)據(jù)庫(kù)。我觀察了國(guó)內(nèi)各家廠商分布式數(shù)據(jù)庫(kù)的實(shí)現(xiàn)，基本濃縮成下面這張示意圖。

圖 9. 分布式數(shù)據(jù)庫(kù)集群

協(xié)調(diào)節(jié)點(diǎn)：這是分布式數(shù)據(jù)庫(kù)接受用戶(hù)請(qǐng)求和返回?cái)?shù)據(jù)的處理節(jié)點(diǎn)，通常以多活的模式部署在多個(gè)物理節(jié)點(diǎn)上。協(xié)調(diào)節(jié)點(diǎn)之間的事務(wù)控制通過(guò)向全局管理節(jié)點(diǎn)請(qǐng)求，獲取全局事務(wù)信息或者鎖信息。協(xié)調(diào)節(jié)點(diǎn)的SQL會(huì)編譯執(zhí)行，調(diào)取對(duì)應(yīng)的數(shù)據(jù)節(jié)點(diǎn)。

數(shù)據(jù)節(jié)點(diǎn)：真正存放數(shù)據(jù)的地方。從協(xié)調(diào)節(jié)點(diǎn)導(dǎo)入的數(shù)據(jù)通過(guò)分片或者復(fù)制的方式存放在數(shù)據(jù)節(jié)點(diǎn)里面。數(shù)據(jù)節(jié)點(diǎn)通常只需要響應(yīng)協(xié)調(diào)節(jié)點(diǎn)的調(diào)取。數(shù)據(jù)節(jié)點(diǎn)通過(guò)一主多備的模式提高數(shù)據(jù)可用性。備節(jié)點(diǎn)一般不提供讀取服務(wù)。

全局管理節(jié)點(diǎn)：分布式數(shù)據(jù)庫(kù)的核心，也是區(qū)別于分布式中間件方案的關(guān)鍵組件。全局管理節(jié)點(diǎn)用于全局事務(wù)控制、元數(shù)據(jù)管理等。這些需要全局控制的功能可能會(huì)被拆分成多個(gè)組件來(lái)部署，這也是不同分布式數(shù)據(jù)庫(kù)集群的根本差異。

集群管理節(jié)點(diǎn)：這是數(shù)據(jù)庫(kù)集群高可用性的保證。用于全局監(jiān)控?cái)?shù)據(jù)庫(kù)各項(xiàng)組件的狀態(tài)，并且依據(jù)狀態(tài)變化自動(dòng)響應(yīng)。集群管理節(jié)點(diǎn)控制著整個(gè)集群里組件的切換和維護(hù)。

上述邏輯節(jié)點(diǎn)可以在物理節(jié)點(diǎn)上混部署，加上數(shù)據(jù)中心的概念。集群可以跨多中心部署實(shí)現(xiàn)數(shù)據(jù)中心級(jí)的容災(zāi)。國(guó)內(nèi)現(xiàn)在比較突出分布式數(shù)據(jù)庫(kù)gaussT、TIDB、glodendb、sequoiadb、antdb等都是這類(lèi)架構(gòu)。下面看兩個(gè)典型的國(guó)產(chǎn)化數(shù)據(jù)案例，與大部分分布式數(shù)據(jù)庫(kù)的解決方案不一樣的是，他們的數(shù)據(jù)庫(kù)引擎不是基于MySQL。

第一個(gè)是華為的高斯數(shù)據(jù)庫(kù)gaussT。

圖 10. 華為gaussT數(shù)據(jù)庫(kù)

這是華為官方的高斯數(shù)據(jù)庫(kù)。其中ETCD和CM是集群管理器，用來(lái)選擇和操作整個(gè)集群。其中ETCD存放集群整體狀態(tài)信息，基于paxos協(xié)議保證可用性。CN是接受用戶(hù)請(qǐng)求的協(xié)調(diào)節(jié)點(diǎn)，負(fù)責(zé)數(shù)據(jù)和SQL的分發(fā)和匯總。CN多活，客戶(hù)端通過(guò)負(fù)載均衡模式連接CN。GTS是全局事務(wù)管理節(jié)點(diǎn)，僅處理事務(wù)號(hào)的請(qǐng)求并且有緩存機(jī)制，因此相對(duì)處理性能比較高。DN是數(shù)據(jù)節(jié)點(diǎn)，一主多備模式保證高可用。集群內(nèi)部的表有兩種方式建立，一種是選好分布鍵的分片數(shù)據(jù)表，一種是全局同步復(fù)制的復(fù)制表。從高斯數(shù)據(jù)庫(kù)的架構(gòu)來(lái)說(shuō)，它是典型的傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的升華版：全面支持分布式事務(wù)，集群當(dāng)做一個(gè)數(shù)據(jù)庫(kù)來(lái)用的方式對(duì)用戶(hù)友好。

說(shuō)到分布式數(shù)據(jù)庫(kù)也要提到TIDB。TIDB是PingCAP公司推出的開(kāi)源分布式數(shù)據(jù)庫(kù)。在一幫做分布式數(shù)據(jù)庫(kù)的廠家中，TIDB是個(gè)另類(lèi)，另辟蹊徑主打先進(jìn)的數(shù)據(jù)庫(kù)架構(gòu)和良好的開(kāi)源生態(tài)。

圖 11. TIDB數(shù)據(jù)庫(kù)

在TIDB的架構(gòu)圖里，TiDB Cluster是接受請(qǐng)求的協(xié)調(diào)節(jié)點(diǎn)，用作SQL解析和轉(zhuǎn)發(fā)。TiKV是存放數(shù)據(jù)的數(shù)據(jù)節(jié)點(diǎn)。與其他分布式數(shù)據(jù)庫(kù)不同的是TIDB用的是分布式的KV存儲(chǔ)引擎。TIDB的數(shù)據(jù)分發(fā)也和其他分布式數(shù)據(jù)庫(kù)必須指定分區(qū)鍵分片規(guī)則不同，實(shí)現(xiàn)的是基于Region級(jí)別的raft復(fù)制，還可以根據(jù)負(fù)載情況進(jìn)行合并和分裂。這個(gè)特點(diǎn)是其他分布式數(shù)據(jù)庫(kù)做不到的。PD Cluster相當(dāng)于是全局事務(wù)管理器。集群管理器在圖中沒(méi)有標(biāo)出來(lái)，其實(shí)里面的每個(gè)cluster都有相應(yīng)的集群服務(wù)。

三種分布式方案已經(jīng)介紹差不多了，最后來(lái)看看中興Goldendb吧。

圖 12. GoldenDB三種部署形態(tài)

中興Goldendb將這三種部署形態(tài)全部集成。No-Sharding就是單機(jī)部署一主多備模式，提供讀寫(xiě)分離的負(fù)載方案。Sharding集群就是中間件部署模式，計(jì)算節(jié)點(diǎn)做轉(zhuǎn)發(fā)，不支持分布式事務(wù)。Distribute Transaction集群就是加了GTM全局事務(wù)管理器，支持分布式事務(wù)。

4. 分布式數(shù)據(jù)庫(kù)測(cè)試體會(huì)

介紹了這么多分布式數(shù)據(jù)庫(kù)架構(gòu)，我們也測(cè)試了很多家的數(shù)據(jù)庫(kù)產(chǎn)品。這里談?wù)勩y行在測(cè)試分布式過(guò)程中的一些經(jīng)驗(yàn)：

1. 對(duì)于單點(diǎn)數(shù)據(jù)的增刪改查，大家的性能都很好，極限瓶頸一般出現(xiàn)在全局事務(wù)管理這個(gè)環(huán)節(jié)。因此這部分的性能差異就在于這個(gè)全局事務(wù)的處理問(wèn)題上。這也決定了一個(gè)分布式數(shù)據(jù)庫(kù)的性能上限。

2. 對(duì)于分布式事務(wù)，需要跨節(jié)點(diǎn)數(shù)據(jù)訪問(wèn)的，大家的性能都不怎么好。其實(shí)分布式事務(wù)對(duì)于分布式數(shù)據(jù)庫(kù)來(lái)說(shuō)還是有很大挑戰(zhàn)的。對(duì)于使用分布式數(shù)據(jù)庫(kù)的業(yè)務(wù)，建議減少分布式事務(wù)，也不要把分布式數(shù)據(jù)庫(kù)當(dāng)做混合負(fù)載來(lái)用。尤其是像不同分布鍵的大表關(guān)聯(lián)，搞垮協(xié)調(diào)節(jié)點(diǎn)是分分鐘的。這部分技術(shù)還是面向數(shù)倉(cāng)的MPP數(shù)據(jù)庫(kù)比較合適。如果MPP數(shù)據(jù)庫(kù)的這部分能力被集成到分布式數(shù)據(jù)庫(kù)中，那這個(gè)分布式數(shù)據(jù)庫(kù)才真是厲害了，從容面對(duì)HTAP。

3. 使用分布式數(shù)據(jù)庫(kù)一定要關(guān)注分布鍵。無(wú)論是分片還是復(fù)制，業(yè)務(wù)開(kāi)發(fā)人員需要從自己的業(yè)務(wù)邏輯開(kāi)發(fā)，合理設(shè)置。一旦選不好，分布式數(shù)據(jù)庫(kù)還不如單節(jié)點(diǎn)性能。

4. 分布式數(shù)據(jù)庫(kù)數(shù)據(jù)重分布，也就是橫向擴(kuò)展，都是痛點(diǎn)。無(wú)論是操作方式還是性能影響，基本上所有的分布式數(shù)據(jù)庫(kù)都成問(wèn)題。可能使用自動(dòng)分布可擴(kuò)展的存儲(chǔ)引擎才是最終解決方案。

5. 分布式數(shù)據(jù)庫(kù)集群組件眾多，相對(duì)來(lái)說(shuō)管理比較復(fù)雜。每個(gè)組件都有自己的日志，都可能有性能瓶頸。在分布式數(shù)據(jù)庫(kù)環(huán)境下運(yùn)維管理成本比較高。

三、傳統(tǒng)數(shù)據(jù)庫(kù)運(yùn)維崗面臨哪些挑戰(zhàn)?

分布式數(shù)據(jù)庫(kù)的應(yīng)用解決了傳統(tǒng)數(shù)據(jù)庫(kù)性能擴(kuò)展問(wèn)題的同時(shí)，也給運(yùn)維人員帶來(lái)了挑戰(zhàn)。以前一套標(biāo)準(zhǔn)就可以運(yùn)維好傳統(tǒng)數(shù)據(jù)庫(kù)，定好參數(shù)規(guī)則，做好應(yīng)急防護(hù)即可?，F(xiàn)在多了分布式數(shù)據(jù)庫(kù)，并不只是多了個(gè)數(shù)據(jù)庫(kù)產(chǎn)品那么簡(jiǎn)單，而是多了種數(shù)據(jù)庫(kù)的使用方式。

1. 分布式數(shù)據(jù)庫(kù)管理多了什么?

統(tǒng)一數(shù)據(jù)視圖：分布式數(shù)據(jù)庫(kù)數(shù)據(jù)做了分片之后，運(yùn)維人員需要解決數(shù)據(jù)透視的問(wèn)題。哪些表是分片表，哪些表是復(fù)制表?如果需要導(dǎo)出或者同步數(shù)據(jù)到其他系統(tǒng)，這個(gè)方案該怎么做?一張表被分成了多少份，整體的數(shù)據(jù)量是多少?如果選擇了分布式數(shù)據(jù)庫(kù)成熟產(chǎn)品還好，這些部分有產(chǎn)品級(jí)的解決方案。中間件型的分布式就更難了。對(duì)于用戶(hù)來(lái)說(shuō)，如果還能將集群里的數(shù)據(jù)當(dāng)做一個(gè)數(shù)據(jù)庫(kù)來(lái)操作是最理想的。

大量節(jié)點(diǎn)管理：選擇分布式，就是選擇橫向擴(kuò)展。相應(yīng)的運(yùn)維節(jié)點(diǎn)數(shù)量會(huì)出現(xiàn)爆發(fā)式增長(zhǎng)。這個(gè)運(yùn)維力量一下子就上去了。還好需要上分布式的系統(tǒng)不會(huì)太多。現(xiàn)在這些節(jié)點(diǎn)不僅都需要單獨(dú)監(jiān)控管理，還需要管理好節(jié)點(diǎn)的角色。

容量管理：這里的容量管理包含性能和數(shù)據(jù)兩個(gè)方面。在分布式環(huán)境下一定要關(guān)注負(fù)載分布問(wèn)題。因?yàn)閺母旧蟻?lái)說(shuō)分布式就是為了解決性能負(fù)載而誕生的。運(yùn)維人員需要檢測(cè)到負(fù)載是否均衡，是否符合預(yù)期，如果有問(wèn)題，需要從數(shù)據(jù)分布和業(yè)務(wù)行為的角度一起去分析。這相對(duì)是比較復(fù)雜和困難的。另一方面，分布式數(shù)據(jù)庫(kù)里面最怕出現(xiàn)數(shù)據(jù)傾斜問(wèn)題。嚴(yán)重的數(shù)據(jù)傾斜會(huì)導(dǎo)致性能瓶頸和容量瓶頸。出現(xiàn)傾斜后如何數(shù)據(jù)重分布也是很難的問(wèn)題。

數(shù)據(jù)一致性：分布式數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性可能會(huì)被用戶(hù)忽略。因?yàn)樵诩惺綌?shù)據(jù)庫(kù)中很少會(huì)出現(xiàn)這種問(wèn)題。然而分布式數(shù)據(jù)庫(kù)的分布式事務(wù)基本都是通過(guò)兩階段提交的方式來(lái)實(shí)現(xiàn)。出現(xiàn)問(wèn)題的情況下可能會(huì)出現(xiàn)提交殘留。因此用戶(hù)需要定時(shí)檢查數(shù)據(jù)庫(kù)是否存在兩階段提交殘留，定時(shí)比對(duì)數(shù)據(jù)。

變更管理：分布式環(huán)境下的變更問(wèn)題也需要重視。節(jié)點(diǎn)變多了，數(shù)據(jù)庫(kù)拆散了，變更也就存在全局和單點(diǎn)的維度。如何統(tǒng)一變更保證集群所有機(jī)器都完成而沒(méi)有遺漏?是不是所有的節(jié)點(diǎn)都變更了?能不能通過(guò)定時(shí)參數(shù)比對(duì)等方式提示參數(shù)不一樣的節(jié)點(diǎn)?

容災(zāi)方案：分布式數(shù)據(jù)庫(kù)的災(zāi)備方案該怎么做?兩地三中心采用什么方式實(shí)現(xiàn)?異構(gòu)數(shù)據(jù)庫(kù)的數(shù)據(jù)同步方案有哪些?數(shù)據(jù)遷移方案呢?這些在單節(jié)點(diǎn)數(shù)據(jù)庫(kù)的情況下有很多成熟并久經(jīng)考驗(yàn)的方案可以使用。然而在分布式環(huán)境下，現(xiàn)在只能說(shuō)是陪著廠商一起成長(zhǎng)。

多租戶(hù)管理：多租戶(hù)管理是分布式數(shù)據(jù)庫(kù)環(huán)境需要解決的重要功能。運(yùn)維人員需要把相應(yīng)的產(chǎn)品方案用起來(lái)，并且在運(yùn)維的過(guò)程中關(guān)注租戶(hù)的容量和性能需求，并相應(yīng)調(diào)整數(shù)據(jù)庫(kù)。

2. 如何管理好分布式數(shù)據(jù)庫(kù)

分布式數(shù)據(jù)庫(kù)作為新的技術(shù)，并不是脫胎于成熟的商業(yè)數(shù)據(jù)庫(kù)，因此還有很多粗糙的地方。尤其是金融行業(yè)的用戶(hù)，被傳統(tǒng)商業(yè)數(shù)據(jù)庫(kù)“嬌生慣養(yǎng)”，首次接觸到新生數(shù)據(jù)庫(kù)的時(shí)候，會(huì)有四處碰壁的感覺(jué)。但是即便是硬骨頭，還是得啃。

控制應(yīng)用場(chǎng)景：

分布式不是萬(wàn)能的，它是面向特殊場(chǎng)景的數(shù)據(jù)庫(kù)產(chǎn)品。只有符合的交易才能往上遷移。如果不想自己麻煩，那就別麻煩分布式數(shù)據(jù)庫(kù)了。這個(gè)要求運(yùn)維人員不僅僅在看產(chǎn)品，還需要與業(yè)務(wù)人員和開(kāi)發(fā)人員緊密合作。要從業(yè)務(wù)分片的角度去管理數(shù)據(jù)庫(kù)。因此使用分布式數(shù)據(jù)庫(kù)必須定義一個(gè)使用場(chǎng)景規(guī)范。

統(tǒng)一管理平臺(tái)：

分布式數(shù)據(jù)庫(kù)的數(shù)據(jù)分片后，運(yùn)維人員需要了解數(shù)據(jù)的整體規(guī)劃是什么樣子的，數(shù)據(jù)分片規(guī)則，復(fù)制方案，同步方案等。使用分布式數(shù)據(jù)庫(kù)集群的用戶(hù)可能要輕松一些，因?yàn)檫@些產(chǎn)品可能有相應(yīng)的產(chǎn)品級(jí)解決方案。而采用了分布式中間件的用戶(hù)，如何還能隨時(shí)查詢(xún)和透視數(shù)據(jù)表的關(guān)系，這是需要另尋方案的。不管是何種方式，這些都是分布式數(shù)據(jù)庫(kù)運(yùn)維需要做好的事情。

所以運(yùn)維人員需要建立一套數(shù)據(jù)管理平臺(tái)。在平臺(tái)里查看和操作分布式數(shù)據(jù)庫(kù)集群狀態(tài)，管理數(shù)據(jù)庫(kù)用戶(hù)、權(quán)限、分布規(guī)則、配置下發(fā)、配置比對(duì)、查看日志、分析等各類(lèi)管理功能。最好也包含多租戶(hù)管理。

智能監(jiān)控平臺(tái)：

引進(jìn)分布式數(shù)據(jù)庫(kù)之后，運(yùn)維人員需要監(jiān)控分布式數(shù)據(jù)庫(kù)節(jié)點(diǎn)狀態(tài)和各個(gè)節(jié)點(diǎn)的性能。首先要解決的問(wèn)題是將新數(shù)據(jù)庫(kù)接入到監(jiān)控告警平臺(tái)。原先適用于單機(jī)數(shù)據(jù)庫(kù)的各項(xiàng)監(jiān)控需要針對(duì)集群數(shù)據(jù)庫(kù)適配一遍。然后更進(jìn)一步，運(yùn)維人員還需要借助智能運(yùn)維來(lái)實(shí)現(xiàn)分布式數(shù)據(jù)庫(kù)的精細(xì)化監(jiān)控。智能監(jiān)控平臺(tái)需要分析發(fā)現(xiàn)分布式數(shù)據(jù)庫(kù)負(fù)載不均衡，節(jié)點(diǎn)行為離群等問(wèn)題，然后智能化展示故障影響鏈條。智能監(jiān)控平臺(tái)還能夠做性能容量趨勢(shì)分析和預(yù)測(cè)，提前警示性能容量告警。

容量管理：

這個(gè)主題單獨(dú)列出來(lái)，確實(shí)是因?yàn)檫@個(gè)主題太重要了。一定要有辦法能夠監(jiān)控?cái)?shù)據(jù)傾斜問(wèn)題和負(fù)載傾斜問(wèn)題，并且在管理平臺(tái)里需要做好負(fù)載重分布和數(shù)據(jù)重分布功能。分布式數(shù)據(jù)庫(kù)支持的數(shù)據(jù)分片方式一般有三種：hash、range和list。如果發(fā)生了數(shù)據(jù)傾斜問(wèn)題，運(yùn)維人員需要查看傾斜原因，并采用這現(xiàn)有的幾種方式嘗試?yán)^續(xù)打散數(shù)據(jù)。因此在容量管理這方面，運(yùn)維人員需要與業(yè)務(wù)及開(kāi)發(fā)人員緊密溝通，了解數(shù)據(jù)的業(yè)務(wù)信息，獲取業(yè)務(wù)增長(zhǎng)預(yù)期，這樣才能做好性能和容量規(guī)劃。

變更發(fā)布：

數(shù)據(jù)庫(kù)的參數(shù)變更可以通過(guò)統(tǒng)一管理平臺(tái)來(lái)實(shí)現(xiàn)。但是如果管理平臺(tái)沒(méi)有集成的功能，變更內(nèi)容也一定需要借助自動(dòng)化發(fā)布平臺(tái)來(lái)做。尤其是存在多數(shù)據(jù)中心容災(zāi)的情況下，人為變更是很容易遺漏的。最好是上線(xiàn)DevOps平臺(tái)，將分布式數(shù)據(jù)庫(kù)的變更也集成在平臺(tái)里。

通過(guò)建立這些管理平臺(tái)和工具，將數(shù)據(jù)庫(kù)運(yùn)維人員從忙于解決各種問(wèn)題的窘境中釋放出來(lái)，成長(zhǎng)為數(shù)據(jù)架構(gòu)師。DBA向前與業(yè)務(wù)場(chǎng)景對(duì)接，向后挑選合適的數(shù)據(jù)庫(kù)技術(shù)，基于標(biāo)準(zhǔn)化自動(dòng)化的部署維護(hù)方式，為業(yè)務(wù)穩(wěn)定運(yùn)行保駕護(hù)航。

四、未來(lái)，數(shù)據(jù)庫(kù)和數(shù)據(jù)庫(kù)運(yùn)維將去往何方?

我們正處在一個(gè)數(shù)據(jù)庫(kù)技術(shù)大爆炸的時(shí)代。這幾年NoSQL數(shù)據(jù)庫(kù)、NewSQL數(shù)據(jù)庫(kù)、時(shí)序數(shù)據(jù)庫(kù)、圖數(shù)據(jù)庫(kù)、分布式數(shù)據(jù)庫(kù)、超融合數(shù)據(jù)庫(kù)相關(guān)的技術(shù)百花齊放，國(guó)產(chǎn)數(shù)據(jù)庫(kù)也強(qiáng)勢(shì)發(fā)展起來(lái)。那么下一代主流數(shù)據(jù)庫(kù)是什么樣子呢?未來(lái)的運(yùn)維模式又將發(fā)生什么變化?

云數(shù)據(jù)庫(kù)：系統(tǒng)上云已經(jīng)成為這幾年的熱點(diǎn)。大廠也紛紛推出自己的云數(shù)據(jù)庫(kù)。未來(lái)云數(shù)據(jù)庫(kù)將會(huì)成為趨勢(shì)。數(shù)據(jù)庫(kù)服務(wù)將進(jìn)一步標(biāo)準(zhǔn)化輸出。無(wú)論是私有云還是公有云，用戶(hù)的數(shù)據(jù)庫(kù)使用方式正在發(fā)生變化。而分布式數(shù)據(jù)庫(kù)和超融合數(shù)據(jù)庫(kù)的強(qiáng)勁性能，也適合在云環(huán)境提供多租戶(hù)使用。

細(xì)分領(lǐng)域：數(shù)據(jù)庫(kù)應(yīng)用領(lǐng)域也會(huì)越來(lái)越細(xì)分?？赡墁F(xiàn)在我們還是希望有能夠面向HTAP場(chǎng)景的全能數(shù)據(jù)庫(kù)，但是未來(lái)數(shù)據(jù)庫(kù)功能將更加分化。尤其是通過(guò)數(shù)據(jù)庫(kù)云可以輕易申請(qǐng)到主打不同功能的數(shù)據(jù)庫(kù)來(lái)解決各類(lèi)業(yè)務(wù)場(chǎng)景。

智能運(yùn)維：隨著數(shù)據(jù)庫(kù)提供云部署云服務(wù)，數(shù)據(jù)庫(kù)運(yùn)維一定需要走向智能運(yùn)維。通過(guò)機(jī)器學(xué)習(xí)智能算法來(lái)監(jiān)控系統(tǒng)運(yùn)行狀態(tài)，依據(jù)數(shù)據(jù)表現(xiàn)提供決策、自動(dòng)修復(fù)、自動(dòng)擴(kuò)容。

最后想象一個(gè)場(chǎng)景，用戶(hù)申請(qǐng)了云數(shù)據(jù)庫(kù)，運(yùn)行一段時(shí)間后，智能運(yùn)維機(jī)器人告訴用戶(hù)數(shù)據(jù)庫(kù)最近發(fā)生了什么事情，一共發(fā)生了幾次自動(dòng)調(diào)優(yōu)，幾次自動(dòng)修復(fù)異常等，共節(jié)省了多少時(shí)間損失。還會(huì)基于用戶(hù)的使用場(chǎng)景，建議用戶(hù)擴(kuò)容或者是購(gòu)買(mǎi)更適合的數(shù)據(jù)庫(kù)服務(wù)，將有助于提高性能多少百分比等。

以上是筆者認(rèn)為在不久的將來(lái)即將發(fā)生的變化，你有什么看法?

【作者】孔再華，IBM認(rèn)證高級(jí)DBA，SAP認(rèn)證BASIS，具有豐富的數(shù)據(jù)庫(kù)環(huán)境問(wèn)題診斷和性能調(diào)優(yōu)的經(jīng)驗(yàn)。在數(shù)據(jù)庫(kù)同城雙活，集群，多分區(qū)，分布式等項(xiàng)目實(shí)施上具有豐富的經(jīng)驗(yàn)?，F(xiàn)任職于中國(guó)民生銀行科技部，工作致力于數(shù)據(jù)庫(kù)同城雙活架構(gòu)建設(shè)，數(shù)據(jù)庫(kù)分布式架構(gòu)建設(shè)和數(shù)據(jù)庫(kù)智能運(yùn)維(AIOps)方向。對(duì)于如何將AI技術(shù)運(yùn)用在運(yùn)維領(lǐng)域具有濃厚的興趣和創(chuàng)新熱情。

分享標(biāo)題：分布式架構(gòu)下，傳統(tǒng)數(shù)據(jù)庫(kù)運(yùn)維究竟要面對(duì)哪些變化？
瀏覽地址：http://www.dlmjj.cn/article/ccsggos.html