金融行業(yè)分布式架構(gòu)數(shù)據(jù)庫(kù)運(yùn)維轉(zhuǎn)型

1、 金融行業(yè)分布式架構(gòu)數(shù)據(jù)庫(kù)運(yùn)維轉(zhuǎn)型 【摘要】分布式架構(gòu)可能是近幾年最火的話題。從集中式、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)可能是近幾年最火的話題，與之相對(duì)的則是集中式架構(gòu)，后者是傳統(tǒng)金融行業(yè)如銀行最常見的部署架構(gòu)。在“去IOE”之前，各大

2、銀行的目標(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ā)，用戶行為模式發(fā)生變化，集中式架構(gòu)的系統(tǒng)面臨很大的挑戰(zhàn)。問(wèn)題主要體現(xiàn)在擴(kuò)展性和可用性這兩方面：1. 擴(kuò)展性集中式架構(gòu)的橫向水平擴(kuò)展能力非常低。面對(duì)性能不足，用戶能做的就是加CPU、加內(nèi)存、換存儲(chǔ)、換機(jī)器等方式。2. 可用性集中式架構(gòu)的服務(wù)能力依賴高性能的主機(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é)出故

3、障，影響的都是全局服務(wù)。這種架構(gòu)下的數(shù)據(jù)庫(kù)也是通過(guò)做主備機(jī)冗余，HA服務(wù)自動(dòng)管理切換滿足高可用性。性能方面通常也是采用縱向擴(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ù)廠商開發(fā)出來(lái)MPP數(shù)據(jù)庫(kù)。這種數(shù)據(jù)庫(kù)算是一套集群，數(shù)據(jù)分布在這些集群的節(jié)點(diǎn)上，數(shù)據(jù)查詢服務(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ò)這類產(chǎn)品是

4、面向OLAP的，是為了解決大查詢問(wèn)題，和現(xiàn)在分布式的方向并不一樣。2. 面向服務(wù)的架構(gòu)（SOA）在互聯(lián)網(wǎng)浪潮還沒到來(lái)，分布式架構(gòu)還未興起的時(shí)候，為了解決單機(jī)性能瓶頸和全局服務(wù)可用性問(wèn)題，最初的方案是業(yè)務(wù)拆分，也就是面向服務(wù)的架構(gòu)（SOA）開始應(yīng)用起來(lái)。純粹的SOA其實(shí)是一個(gè)組件模型，它將應(yī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ō)是部分，是因

5、為總有些核心服務(wù)是熱點(diǎn)，沒有辦法做到拆分的。隨之帶來(lái)的缺點(diǎn)是系統(tǒng)調(diào)用鏈復(fù)雜程度增加了，數(shù)據(jù)在不同服務(wù)間的同步要求變多變復(fù)雜，然后系統(tǒng)和服務(wù)器的數(shù)量增多了。即便是采用了SOA的思路，還是沒有徹底解決熱點(diǎn)功能的性能問(wèn)題和可用性問(wèn)題：1. 沒有實(shí)現(xiàn)核心功能的水平擴(kuò)展，單個(gè)功能還是屬于集中式架構(gòu)部署。2. 沒有實(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ā)展：第一大變革是各種分布式開源軟件走向成熟并被充分利用。分布式存儲(chǔ)、分布式計(jì)算、分布式

6、消息中間件引領(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)先者們并沒有像擁抱云技術(shù)那樣去擁抱分布式數(shù)據(jù)庫(kù)，反而給了眾多初創(chuàng)數(shù)據(jù)庫(kù)企業(yè)機(jī)會(huì)。互聯(lián)網(wǎng)消費(fèi)行為：另外一大變革是互聯(lián)網(wǎng)行業(yè)改變了用戶的消費(fèi)行為。這幾年網(wǎng)絡(luò)運(yùn)營(yíng)商在提速降費(fèi)，互聯(lián)網(wǎng)移動(dòng)設(shè)備出貨量飆升，用戶的消費(fèi)習(xí)慣也大量從線下轉(zhuǎn)移到線上。中國(guó)的人口紅利在互聯(lián)網(wǎng)產(chǎn)業(yè)發(fā)揮的淋漓盡致。對(duì)于金融行業(yè)來(lái)說(shuō)，用戶消費(fèi)行為的變化帶來(lái)的是對(duì)金融科技的挑戰(zhàn)。交易量和數(shù)據(jù)量都在不停攀升高峰。尤其是網(wǎng)銀，手機(jī)銀行等渠道類業(yè)務(wù)都將

7、面臨集中式架構(gòu)性能瓶頸問(wèn)題。其中最典型的就是阿里。阿里從2011年開始基于成本因素的考慮逐步去IOE，同時(shí)年年祭出了雙十一成績(jī)單。高帥富的小機(jī)替換成了PC機(jī)，Oracle數(shù)據(jù)庫(kù)換成了開源MySQL數(shù)據(jù)庫(kù)，同時(shí)自研分布式中間件TDDL實(shí)現(xiàn)橫向擴(kuò)展。阿里通過(guò)堆砌廉價(jià)的PC機(jī)來(lái)支撐龐大的雙十一促銷業(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)出了很

8、多主打數(shù)據(jù)庫(kù)產(chǎn)品和服務(wù)的企業(yè)。尤其是分布式數(shù)據(jù)庫(kù)技術(shù)，在國(guó)際數(shù)據(jù)庫(kù)領(lǐng)頭羊們還沒有全力投入拿出作品的時(shí)候，國(guó)內(nèi)很多企業(yè)借鑒開源分布式技術(shù)方案，研發(fā)出了自己的分布式數(shù)據(jù)庫(kù)。因?yàn)闆]有作業(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)前一些分布式

9、數(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. 讀寫分離為了解決集中式架構(gòu)下的單節(jié)點(diǎn)計(jì)算性能問(wèn)題，首先出現(xiàn)的方案是讀寫分離模式。當(dāng)時(shí)MySQL開源數(shù)據(jù)庫(kù)比較流行。然而MySQL單節(jié)點(diǎn)的處理性能很容易遇到瓶頸。MySQL主從復(fù)制的架構(gòu)下，主庫(kù)可讀寫，然而備庫(kù)建議只讀。因此如果SQL解析層能夠做到讀寫分離，那么主庫(kù)的壓力將會(huì)大大降低。圖 4. 讀寫分離架構(gòu)這種架構(gòu)曾經(jīng)流行一段時(shí)間，這個(gè)階段MySQL發(fā)展勢(shì)頭也很迅猛，開始挑戰(zhàn)商業(yè)數(shù)據(jù)庫(kù)的地位。商業(yè)數(shù)據(jù)庫(kù)的用戶也向IBM和Oracle等提出

10、了相關(guān)的需求。這種架構(gòu)下每個(gè)數(shù)據(jù)節(jié)點(diǎn)的數(shù)據(jù)是全量的?？蛻舳嘶蛘呤菙?shù)據(jù)庫(kù)中間件需要解決SQL的讀寫分發(fā)問(wèn)題：如何保證數(shù)據(jù)一致性，如何設(shè)計(jì)SQL的隔離級(jí)別，如何解決鎖問(wèn)題等等。解析層解析層需要實(shí)現(xiàn)讀寫分發(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)題。現(xiàn)在最典型的是阿里云的polardb。圖 5. 阿里云polardb分布式存儲(chǔ)阿里云的polardb實(shí)現(xiàn)遠(yuǎn)遠(yuǎn)比簡(jiǎn)單的讀寫分離要豐富的多。首先這是個(gè)面向云的原生數(shù)據(jù)庫(kù)，是屬于軟硬一體的解決方案。解析層實(shí)現(xiàn)讀

11、寫分離和負(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. 分布式中間件模式讀寫分離還是不能滿足中國(guó)互聯(lián)網(wǎng)龐大的用戶體量。銀行有幾千萬(wàn)上億的用戶，互聯(lián)網(wǎng)更多。但凡來(lái)個(gè)促銷活動(dòng)，運(yùn)維人員就心驚肉跳。僅僅靠讀寫分離其實(shí)不能滿足這種集中并發(fā)式的性能瓶頸。那么能不能將這些用戶的交易數(shù)據(jù)分開放在不同的節(jié)點(diǎn)上，讓這些用戶只在對(duì)應(yīng)的節(jié)點(diǎn)處理數(shù)據(jù)呢？這就是現(xiàn)在分布式的主流思路：數(shù)據(jù)分片。圖 6. 數(shù)據(jù)庫(kù)中間件圖中的每個(gè)分片都可以是一套主從架構(gòu)的數(shù)據(jù)庫(kù)

12、，不僅僅是一個(gè)物理節(jié)點(diǎn)。解析層實(shí)現(xiàn)sql分發(fā)查詢以及結(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)品和開源數(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ù)

13、據(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)稱，主要是MySQL。DRDS通過(guò)兩階段提交來(lái)實(shí)現(xiàn)分布式事務(wù)。圖 8. 阿里云DRDS如果存在分布式的事務(wù)，那么在這種架構(gòu)下最好由應(yīng)用層面去解決。這方面我覺得做的最好的是招商銀行。招行一開始就將分布式事務(wù)和分片的角色都放在業(yè)務(wù)應(yīng)用開發(fā)層面，因此不需要依賴底層數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)分庫(kù)分表。3. 分布式集群模式

14、中間件模式其實(shí)還是和數(shù)據(jù)庫(kù)引擎脫離的。分布式中間件如果將中間件和底層數(shù)據(jù)庫(kù)揉在一起，當(dāng)做一個(gè)產(chǎn)品去開發(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ù)接受用戶請(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ò)一主多備

15、的模式提高數(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、antd

16、b等都是這類架構(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是接受用戶請(qǐng)求的協(xié)調(diào)節(jié)點(diǎn)，負(fù)責(zé)數(shù)據(jù)和SQL的分發(fā)和匯總。CN多活，客戶端通過(guò)負(fù)載均衡模式連接CN。GTS是全局事務(wù)管理節(jié)點(diǎn)，僅處理事務(wù)號(hào)的請(qǐng)求并且有緩存機(jī)制，因此相對(duì)處理性能比較高。DN是數(shù)據(jù)節(jié)點(diǎn)，一主多備模式保證高可用。集群內(nèi)部的表有兩種方式建立，

17、一種是選好分布鍵的分片數(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ì)用戶友好。說(shuō)到分布式數(shù)據(jù)庫(kù)也要提到TIDB。TIDB是PingCAP公司推出的開源分布式數(shù)據(jù)庫(kù)。在一幫做分布式數(shù)據(jù)庫(kù)的廠家中，TIDB是個(gè)另類，另辟蹊徑主打先進(jìn)的數(shù)據(jù)庫(kù)架構(gòu)和良好的開源生態(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ù)

18、據(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ù)管理器。集群管理器在圖中沒有標(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ī)部署一主多備模式，提供讀寫分離的負(fù)載方案。Sharding集群就是中間件部署模式，計(jì)算節(jié)點(diǎn)做轉(zhuǎn)發(fā)，不支持分布式事務(wù)。Distribute Transac

19、tion集群就是加了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)，

20、搞垮協(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ù)開發(fā)人員需要從自己的業(yè)務(wù)邏輯開發(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ù)

21、環(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í)的解決方案。中間件型的

22、分布式就更難了。對(duì)于用戶來(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)重

23、的數(shù)據(jù)傾斜會(huì)導(dǎo)致性能瓶頸和容量瓶頸。出現(xiàn)傾斜后如何數(shù)據(jù)重分布也是很難的問(wèn)題。數(shù)據(jù)一致性：分布式數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性可能會(huì)被用戶忽略。因?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)提交殘留。因此用戶需要定時(shí)檢查數(shù)據(jù)庫(kù)是否存在兩階段提交殘留，定時(shí)比對(duì)數(shù)據(jù)。變更管理：分布式環(huán)境下的變更問(wèn)題也需要重視。節(jié)點(diǎn)變多了，數(shù)據(jù)庫(kù)拆散了，變更也就存在全局和單點(diǎn)的維度。如何統(tǒng)一變更保證集群所有機(jī)器都完成而沒有遺漏？是不是所有的節(jié)點(diǎn)都變更了？能不能通過(guò)定時(shí)參數(shù)比對(duì)等方式提示參數(shù)不一樣的節(jié)點(diǎn)？容災(zāi)方案：分布式數(shù)據(jù)庫(kù)的災(zāi)備方案該怎么做？?jī)?/p>

24、地三中心采用什么方式實(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)。多租戶管理：多租戶管理是分布式數(shù)據(jù)庫(kù)環(huán)境需要解決的重要功能。運(yùn)維人員需要把相應(yīng)的產(chǎn)品方案用起來(lái)，并且在運(yùn)維的過(guò)程中關(guān)注租戶的容量和性能需求，并相應(yīng)調(diào)整數(shù)據(jù)庫(kù)。2. 如何管理好分布式數(shù)據(jù)庫(kù)分布式數(shù)據(jù)庫(kù)作為新的技術(shù)，并不是脫胎于成熟的商業(yè)數(shù)據(jù)庫(kù)，因此還有很多粗糙的地方。尤其是金融行業(yè)的用戶，被傳統(tǒng)商業(yè)數(shù)據(jù)庫(kù)“嬌生慣養(yǎng)”，首次接觸到新生數(shù)據(jù)庫(kù)的時(shí)候，會(huì)有四處碰壁的感覺。但是即便是硬骨頭，還是得啃?？刂茟?yīng)用場(chǎng)景：分布式

25、不是萬(wàn)能的，它是面向特殊場(chǎng)景的數(shù)據(jù)庫(kù)產(chǎn)品。只有符合的交易才能往上遷移。如果不想自己麻煩，那就別麻煩分布式數(shù)據(jù)庫(kù)了。這個(gè)要求運(yùn)維人員不僅僅在看產(chǎn)品，還需要與業(yè)務(wù)人員和開發(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ù)集群的用戶可能要輕松一些，因?yàn)檫@些產(chǎn)品可能有相應(yīng)的產(chǎn)品級(jí)解決方案。而采用了分布式中間件的用戶，如何還能隨時(shí)查詢和透視數(shù)據(jù)表的關(guān)系，這是需要另尋方案的。不管是何種方式，這些都是分布式數(shù)據(jù)庫(kù)運(yùn)維需要做好的事情

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