王曉燕

摘要： 分布式數(shù)據(jù)庫提供更加強(qiáng)大的并發(fā)處理能力、更好的資源擴(kuò)展性以及架構(gòu)彈性，近年來被廣泛應(yīng)用于商業(yè)領(lǐng)域。本文通過對(duì)分布式數(shù)據(jù)庫的深入研究以及多種部署方案的對(duì)比分析，提出適用于某企業(yè)互聯(lián)網(wǎng)數(shù)據(jù)平臺(tái)的數(shù)據(jù)部署方案。

關(guān)鍵詞： 分布式數(shù)據(jù)庫； 集中式數(shù)據(jù)庫； 共享數(shù)據(jù)庫集群； 非共享數(shù)據(jù)庫集群

中圖分類號(hào)：TP392

文獻(xiàn)標(biāo)志碼：A

文章編號(hào)：2095-2163（2017）04-0056-04

0引言

近年來，隨著互聯(lián)網(wǎng)企業(yè)的快速發(fā)展，分布式數(shù)據(jù)庫系統(tǒng)已廣泛應(yīng)用于商業(yè)領(lǐng)域。較之傳統(tǒng)的集中式數(shù)據(jù)庫架構(gòu)，其性能優(yōu)勢在于能夠提供更為強(qiáng)大的并發(fā)處理能力、更為優(yōu)質(zhì)的資源擴(kuò)展性和架構(gòu)彈性，但卻在數(shù)據(jù)一致性方面略弱于集中式數(shù)據(jù)庫。業(yè)界較為流行的分布式數(shù)據(jù)庫架構(gòu)主要分為4種：多活共享數(shù)據(jù)庫集群、大規(guī)模平行處理數(shù)據(jù)庫（MPP）、分布式數(shù)據(jù)文件處理系統(tǒng)（典型產(chǎn)品Hadoop）和基于數(shù)據(jù)中間件調(diào)度管理的非共享數(shù)據(jù)庫集群[1]。其中，多活共享數(shù)據(jù)庫集群和基于數(shù)據(jù)中間件調(diào)度管理的非共享數(shù)據(jù)庫集群更適用于面向客戶交易的應(yīng)用場景，而其它2種架構(gòu)則主要適用于大數(shù)據(jù)分析的應(yīng)用領(lǐng)域。

某企業(yè)在自身互聯(lián)網(wǎng)應(yīng)用平臺(tái)建設(shè)過程中，根據(jù)其金融行業(yè)背景及業(yè)務(wù)特點(diǎn)，并結(jié)合現(xiàn)有技術(shù)能力和管理水平，研發(fā)設(shè)計(jì)并實(shí)現(xiàn)了一種面向大型互聯(lián)網(wǎng)應(yīng)用平臺(tái)的基于多活共享數(shù)據(jù)庫集群和非共享數(shù)據(jù)庫集群相結(jié)合的分布式數(shù)據(jù)庫系統(tǒng)架構(gòu)。

1技術(shù)應(yīng)用簡介

目前業(yè)界成熟的多活共享數(shù)據(jù)庫集群主要通過Oracle RAC和DB2 pureScale兩種技術(shù)產(chǎn)品展開核心研究，并且僅在計(jì)算資源層面上研發(fā)獲得了分布式架構(gòu)，而在數(shù)據(jù)的邏輯結(jié)構(gòu)層面并未真正推行分布式設(shè)計(jì)?；跀?shù)據(jù)中間件調(diào)度管理的非共享數(shù)據(jù)庫集群的最佳實(shí)現(xiàn)是采用MyCAT中間件+MySQL數(shù)據(jù)庫組成的分布式集群。該架構(gòu)中，數(shù)據(jù)可被靈活地垂直拆分和水平切分，是真正意義上的分布式數(shù)據(jù)庫系統(tǒng)架構(gòu)，但卻也在一定程度上提升了與其相關(guān)的技術(shù)復(fù)雜度和管理復(fù)雜度。

國內(nèi)互聯(lián)網(wǎng)應(yīng)用平臺(tái)的案例中，大型互聯(lián)網(wǎng)公司出于對(duì)降低成本及技術(shù)發(fā)展自主可控等因素的考慮，更傾向于使用MySQL分布式數(shù)據(jù)庫技術(shù)方案。而金融企業(yè)考慮到開源數(shù)據(jù)庫產(chǎn)品的技術(shù)風(fēng)險(xiǎn)較大，自身技術(shù)研發(fā)和維護(hù)能力有限等因素，更傾向于使用由商用數(shù)據(jù)庫產(chǎn)品（Oracle、DB2等）構(gòu)建的分布式數(shù)據(jù)庫方案。但也有數(shù)家機(jī)構(gòu)技術(shù)理念頗顯前衛(wèi)，正嘗試在互聯(lián)網(wǎng)應(yīng)用平臺(tái)建設(shè)中使用開源技術(shù)及產(chǎn)品，并采取循序漸進(jìn)的穩(wěn)健策略，先在外圍應(yīng)用系統(tǒng)中使用，而隨著開源技術(shù)和產(chǎn)品成熟度提高及自身技術(shù)團(tuán)隊(duì)和能力建設(shè)的加強(qiáng)，則逐步向重要應(yīng)用系統(tǒng)形成有益拓展與推廣。

2產(chǎn)品選型分析

DB2 pureScale技術(shù)在近幾年才趨于成熟和商用，使用案例極少，容易在運(yùn)用時(shí)遭遇首發(fā)故障，需經(jīng)過市場和時(shí)間檢驗(yàn)。Oracle RAC技術(shù)問世已達(dá)十余年，且得到業(yè)界的普遍認(rèn)可，并在金融領(lǐng)域推出較多使用案例，因而呈現(xiàn)出頗高的技術(shù)成熟度。MySQL分布式數(shù)據(jù)庫架構(gòu)的靈活性和擴(kuò)展性均為較好，成本投入經(jīng)濟(jì)實(shí)惠，在超大規(guī)?；ヂ?lián)網(wǎng)應(yīng)用平臺(tái)案例中業(yè)已得到復(fù)雜交易和超高強(qiáng)度并發(fā)交易場景的實(shí)際檢驗(yàn)。

基于前述討論可知，綜合考慮到互聯(lián)網(wǎng)應(yīng)用領(lǐng)域的IT架構(gòu)特點(diǎn)、金融行業(yè)的風(fēng)險(xiǎn)要求，以及引入并掌握多種主流數(shù)據(jù)庫產(chǎn)品技術(shù)對(duì)企業(yè)未來發(fā)展提供更加靈活、更為多元化的IT服務(wù)能力則將具有可觀重大的現(xiàn)實(shí)意義。因而研究中摒棄傳統(tǒng)的“小型機(jī)+DB2數(shù)據(jù)庫”技術(shù)架構(gòu)，而是選擇更為開放的“X86服務(wù)器平臺(tái)+Oracle或MySQL數(shù)據(jù)庫”的技術(shù)路線。

3數(shù)據(jù)應(yīng)用場景分析

該企業(yè)數(shù)據(jù)應(yīng)用場景主要分為3類：前端交互應(yīng)用類數(shù)據(jù)、中端交易應(yīng)用類數(shù)據(jù)、后端賬務(wù)核算及平臺(tái)管控類數(shù)據(jù)。其中，前端交互應(yīng)用類數(shù)據(jù)主要包括：網(wǎng)銀、商戶、營銷活動(dòng)、交易推送等；該類數(shù)據(jù)不采用分庫分表設(shè)計(jì)思想，因此集中式數(shù)據(jù)庫設(shè)計(jì)可降低技術(shù)復(fù)雜度。而中端交易應(yīng)用類數(shù)據(jù)主要包括：賬戶、支付、產(chǎn)品、客戶等。該類數(shù)據(jù)采用分庫分表設(shè)計(jì)思想，旨在更好地滿足應(yīng)用產(chǎn)品及服務(wù)的快速部署和迭代的需求，故采用分布式數(shù)據(jù)庫設(shè)計(jì)將更為現(xiàn)實(shí)合理，可極大地提高數(shù)據(jù)拆分或整合的靈活性和擴(kuò)展性。后端核算及管控類數(shù)據(jù)主要包括賬務(wù)核算、平臺(tái)管理、平臺(tái)監(jiān)控等。核算賬務(wù)類數(shù)據(jù)對(duì)數(shù)據(jù)一致性要求極高，而平臺(tái)管理及監(jiān)控等數(shù)據(jù)的規(guī)模較小，無需采用分庫分表設(shè)計(jì)，故采用集中式數(shù)據(jù)庫結(jié)構(gòu)更為適合。

4數(shù)據(jù)庫系統(tǒng)設(shè)計(jì)目標(biāo)

針對(duì)互聯(lián)網(wǎng)應(yīng)用平臺(tái)的相關(guān)特性要求，對(duì)數(shù)據(jù)庫系統(tǒng)設(shè)計(jì)方案提出以下定制目標(biāo)[2]：

1）高可用性?；ヂ?lián)網(wǎng)應(yīng)用平臺(tái)數(shù)據(jù)庫系統(tǒng)應(yīng)在邏輯和物理層面提供良好的高可用性設(shè)計(jì)，確保設(shè)備硬件及數(shù)據(jù)邏輯副本具有多份冗余。

2）高并發(fā)處理能力?；ヂ?lián)網(wǎng)應(yīng)用平臺(tái)數(shù)據(jù)庫系統(tǒng)不但要具備正常日間交易的處理能力，還要能在特殊時(shí)段或秒殺場景下平穩(wěn)地應(yīng)對(duì)高并發(fā)交易量的沖擊。

3）可擴(kuò)展性。互聯(lián)網(wǎng)應(yīng)用平臺(tái)數(shù)據(jù)庫系統(tǒng)能夠良好地適應(yīng)業(yè)務(wù)交易量的發(fā)展趨勢，在各種性能和容量資源方面都具有強(qiáng)大的可擴(kuò)展能力。

4）靈活性。針對(duì)應(yīng)用系統(tǒng)的快速迭代和變更，互聯(lián)網(wǎng)應(yīng)用平臺(tái)數(shù)據(jù)庫系統(tǒng)應(yīng)配備較強(qiáng)的部署靈活性。能夠較好地適應(yīng)數(shù)據(jù)拆分和整合的變化需求。

5）業(yè)務(wù)連續(xù)性?；ヂ?lián)網(wǎng)應(yīng)用平臺(tái)數(shù)據(jù)庫系統(tǒng)應(yīng)形成較強(qiáng)的容災(zāi)能力，能夠在人為和自然災(zāi)害發(fā)生后盡快恢復(fù)系統(tǒng)服務(wù)狀態(tài)，盡可能降低數(shù)據(jù)丟失量和影響范圍，同時(shí)符合數(shù)據(jù)安全要求的關(guān)鍵性指標(biāo)也可得到有效控制與保障。

5數(shù)據(jù)庫系統(tǒng)技術(shù)方案

為滿足互聯(lián)網(wǎng)應(yīng)用平臺(tái)數(shù)據(jù)庫系統(tǒng)的設(shè)計(jì)目標(biāo)要求，提出3種技術(shù)方案。在此，給出研究論述如下。

5.1A方案

A方案基于Oracle RAC的數(shù)據(jù)庫雙活集群設(shè)計(jì)思想，全部采用高端4路X86機(jī)架式服務(wù)器，根據(jù)不同應(yīng)用需求建立4組Oracle RAC數(shù)據(jù)庫雙活集群，每組集群由2臺(tái)物理服務(wù)器組成。利用Oracle RAC技術(shù)實(shí)現(xiàn)本地高可用和性能負(fù)載均衡。endprint

集群A部署的數(shù)據(jù)庫包括：網(wǎng)銀、商戶、營銷活動(dòng)、交易推送等；集群B部署的數(shù)據(jù)庫包括：賬戶和支付；集群C部署的數(shù)據(jù)庫包括：產(chǎn)品和客戶；集群D部署的數(shù)據(jù)庫包括：賬務(wù)核算、平臺(tái)管理、平臺(tái)監(jiān)控等。研究中，A方案部署結(jié)構(gòu)設(shè)計(jì)如圖1所示。

隨著業(yè)務(wù)發(fā)展和性能需要，可將數(shù)據(jù)庫集群規(guī)模由2個(gè)節(jié)點(diǎn)在線擴(kuò)充至4個(gè)節(jié)點(diǎn)。在集群B和C部署的數(shù)據(jù)庫，可通過新建RAC集群B′和C′實(shí)現(xiàn)數(shù)據(jù)模塊的水平拆分。數(shù)據(jù)庫內(nèi)部的表可通過分片設(shè)計(jì)以提高數(shù)據(jù)結(jié)構(gòu)的使用性能和容量。

數(shù)據(jù)庫的文件和數(shù)據(jù)全部存放在外接共享存儲(chǔ)陣列上，并利用存儲(chǔ)底層遠(yuǎn)程復(fù)制技術(shù)實(shí)現(xiàn)數(shù)據(jù)容災(zāi)。若未來需要建立異地容災(zāi)環(huán)境，則采用Oracle ADG技術(shù)將主生產(chǎn)中心的數(shù)據(jù)異步復(fù)制到異地容災(zāi)環(huán)境。

5.2B方案

B方案基于Oracle RAC和MySQL的數(shù)據(jù)庫混合架構(gòu)設(shè)計(jì)思想，主要采用2種硬件架構(gòu)的服務(wù)器類型：部署Oracle RAC集群的服務(wù)器采用高端4路X86機(jī)架式服務(wù)器，其結(jié)構(gòu)與A方案類似；部署MySQL數(shù)據(jù)庫的服務(wù)器采用中端2路X86機(jī)架式服務(wù)器。利用MySQL主從復(fù)制技術(shù)實(shí)現(xiàn)高可用集群[3]，同時(shí)給每個(gè)集群配備一個(gè)準(zhǔn)同步復(fù)制的只讀數(shù)據(jù)庫，通過讀寫分離模式提高性能負(fù)載。

Oracle RAC集群A部署企業(yè)網(wǎng)銀、商戶、營銷活動(dòng)、交易推送等數(shù)據(jù)庫；RAC集群B部署核算、平臺(tái)管理、監(jiān)控等數(shù)據(jù)庫；建立2組MySQL高可用集群分別部署賬戶、支付和產(chǎn)品、客戶等數(shù)據(jù)庫。

隨著業(yè)務(wù)增長及性能要求不斷提高，可對(duì)后端交易類應(yīng)用的數(shù)據(jù)庫進(jìn)行多節(jié)點(diǎn)水平切分來構(gòu)建數(shù)據(jù)模塊的分拆部署，提高數(shù)據(jù)庫的整體性能。數(shù)據(jù)庫內(nèi)部的表可通過分片設(shè)計(jì)提高數(shù)據(jù)結(jié)構(gòu)的使用性能和容量。

數(shù)據(jù)庫的存儲(chǔ)可以采選2種處理模式。其中，Oracle RAC數(shù)據(jù)庫集群的數(shù)據(jù)文件存放于外接共享存儲(chǔ)陣列；MySQL數(shù)據(jù)庫是將數(shù)據(jù)文件存放于數(shù)據(jù)庫服務(wù)器的內(nèi)置硬盤（SSD硬盤或閃存卡，滿足數(shù)據(jù)庫高讀寫性能要求），并利用RAID10對(duì)其進(jìn)行數(shù)據(jù)保護(hù)和性能提升。采用內(nèi)置硬盤的存儲(chǔ)方案不受制于共享式存儲(chǔ)陣列和SAN資源承載能力以及空間束縛，能夠更為快速、靈活地?cái)U(kuò)充數(shù)據(jù)庫服務(wù)器節(jié)點(diǎn)。

容災(zāi)方面，Oracle RAC集群將利用存儲(chǔ)底層遠(yuǎn)程復(fù)制技術(shù)實(shí)現(xiàn)容災(zāi)。而MySQL分布式數(shù)據(jù)庫的主從復(fù)制技術(shù)無法實(shí)時(shí)同步復(fù)制，不能保證數(shù)據(jù)零丟失，因此普遍采用的容災(zāi)策略是盡量把數(shù)據(jù)模塊縮小、打散，并選擇多站點(diǎn)部署（3個(gè)及以上）。該策略可使MySQL數(shù)據(jù)庫極大地降低對(duì)容災(zāi)環(huán)境的依賴，由容災(zāi)架構(gòu)變?yōu)榉植际蕉嗷罴軜?gòu)，嚴(yán)格控制故障和災(zāi)難對(duì)數(shù)據(jù)的影響范圍，減少數(shù)據(jù)丟失量。

因此，B設(shè)計(jì)方案是將交易類應(yīng)用的數(shù)據(jù)庫橫向拆分成2個(gè)數(shù)據(jù)單元，每個(gè)單元均包含相互關(guān)聯(lián)的賬戶、支付、產(chǎn)品、客戶信息。將2個(gè)數(shù)據(jù)單元分別部署在主生產(chǎn)中心和同城災(zāi)備中心，通過數(shù)據(jù)庫主從異步復(fù)制技術(shù)（RPO>>0）在對(duì)端建立容災(zāi)數(shù)據(jù)庫環(huán)境；若網(wǎng)絡(luò)資源存在局限性而難以達(dá)成跨站點(diǎn)部署，可先將MySQL高可用集群全部部署于主生產(chǎn)中心，同城災(zāi)備中心僅存放異步復(fù)制的數(shù)據(jù)庫容災(zāi)環(huán)境，設(shè)計(jì)不足即是將會(huì)產(chǎn)生大量數(shù)據(jù)丟失。未來須通過機(jī)房環(huán)境和網(wǎng)絡(luò)資源的改善，逐步實(shí)現(xiàn)跨更多站點(diǎn)的分布式部署架構(gòu)。也可將數(shù)據(jù)庫文件存放在外接共享存儲(chǔ)陣列，利用SRDF技術(shù)實(shí)現(xiàn)數(shù)據(jù)同步復(fù)制的同城災(zāi)備中心，確保數(shù)據(jù)零丟失，但在一定程度上卻會(huì)降低數(shù)據(jù)庫部署的靈活性。

研究中，B方案部署結(jié)構(gòu)設(shè)計(jì)則如圖2所示。

5.3C方案

C方案基于Oracle多種技術(shù)結(jié)合的數(shù)據(jù)庫架構(gòu)設(shè)計(jì)思想。在服務(wù)器選型方面，采用2種硬件架構(gòu)的服務(wù)器類型：部署Oracle RAC集群的服務(wù)器采用高端4路X86機(jī)架式服務(wù)器，其結(jié)構(gòu)與A方案類似；部署Oracle ADG高可用數(shù)據(jù)庫集群的服務(wù)器采用中端2路X86機(jī)架式服務(wù)器。高可用集群內(nèi)部節(jié)點(diǎn)之間采用數(shù)據(jù)同步復(fù)制技術(shù)確保本地?cái)?shù)據(jù)零丟失，并通過讀寫分離提高性能負(fù)載。

Oracle RAC集群A部署企業(yè)網(wǎng)銀、商戶、營銷活動(dòng)、交易推送等數(shù)據(jù)庫；RAC集群B部署核算、平臺(tái)管理、監(jiān)控等數(shù)據(jù)庫；建立4個(gè)Oracle ADG高可用集群分別部署后端交易類應(yīng)用的賬戶、支付、產(chǎn)品、客戶等數(shù)據(jù)庫；也可建立2個(gè)數(shù)據(jù)庫高可用集群，每個(gè)集群分別部署2個(gè)數(shù)據(jù)庫，需要根據(jù)非功能測試和驗(yàn)證后確定最終方案。

面對(duì)業(yè)務(wù)增長及性能要求的不斷提高，Oracle RAC集群可通過動(dòng)態(tài)擴(kuò)充節(jié)點(diǎn)來增強(qiáng)處理能力。而針對(duì)后端交易類應(yīng)用的數(shù)據(jù)庫，當(dāng)單個(gè)高可用集群資源性能不足時(shí)可快速建立一個(gè)新集群，將數(shù)據(jù)庫水平切分為若干數(shù)據(jù)模塊，部分遷移至新建集群，達(dá)到提高該數(shù)據(jù)庫整體性能的研究效果；數(shù)據(jù)庫內(nèi)部的表可通過分片設(shè)計(jì)改進(jìn)數(shù)據(jù)結(jié)構(gòu)的使用性能和容量。若某個(gè)數(shù)據(jù)庫需要提升讀操作性能，可利用ADG技術(shù)為該數(shù)據(jù)庫實(shí)例建立2個(gè)只讀副本。

數(shù)據(jù)庫的數(shù)據(jù)文件都存放在外接共享存儲(chǔ)陣列上，并通過存儲(chǔ)底層遠(yuǎn)程復(fù)制技術(shù)實(shí)現(xiàn)數(shù)據(jù)的同城容災(zāi)。未來機(jī)房環(huán)境、網(wǎng)絡(luò)資源及存儲(chǔ)資源滿足條件時(shí)，可借鑒B方案將容災(zāi)架構(gòu)調(diào)整為跨站點(diǎn)多活架構(gòu)。

研究中，C方案部署結(jié)構(gòu)設(shè)計(jì)即如圖3所示。

6結(jié)束語

面對(duì)開源數(shù)據(jù)庫技術(shù)的互聯(lián)網(wǎng)應(yīng)用正進(jìn)入普遍優(yōu)化實(shí)施的潮流趨勢下，企業(yè)的互聯(lián)網(wǎng)應(yīng)用平臺(tái)的項(xiàng)目建設(shè)既要注重相關(guān)技術(shù)產(chǎn)品的安全穩(wěn)定運(yùn)行，更重要的是客觀理性地認(rèn)識(shí)到這種技術(shù)趨勢在其自身良好發(fā)展背景下所體現(xiàn)出的合理性和必然性。因此，綜合考慮技術(shù)發(fā)展、方案可行性、應(yīng)用適配[CM（26]性、成本投入、運(yùn)維管理及自身發(fā)展等諸多方面因素，最終選擇基于Oracle RAC雙活集群和MySQL分布式集群相結(jié)合的方案B作為該企業(yè)互聯(lián)網(wǎng)應(yīng)用平臺(tái)的數(shù)據(jù)庫系統(tǒng)技術(shù)方案?；ヂ?lián)網(wǎng)應(yīng)用平臺(tái)的數(shù)據(jù)庫系統(tǒng)建設(shè)是一個(gè)非常復(fù)雜、龐大的項(xiàng)目，除了最為關(guān)鍵的架構(gòu)問題外，還有很多技術(shù)細(xì)節(jié)問題需要尋求有效解答。比如MySQL數(shù)據(jù)庫的分片方案、分布式SQL語句的編寫規(guī)范、分布式數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)遷移和運(yùn)維管理體系等。本文旨在討論互聯(lián)網(wǎng)應(yīng)用平臺(tái)數(shù)據(jù)庫系統(tǒng)架構(gòu)層面的設(shè)計(jì)與分析，其他技術(shù)問題仍有待在后續(xù)工作中展開重點(diǎn)深入的探討與研究。

參考文獻(xiàn)：

[1] 周英飚. 通用無共享數(shù)據(jù)庫集群研究與實(shí)現(xiàn)[J]. 計(jì)算機(jī)工程與應(yīng)用，2007，43（32）：156-160.

[2] 陳爭航. 分布式數(shù)據(jù)庫系統(tǒng)研究與應(yīng)用[D]. 成都：西南交通大學(xué)，2014.

[3] 陳冠華. 基于消息中間件的高可用MySQL集群的研究[D]. 武漢：華中科技大學(xué)，2007.

[4] 胡金柱，譚支鵬. 分布式對(duì)象數(shù)據(jù)庫系統(tǒng)中的對(duì)象管理策略[J].小型微型計(jì)算機(jī)系統(tǒng)，2001，22（1）：96-99.

[5] 戴婉榮. 基于分布式數(shù)據(jù)庫的數(shù)據(jù)同步機(jī)制的研究與應(yīng)用[D]. 武漢：武漢理工大學(xué)，2010.

[6] 蘇燕強(qiáng). Oracle分布式數(shù)據(jù)庫及其應(yīng)用研究[J]. 計(jì)算機(jī)應(yīng)用與軟件，2004，21（8）：36-37，121.

[7] 陳珉喻，喻丹丹，徐國慶. 分布式數(shù)據(jù)庫系統(tǒng)中數(shù)據(jù)一致性維護(hù)方法研究[J]. 國防科技大學(xué)學(xué)報(bào)，2002，24（3）：76-80.endprint