本文根據(jù)于樹文老師在〖deeplus直播第231期〗線上分享演講內(nèi)容整理而成。

于樹文

光大銀行資深DBA

• 目前在中國光大銀行信息科技部數(shù)據(jù)庫管理團隊主要負(fù)責(zé)分布式數(shù)據(jù)庫建設(shè)項目，推進(jìn)行內(nèi)技術(shù)架構(gòu)轉(zhuǎn)型等相關(guān)工作。

• 從事數(shù)據(jù)庫運維管理工作十余年，在數(shù)據(jù)庫的性能優(yōu)化，升級遷移，高可用容災(zāi)等方面具有豐富經(jīng)驗。

我今天分享的主題是《高并發(fā)場景下，光大銀行分布式數(shù)據(jù)庫的架構(gòu)轉(zhuǎn)型實戰(zhàn)》。

光大銀行也是很有魄力的，拿出了一個重要的業(yè)務(wù)系統(tǒng)進(jìn)行一次試點，做了一次這種分布式架構(gòu)轉(zhuǎn)型的項目。我有過十余年DBA相關(guān)的經(jīng)驗，不過之前接觸比較多的主要還是傳統(tǒng)的商用型數(shù)據(jù)庫，所以能作為這次項目的推進(jìn)人，也是我個人在這種新的架構(gòu)下的一次學(xué)習(xí)的過程。

一、光大云繳費平臺的基本情況

先給大家介紹一下今天分享的這個平臺情況，對于一些業(yè)務(wù)的數(shù)據(jù)概況。

這個系統(tǒng)上線當(dāng)初，是和其它的業(yè)務(wù)系統(tǒng)放在一起的。在2015年和2018年，考慮到業(yè)務(wù)和成本等多方面的因素，經(jīng)歷過兩次業(yè)務(wù)剝離，最終在18年成了一個單獨的平臺。

里面涉及的繳費種類包含20大類，其中有8000余個繳費的項目，接近500個繳費渠道，目前覆蓋國內(nèi)300+城市。平時大家生活中使用比較多的像水費、電費、生活費的繳納，可能都是通過這個平臺來完成的。目前，它已經(jīng)被打造成為行內(nèi)TPS最高的業(yè)務(wù)系統(tǒng)：

上圖的這些數(shù)據(jù)，可以看出從18年5月開始，交費平臺的各項數(shù)據(jù)有大幅度的增長，有的甚至是翻倍的增長。這些指標(biāo)可以作為衡量一個業(yè)務(wù)系統(tǒng)是否有健康良好發(fā)展趨勢的依據(jù)，但是轉(zhuǎn)到后臺，最終都代表著給數(shù)據(jù)庫的壓力是一個什么樣的變化。

二、傳統(tǒng)IOE架構(gòu)的基本優(yōu)化及面臨的挑戰(zhàn)

目前數(shù)據(jù)庫傳統(tǒng)的IOE架構(gòu)包括云繳費系統(tǒng)，它用的也是這種傳統(tǒng)的IOE架構(gòu)，在部署模式上是采用的雙中心RAC 2+2的冷備部署：

• 數(shù)據(jù)一致性是通過存儲復(fù)制技術(shù)來保證的：這個相對來講，光大用的時間也比較長，而且也證明了這種數(shù)據(jù)一致性保護(hù)機制是比較可靠的。

• 高可用是通過RAC自身特性以及一些第三方軟件來提供的：不得不說，Oracle還是有它的獨到之處的，不然也不會在各個領(lǐng)域都能有比較高的占有率。

• 產(chǎn)品及架構(gòu)設(shè)計是比較成熟的，運行穩(wěn)定性比較高：之前，云繳費平臺在這上面運行了十幾年，基本上沒有出過什么問題。所以這種傳統(tǒng)的IOE架構(gòu)確實是有它自身的優(yōu)勢。

在這種傳統(tǒng)的IOE架構(gòu)下，我們通常會做到一些優(yōu)化，大致如下：

• 索引、統(tǒng)計信息優(yōu)化：目的是讓它走最好、最穩(wěn)定的執(zhí)行計劃。

• 表分區(qū)改造：通過hash、range，或是兩層分區(qū)，打散IO消耗。

• 拆分存儲端口：data及redo端口隔離，避免端口混用時的壓力影響導(dǎo)致提交慢。

• 硬件迭代：性能、容量提升。

其實做了這么多的優(yōu)化，包括還有很多其它的優(yōu)化，主要目的都是為了減少IO請求，通過物理設(shè)備的性能提升來保障業(yè)務(wù)能有一個穩(wěn)定、快速的交易響應(yīng)時間。

但是，這些可能都是只對讀IO有作用的，也就是通過盡量減少它的物理讀及buffer讀，來提升業(yè)務(wù)TPS，并降低ART。但是對于寫來說，主要是由業(yè)務(wù)需求決定的，所以從數(shù)據(jù)庫層面，至少從這種傳統(tǒng)的架構(gòu)層面是優(yōu)化不掉的，因為這個是它業(yè)務(wù)傳導(dǎo)過來的一個最基本的寫的指標(biāo)。

所以我們總結(jié)了一下，在傳統(tǒng)的架構(gòu)下，會面臨這樣的一些挑戰(zhàn)：

• 處理能力受存儲性能、熱點資源制約：高業(yè)務(wù)壓力下，集中式存儲資源性能受限，熱點資源、空間分配等沖突嚴(yán)重。因為這種高并發(fā)的業(yè)務(wù)，在壓力下，集中式存儲，可以說是一個單點吧，它的資源性能是受到一定限制的。像IOE用到了Oracle的RAC，倒也不是不能擴展，主要是它擴展不方便，而且擴展來擴展去就是加機器，CPU、內(nèi)容都得到擴展了，但實際下面對的還是一個存儲。所以可能最終IO會成為一個熱點，一個壓力的瓶頸。

• 部署集中導(dǎo)致風(fēng)險集中，變更維護(hù)窗口壓縮：一旦出現(xiàn)軟件產(chǎn)品缺陷、硬件損壞等故障時，所有的交易都會受影響，或者是變更維護(hù)操作，如果說需要停機的話，需要整個停下來才能變更（比如說打個補丁，或者是有些不能動態(tài)修改的參數(shù)之類的），都會影響系統(tǒng)全部交易。

• 跨數(shù)據(jù)庫中心多活部署：對于傳統(tǒng)數(shù)據(jù)庫來說，這種部署模式也非常困難?？赡苤挥型ㄟ^分布式的引入，才能提升多活部署的可能、提升可用性、加快切換速度，突破特性軟硬件的成本和性能限制。

• 數(shù)據(jù)庫產(chǎn)品多樣化：之前去“IOE”這個詞也說了挺久了，畢竟還是有很多形勢上的變化，所以在商業(yè)化的產(chǎn)品上，可能會存在一些供應(yīng)鏈的風(fēng)險。那么通過多樣化的選擇，可能會減少這方面的風(fēng)險，同時也給我們更多部署上的選擇。

三、光大的分布式數(shù)據(jù)庫技術(shù)調(diào)研及思考

所以光大銀行對分布式數(shù)據(jù)庫的技術(shù)做了一些相關(guān)調(diào)研。

對于數(shù)據(jù)庫來講，其實它的核心其實就是SQL解析、事務(wù)控制和數(shù)據(jù)存儲與訪問。像數(shù)據(jù)復(fù)制、備份恢復(fù)、可用性切換、數(shù)據(jù)遷移、操作調(diào)度、開發(fā)接口、權(quán)限管理、對象管理、監(jiān)控報警等等，這些都是它整個的一個生態(tài)。這些工具有沒有、高不高效，就決定了運維的工作能不能更好的開展。

所以，分布式數(shù)據(jù)庫其實就是將傳統(tǒng)數(shù)據(jù)庫的各技術(shù)組件通過松耦合的方式部署，通過網(wǎng)絡(luò)之間，會有一個相互的協(xié)同工作，達(dá)到分散壓力，提升總體處理能力的目的。也就是把我原來的瓶頸打散了。

但是被打散之后，各個組件之間可能網(wǎng)絡(luò)通訊成本就增加了，所以在提升總體交易吞吐量的同時，平均的響應(yīng)時間也就是ART可能就會增加。拿云繳費這個系統(tǒng)來說，我們測試的時候發(fā)現(xiàn)原來二十幾毫秒的交易，到分布式上可能就會多個十幾毫秒，或者再長一點的時間，主要整體是受到一個鏈路的影響。所以分布式并不能減少交易響應(yīng)時間，但可以通過它的擴展性，帶來交易響應(yīng)時間的穩(wěn)定。

那為什么我們的測試發(fā)現(xiàn)在分布式上交易響應(yīng)時間變長了呢？主要是因為原來的數(shù)據(jù)庫還沒達(dá)到瓶頸。等到原來這種傳統(tǒng)架構(gòu)的數(shù)據(jù)庫達(dá)到一個性能瓶頸，出現(xiàn)性能拐點，那時候一定會出現(xiàn)一個大幅度的性能抖動或者滑坡。但是在分布式架構(gòu)下，我們就可以通過它橫向的擴展能力，讓平均響應(yīng)時間基本維持在恒定的一條線上。

目前，分布式部署技術(shù)很多企業(yè)都在用，但切入點是不一樣的，而且也形成了多種技術(shù)路線，并且這幾種路線，從我們的調(diào)研來看，也都在不斷地演進(jìn)。

我們的分布式數(shù)據(jù)庫技術(shù)調(diào)研發(fā)現(xiàn)，基本上可以分為三類：

1）應(yīng)用層分布式架構(gòu)

主要是通過應(yīng)用架構(gòu)的設(shè)計，將業(yè)務(wù)數(shù)據(jù)分散到多個數(shù)據(jù)庫存儲。

這個其實也算是一種單元化吧，所以這層主要的核心是在于對進(jìn)來的交易做一次解析，然后在交易通過應(yīng)用層之后，解析完成了，它知道自己該去哪個數(shù)據(jù)庫，去訪問哪些數(shù)據(jù)。

2）NewSQL分布式數(shù)據(jù)庫

數(shù)據(jù)以物理分片的方式，把數(shù)據(jù)打散，分散到若干個存儲節(jié)點。它是在存儲層實現(xiàn)分布式的數(shù)據(jù)掃描和過濾。

3）數(shù)據(jù)庫訪問代理中間件

最早像tomcat，也算是一個分布式中間件。這種通常都是選擇恰當(dāng)?shù)姆制I，通過分片鍵來將數(shù)據(jù)打散，然后在應(yīng)用訪問代理的時候，將SQL按照它的分片規(guī)則做一次解析，解析完成后，來實現(xiàn)對各個分片進(jìn)行單獨訪問。也就是說，相當(dāng)于是做了個SQL的拆分，由它路由到我指定的數(shù)據(jù)庫上，訪問指定的數(shù)據(jù)。

這是目前常見的幾種分布式數(shù)據(jù)庫的技術(shù)路線。

接下來我們總結(jié)和整合一下：

第一個是分布式應(yīng)用架構(gòu)層面。目前在分布式數(shù)據(jù)庫應(yīng)用架構(gòu)的路線上，就是做的分庫分表，一般都是產(chǎn)品/廠商自建的。因為這種一般都比其它的與應(yīng)用的業(yè)務(wù)特點，結(jié)合的是更加緊密的。對于單系統(tǒng)來說，它單獨地進(jìn)行了一些分析，對業(yè)務(wù)進(jìn)行了一些拆分，效果是比較突出的，但這種模式不容易推廣，因為一旦做一個系統(tǒng)，就需要對系統(tǒng)所有的交易、數(shù)據(jù)庫的設(shè)計、表之類的重新梳理一次，比較費時間。不過效果確實很明顯，目前這么做的系統(tǒng)也不少。

第二個是分布式代理中間件。主要是通過分布式代理中間件，在一定程度上實現(xiàn)了自動化的分庫分表。實際上就是按照分片鍵的規(guī)則將數(shù)據(jù)拆分了，由它來進(jìn)行分庫分表的操作。所以這個性能還是跟應(yīng)用設(shè)計有很大關(guān)系的，如果大表找不到合適的分片鍵的話，用這種數(shù)據(jù)庫可能就達(dá)不到預(yù)期的效果。所以這類我們覺得是可以作為分布式應(yīng)用架構(gòu)的一種比較好的補充。

第三類就是NewSQL分布式。這類的性能擴展對應(yīng)用相對透明，但是這些產(chǎn)品出來的時間相對來說都不是很長，還在演進(jìn)中，開發(fā)接口等方面可能就存在一些限制，并沒有前兩種分布式的架構(gòu)那么靈活。

四、光大自研的分布式數(shù)據(jù)庫EverDB

光大結(jié)合調(diào)研結(jié)果，采取了兩個技術(shù)路線：一個是NewSQL的引入，一個是想要自研一個分布式數(shù)據(jù)庫，也就是EverDB。

EverDB有三個主要的組件：

• EDB-grid：數(shù)據(jù)庫訪問代理組件，具有SQL路由、數(shù)據(jù)分片、故障轉(zhuǎn)移等功能并對應(yīng)用實現(xiàn)協(xié)議透明。（所以一個SQL進(jìn)來，通過這層之后，解析完成就會告訴你你的數(shù)據(jù)在下面的某個MySQL集群上；同時分片完成之后，你也不需要關(guān)心數(shù)據(jù)是存在哪個MySQL庫、哪個實例里，只要過了這層，就會自動地路由過去）。

• EDB-bridge：數(shù)據(jù)庫復(fù)制和校驗組件，負(fù)責(zé)逃離數(shù)據(jù)庫異地災(zāi)備的數(shù)據(jù)庫同步和同步數(shù)據(jù)校驗。（從上圖也可以看出，它是通過bridge復(fù)制了一個逃離數(shù)據(jù)庫的，因為畢竟像這種新的技術(shù)引用，是伴隨著一定的風(fēng)險的，尤其是繳費這種系統(tǒng)，也是比較重要。所以當(dāng)時的考慮是，通過bridge復(fù)制出來的數(shù)據(jù)庫，當(dāng)核心組件，也就是grid出現(xiàn)問題的時候，我可以通過應(yīng)用的配置調(diào)整，讓它跨過中間的所有節(jié)點，直連逃離數(shù)據(jù)庫，在一定程度上快速恢復(fù)業(yè)務(wù)。這個組件主要就是承擔(dān)這個作用）。

• EDB-control：分布式數(shù)據(jù)庫管理平臺，對集群中各個功能節(jié)點及數(shù)據(jù)節(jié)點進(jìn)行監(jiān)管。有點類似Oracle的Grid control。

然后數(shù)據(jù)庫實際上用的就是MySQL集群。數(shù)據(jù)節(jié)點采用的就是MySQL數(shù)據(jù)庫，對部署模式?jīng)]有什么限制，支持多種部署模式。

1）數(shù)據(jù)分片

• 目前支持Hash、Mod、Range、List等分片規(guī)則，分片功能對應(yīng)用透明，應(yīng)用訪問數(shù)據(jù)不需要額外加什么條件。

• 分片數(shù)量需提前規(guī)劃，目前不支持在線調(diào)整。（也就是說如果我一開始將數(shù)據(jù)分了32個片，然后底下部署了比如說8個MySQL集群，這樣的話，實際上每個MySQL集群里是有4片數(shù)據(jù)的。這時如果我想要重新做分片的話，這些數(shù)據(jù)是需要重新導(dǎo)一遍，才能改分片數(shù)量的。所以分片數(shù)量初期的規(guī)劃就比較重要，而且和后續(xù)業(yè)務(wù)的增長趨勢的預(yù)估以及我相關(guān)節(jié)點的擴容計劃是有關(guān)系的。因為像前面提到的32個分片，假設(shè)我后端的數(shù)據(jù)庫擴展到32個MySQL集群的時候，那實際上每個集群里只有1片數(shù)據(jù)了，這個時候再想擴就擴不了了，只能是重新加分片，那就會涉及到數(shù)據(jù)遷移）。

2）數(shù)據(jù)存儲

• MySQL數(shù)據(jù)源支持主從半同步、MGR等多種部署方式，其中主從半同步方式至少每個機房可存在一個強一致節(jié)點，從而保證跨機房切換RPO為0。（不然的話，如果只是速度快，將近地/同機房的數(shù)據(jù)同步完了，跨機房的沒有管，一旦發(fā)生宕機、網(wǎng)絡(luò)故障時，切換過去就有可能是舊數(shù)據(jù)了。所以這塊兒可能也算是網(wǎng)絡(luò)上增加成本開銷的原因，因為畢竟是要等一個跨機房的同步。相對而言，金融行業(yè)對數(shù)據(jù)一致性的要求是比較高的，所以是不允許出現(xiàn)數(shù)據(jù)丟失的情況）。

3）橫向擴展

• 計算節(jié)點EDB-grid支持橫向動態(tài)擴展，擴展過程對集群無任何影響，是比較透明的。也就是說，grid直接動態(tài)增加就可以了，通過前端的F5配置，應(yīng)用配到F5那層之后，F(xiàn)5會自動相應(yīng)的轉(zhuǎn)發(fā)到新的節(jié)點上來。

• 數(shù)據(jù)節(jié)點分為物理設(shè)備擴展及數(shù)據(jù)庫實例擴展，兩個達(dá)到的目的是不一樣的：

• 一個是可以稀釋實例分布（因為畢竟也是考慮到成本，有可能物理設(shè)備是復(fù)用的，會存在一個物理機上跑著一個MySQL集群的主，同時還跑著別的集群的從實例，所以通過這種物理設(shè)備的擴展，可以通過切換并移動MySQL的實例，來減少物理設(shè)備的容量壓力）。

• 另一個是可以稀釋數(shù)據(jù)分片（實例數(shù)量的擴展，會涉及到分片數(shù)據(jù)的在線移動。這個經(jīng)過我們的測試，發(fā)現(xiàn)其實會對局部的交易會產(chǎn)生一定的影響）。

4）遷移備份

• 通過DataX工具實現(xiàn)異構(gòu)分批次遷移數(shù)據(jù)，這個也是在云繳費平臺從傳統(tǒng)的Oracle到EverDB的過程中所采用的方式，并在這個過程中完成了字符集轉(zhuǎn)換。像原來Oracle的字符集可能有一些與MySQL不太一致的地方，可以通過這種文本落地的方式，把這個轉(zhuǎn)換完成。像這種系統(tǒng)數(shù)據(jù)量比較大，我們在遷移的過程當(dāng)中也做了一些批次的拆分，有一些不變的例數(shù)據(jù)，可以提前進(jìn)行遷移，其實在真正實施的當(dāng)天，遷移的數(shù)據(jù)是很少量的一部分。

• 數(shù)據(jù)備份為分集群整體備份以及單庫備份，并支持額外的備份網(wǎng)絡(luò)。畢竟這種分布式架構(gòu)本身對網(wǎng)絡(luò)的依賴度就非常高，如果要是與業(yè)務(wù)或者節(jié)點之間的通信采用同一個網(wǎng)絡(luò)的話，備份是有很大可能會干擾正常的業(yè)務(wù)的。集群整體備份這塊兒，其實是備的完整的集群拓?fù)洌€原出來的其實也是一個完整的集群拓?fù)?；單庫備份是一個邏輯備份，可以實現(xiàn)相對來說靈活一點的數(shù)據(jù)恢復(fù)。

5）開發(fā)應(yīng)用

• 支持分布式事務(wù)。

• 支持事務(wù)、悲觀鎖以及全部隔離級別。

• 支持絕大部分MySQL語法（不是全支持，像我印象中，有一些像left join之類的支持程度是有限的，因為畢竟它的解析是靠grid來完成的，所以它的語法在這層的邏輯實現(xiàn)上是有一定的限制的）。

• 有限支持函數(shù)（min、max、count、sun、avg），視圖（只可進(jìn)行select操作，不能做update操作），過程（過程內(nèi)不支持函數(shù)調(diào)用）。

• 不支持觸發(fā)器、定時任務(wù)、臨時表。

所以在開發(fā)上面，可能確實和原生的MySQL是有一定的區(qū)別的，但是已經(jīng)可以滿足我們目前大部分的應(yīng)用邏輯設(shè)計的需求了。

在整個改造的過程當(dāng)中，數(shù)據(jù)庫測試算是我們的一個重點工作，主要集中在兩方面：

1）測試場景設(shè)計

這次數(shù)據(jù)的遷移改造，我們一共設(shè)計了30余個測試場景，其中主要包括：

• 各功能節(jié)點的故障切換（因為相對傳統(tǒng)的架構(gòu)來說，雖然不集中了，但是功能節(jié)點變多了。同時也擺脫了傳統(tǒng)的小機，因為現(xiàn)在用的都是X86的服務(wù)器了，所以它硬件的故障率可能是有一定上升的，所以我們模擬了每個功能節(jié)點的故障）。

• 節(jié)點間網(wǎng)絡(luò)故障（因為網(wǎng)絡(luò)整個的交易鏈路比原來的長了很多，所以跨機房或者是網(wǎng)卡的網(wǎng)絡(luò)故障都有可能發(fā)生）。

• 集群動態(tài)擴容（也是比較體現(xiàn)分布式數(shù)據(jù)庫優(yōu)勢的）。

• 不同背景壓力對聯(lián)機交易的影響（因為大部分系統(tǒng)還是有批量業(yè)務(wù)的，就會涉及到一些大的事務(wù)的處理，所以我們對于這種背景壓力對于聯(lián)機的影響也是比較關(guān)注的）。

• 極端情況下的備份恢復(fù)（比如說集群完全不能對外停服，或者是各個不同的節(jié)點crash之類的）。

• MGR/MS對比（一開始我們挺傾向于使用MGR的這個架構(gòu)的，畢竟它也是MySQL原生出的集群模式。但是經(jīng)過測試對比，發(fā)現(xiàn)還是主從半同步的效率高一些，而且現(xiàn)在MGR確實技術(shù)還不是很成熟和穩(wěn)定，所以我們最后部署上是選擇了主從半同步）。

2）測試關(guān)注的指標(biāo)

• 各故障場景的影響范圍（因為畢竟按預(yù)期，是想將整體全局的故障轉(zhuǎn)換成局部的故障）。

• 交易總體受影響時間時長。

• 交易失敗筆數(shù)。

• 響應(yīng)時間變化。

• 節(jié)點間網(wǎng)絡(luò)流量（主要還是跨機房這塊兒的，因為同城跨機房可能不光是有分布式數(shù)據(jù)庫的流量，還會有業(yè)務(wù)的流量，或者是其它數(shù)據(jù)同步的流量。所以可能這種流量之間，對于帶寬的要求也是使用分布式過程當(dāng)中比較需要注意的點）。

在云繳費系統(tǒng)實施的過程當(dāng)中，也有一些重點，簡單給大家介紹一下：

1）邏輯設(shè)計

• 分片表：是數(shù)據(jù)庫里最大的一張表，里面可能記錄著日志、流水等。像這種表，是一定要有一個合適的分片鍵的，而且我們要把握好分片的數(shù)量。對這種大表的訪問、拆分，平均分配到各個分區(qū)，只有實現(xiàn)了這部分的數(shù)據(jù)打散，才能真正對數(shù)據(jù)庫的性能和訪問效率有一個提升。所以幾個大表之間可能同時還會存在一些Join的情況，所以我們這次在數(shù)據(jù)庫的設(shè)計上，對這些大表都選擇的相同的分片鍵，這樣一筆交易進(jìn)來，它可能帶著相同的分片鍵，只會到一個實例里的一個數(shù)據(jù)庫里去。所以它通過這種方式，減少了跨庫甚至是跨機房的這種Join，來避免由于這些操作而增加的交易成本。

• 全局表：在繳費系統(tǒng)里，數(shù)據(jù)量有限，修改較少，讀取較多。此類表會由grid這層把這些表復(fù)制到所有分片，可以和各分片進(jìn)行本地Join。我們的總體目標(biāo)就是為了讓它規(guī)避這種跨庫。

• 普通表：數(shù)據(jù)量有限，修改讀取都較少。此類表集中存儲不分片。這時候如果需要取得數(shù)就是臨時Join一下，不需要和分片表Join，不會有太大的成本和開銷。

2）開發(fā)設(shè)計

• 連接驅(qū)動：和MySQL沒有什么區(qū)別，基本上語法遵從MySQL的協(xié)議就可以了。

• 開發(fā)過程中盡量避免使用存儲過程。相對來講，這次做的應(yīng)用改造就是將交易邏輯變得簡單化了，把原來復(fù)雜的地方都給優(yōu)化掉了，同時也選擇了相對合理的字符集，因為這個系統(tǒng)原庫的字符集其實不太合適，所以借著這個機會把這個問題解決掉。

• 分布式數(shù)據(jù)庫存在多個接入IP，需合理設(shè)計負(fù)載均衡和故障重連機制。因為剛才那張架構(gòu)圖中，它是從應(yīng)用連接到F5，再從F5分發(fā)到每一個中間件節(jié)點，中間件節(jié)點再到MySQL。中間件節(jié)點到MySQL是長連接的，但從F5到中間件這層是不能用長連接的，因為如果要是這個時候用長連接，可能就會失去F5負(fù)載均衡的作用，所以在這種情況下，又要用短連接，又要保證在出現(xiàn)分布式事務(wù)的時候不能因為連接中斷導(dǎo)致分布式事務(wù)失?。ɑ蛘呷绻麤]有分布式事務(wù)，可能一筆交易中，需要做多個DML操作，可能因為短連接斷開了導(dǎo)致它做了3個DML，最后一個沒有做成）這種情況肯定是不可能出現(xiàn)的。所以這時候我們調(diào)整了一下短連接的配置，讓短連接的配置足夠長，然后F5的連接斷開釋放由應(yīng)用層來控制。比如說做十筆交易之后斷一次。所以這塊兒的負(fù)載均衡是靠這個來設(shè)計的。

3）批量設(shè)計

• 在批量這塊，原來在Oracle環(huán)境里并沒有做到與數(shù)據(jù)庫的一個完全隔離，這次在分布式改造中，也是對這塊兒做了一個優(yōu)化。所以在隔離的情況下，我就不能讓批量運行環(huán)境成為一個單點。所以就對批量故障的冗余、重試、數(shù)據(jù)檢查及校驗進(jìn)行了重新設(shè)計。因為批量設(shè)計中也會涉及到一些分布式的事務(wù)，所以這塊兒的數(shù)據(jù)的檢查和校驗也是設(shè)計的一個重點。

• 優(yōu)化批量邏輯，減少跨分片Join及復(fù)雜SQL。因為復(fù)雜SQL對于分布式來說，很多產(chǎn)品對于復(fù)雜SQL的支持還是很有限的，可能跑起來的效果也達(dá)不到預(yù)期。

• 批量拆分，充分利用分布式數(shù)據(jù)庫資源。

4）試運行方案設(shè)計

剛才提到的bridge的工具，就是我們現(xiàn)在在試運行，以后會正式運行的一個主要的逃生方案。這種新技術(shù)產(chǎn)品帶來的架構(gòu)風(fēng)險，一定要有逃生方案才能比較有信心在上面跑，在極端情況下，可以將新架構(gòu)隔離開，讓它回到相對來講比較傳統(tǒng)的架構(gòu)上去。

目前云繳費架構(gòu)已經(jīng)算是改造完成上線了，但是它并沒有完全接軌Oracle的真實交易，是在應(yīng)用層做了一個轉(zhuǎn)發(fā)，把發(fā)給Oracle的交易同步發(fā)給EverDB一份，然后通過這個試運行階段，來驗證產(chǎn)品的兼容性、穩(wěn)定性。這個也算是個過渡階段吧，因為只有經(jīng)過真實生產(chǎn)的全量交易的壓力后，我們才敢把其它的交易完整切過去。

所以這塊兒的設(shè)計也挺重要的，如果直接就新上的話，可能會出現(xiàn)各種各樣預(yù)期外的問題，解決起來可能也會無從下手。我們利用交易轉(zhuǎn)發(fā)的機制，還在驗證這種新架構(gòu)的運行模式。對這種并行試運行的方案還有逃生方案，都要進(jìn)行充分的測試，最終目的就是保障數(shù)據(jù)安全，同時這種逃生環(huán)境要能承載一定量的業(yè)務(wù)運行，畢竟它節(jié)點數(shù)不會有分布式那么多，所以如果業(yè)務(wù)全部切過來的話，它可能運行起來會遇到一些資源征用之類的問題。

云繳費系統(tǒng)部署架構(gòu)，它前面是APP的數(shù)量，一共是24臺，后邊用兩個grid節(jié)點，然后有兩臺備份的服務(wù)器，和兩臺逃生的服務(wù)器。中間的區(qū)域全是MySQL的集群，全都是主從，采用的是一主三從的模式，目前是雙機房運行。每個機房里有一主一從，另一個機房里有兩從，然后通過配置，我保證同機房和跨機房有兩個節(jié)點是數(shù)據(jù)強一致的，另外一個節(jié)點就不管了。這樣如果發(fā)生故障的話，由grid這層會告訴它哪個節(jié)點的數(shù)據(jù)是最新的，是一致的，這樣就會切到那個節(jié)點。

目前云繳費系統(tǒng)試運行也有半年了，這里是對它簡單的一個總結(jié)：

1）分布式改造收益

• 處理能力橫向擴展性提升，擺脫傳統(tǒng)IOE的瓶頸。

• 降低對高度存儲的依賴。因為剛才那張部署圖里，所有的機器都沒有用存儲，像EMC或者其它牌子的存儲，都沒有在用，實際上就用了本地的NVME的閃盤；這個性能確實比存儲要高很多，所以它其實從一定程度上彌補了網(wǎng)絡(luò)上鏈路邊長帶來的損耗。

• 全局故障降低為局部故障。就是可能某一部分?jǐn)?shù)據(jù)不可用，比如8個集群，哪怕一個集群整體都掛了，從也全掛了，但我可能還有7個集群，至少還有八分之七的對外服務(wù)是好的。

2）運維方案積累

因為這個對于我們來說也是第一次做這種比較大的改造轉(zhuǎn)型，所以在監(jiān)控指標(biāo)及監(jiān)控方案、故障場景的應(yīng)急預(yù)案、分布式數(shù)據(jù)庫的技術(shù)標(biāo)準(zhǔn)&規(guī)范等，都是通過這次的探索和遷移總結(jié)出了一些經(jīng)驗。

3）產(chǎn)品自身完善

• 提升集群整體運行工穩(wěn)定性。這方面還是有提高的空間的，尤其是在架構(gòu)上，我們也在嘗試把一些像ZooKeeper這種小的組件與其它的組件做整合，減少各功能節(jié)點的離散程度，畢竟節(jié)點越多，出問題的可能性就越大。

• 對各分布式組件進(jìn)行功能增強。因為通過這次開發(fā)和上線工作，也發(fā)現(xiàn)了數(shù)據(jù)庫架構(gòu)中的一些問題。

• 優(yōu)化部署架構(gòu)。

4）技術(shù)難點

目前我們碰到的一個技術(shù)難點就是交易全鏈路監(jiān)控分析。因為這個交易鏈路從外部到前端的F5，再到AP，再到F5，再到grid，再到MySQL，包括可能grid之間（也就是中間件節(jié)點之間）可能會有些數(shù)據(jù)同步，MySQL之間也會有些數(shù)據(jù)同步，所以這個交易鏈路實際上比以前變得是太長太長了，所以現(xiàn)在如果某一筆交易慢了的話，可能在一些有日志的節(jié)點上，或者說日志做的比較完善的話，可能還是有跡可循的?？墒侨绻W(wǎng)絡(luò)抖動了一下，或者是出現(xiàn)一些延時的問題，目前看這種全鏈路雖然不是不能監(jiān)控，但至少還沒能實現(xiàn)一筆交易完整的一個追溯的過程。

五、EverDB后續(xù)發(fā)展規(guī)劃及里程回顧

1）近期

增強運行穩(wěn)定性，提升分布式事務(wù)性能。目前來講，我們對于XA事務(wù)的處理可能性能上還有一定的優(yōu)化空間，同時我們也希望這種數(shù)據(jù)庫能夠支持國產(chǎn)ARM平臺和國產(chǎn)操作系統(tǒng)，能夠接近于全系的安全可控標(biāo)準(zhǔn)；

2）中期

• 我們想簡化部署方式，來實現(xiàn)輕量級的部署。而且像中間件的組件還有bridge的組件，我們想應(yīng)用到單元化架構(gòu)里去，就是把它拿出來，不一定就只能在我們這個架構(gòu)里用。因為它本身就是松耦合的，拿到別的場景下，一樣可以比較好的發(fā)揮它的作用。

• 還有一個就是擴展運行數(shù)據(jù)采集能力。因為數(shù)據(jù)這個東西其實在運維的過程當(dāng)中是非常重要的，Oralce做的最好就是AWR 報告，其它不管是傳統(tǒng)商業(yè)產(chǎn)品，還是新生的開源產(chǎn)品，在這方面還是比較欠缺的。所以我們想通過運行數(shù)據(jù)的采集，加上對數(shù)據(jù)的分析，來實現(xiàn)幫助數(shù)據(jù)庫的運行狀況能夠長期保持在一個穩(wěn)定良好的狀態(tài)之下。

3）遠(yuǎn)期

如果說的再遠(yuǎn)一些，就是希望支持更多種底層數(shù)據(jù)存儲引擎，不僅僅是MySQL了，可能還會有金融其它的數(shù)據(jù)庫產(chǎn)品，并通過這種方式來擴展我們的應(yīng)用場景。

以上就是我們后續(xù)想對分布式架構(gòu)做的一些主要的工作。

這里展示了我們整個的一個里程碑，從開始改造到現(xiàn)在經(jīng)歷的一些比較重要的時間節(jié)點：

• 18年，啟動了技術(shù)路線的調(diào)研。

• 19年第一季度完成了方案的選型，同時這個項目也正式地立項。其實這中間經(jīng)歷了大概有半年的時間，調(diào)研的過程我們還是收獲很大的，因為我們看到了同業(yè)或者是互聯(lián)網(wǎng)都在用什么樣的產(chǎn)品，用什么樣的架構(gòu)，走什么技術(shù)路線，這些作為我們的參照依據(jù)，最終才有了EverDB的立項。

• 19年11月，我們完成了EverDB1.0版本的開發(fā)。

• 后面時間很緊張，用了大概兩個多月，就把云繳費基于EverDB1.0的測試完成了，并且做了投產(chǎn)試運行的工作。目前是處于全量交易轉(zhuǎn)發(fā)的階段。之前1月的時候，我們只過來了八分之一的量，后面通過不斷觀察數(shù)據(jù)庫的指標(biāo)，還有運行的穩(wěn)定性，慢慢開到了半量、全量。

• 今年5月，我們啟動了相應(yīng)的升級項目，想后續(xù)對它整體的功能和組件做一些增強及優(yōu)化。

其實架構(gòu)轉(zhuǎn)型，收獲還是很大的，對于分布式的一些優(yōu)勢、劣勢，包括它能做什么，不能做什么，如果沒有完整地做一次的話，了解的就沒有這么深入和具體。以上就是我今天給大家分享的全部內(nèi)容。

Q & A

Q1：分片集群一致性備份策略是怎么樣的？跨機房切換后性能下降后怎么和應(yīng)用聯(lián)動的呢？

A：是這樣，關(guān)于備份，是可以在grid層面獲取到每個數(shù)據(jù)節(jié)點的一致性點的，可以通過這個一致性點，對后端的MySQL做一個相應(yīng)的備份。關(guān)于跨機房切換后性能下降的問題，從1:1的架構(gòu)圖里，可以看出，我們做了服務(wù)器數(shù)量上的冗余保障，即便只在單邊機房運行，每個服務(wù)器上也只有一個主節(jié)點，不會出現(xiàn)切換后一臺服務(wù)器存在多個主節(jié)點導(dǎo)致的資源爭用問題。

Q2：MySQL使用的是什么版本呢？

A：目前使用的還是MySQL 5.7.26，暫時還沒考慮MySQL 8。MySQL 8我們也在學(xué)習(xí)當(dāng)中，因為它目前出現(xiàn)的時間也不算太長，相對來說現(xiàn)在比較穩(wěn)定的還是MySQL 5.7.26或者M(jìn)ySQL 5.7.28這種版本。

Q3：跨機房的延時怎么解決呢？

A：其實跨機房的延時很難解決，因為你要保證數(shù)據(jù)一致性的話，跨機房的延時是一定要等的，就像CAP，可能保了一致性，就要犧牲一些別的東西。這個可能不同的領(lǐng)域有不同的權(quán)衡吧，也許對有些能夠犧牲一致性的業(yè)務(wù)來說，對這塊兒就可以把延時問題規(guī)避掉。但是涉及到轉(zhuǎn)賬，這種賬務(wù)問題，可能還是沒辦法解決掉延時。其實在發(fā)生故障切換的時候，我們必須要保證另一個機房是有一份完整的數(shù)據(jù)的。

Q4：分片表主要就是業(yè)務(wù)流水，全局表就是類似人員信息這種主數(shù)據(jù)？

A：差不多，這個也主要是在開發(fā)層做的設(shè)計。對于表的分類大致是這種方向，因為其實就是流水表、日志表最大，這種表在原來的Oralce的部署里面就已經(jīng)做了一層甚至兩層的分區(qū)了，只不過它提供的存儲還是在一個里邊。在這塊兒，如果將分片表按照分片鍵做了拆分，實際上就已經(jīng)部署到不同的物理分區(qū)上了。

Q5：選擇合適的MySQL字符集，選了什么，utf8mb4嗎？

A：是的，用的就是utf8mb4。

Q6：分布式，是否涉及到多個庫完成一個事務(wù)？若有，如何保證事務(wù)完整執(zhí)行？

A：分布式肯定是要涉及多個庫的，這個實際上是已經(jīng)跨了物理的分區(qū)和我的MySQL實例的，這個目前在云繳費的批量交易里是存在的，其實大部分聯(lián)機都規(guī)避了這個問題，所以在批量交易里有這么個事務(wù)，就是用的XA的事務(wù)協(xié)議，來保證事務(wù)的完整性。

Q7：數(shù)據(jù)庫節(jié)點變多，是如何做到備份統(tǒng)一調(diào)度的？

A：這個其實跟剛才Q1是一樣的。實際上我們備份的時間還是選擇在業(yè)務(wù)相對低峰的時間段進(jìn)行的，可能凌晨幾點這樣，因為確實在獲取一致性點的時候，對業(yè)務(wù)是有點影響的，所以當(dāng)節(jié)點變多的時候，影響可能會有點放大，不過也不會太大，而且又是凌晨兩三點的那種基本上交易比較少的時間。所以還是通過數(shù)據(jù)一致性點來做的統(tǒng)一的調(diào)度。

Q8：分布式數(shù)據(jù)庫，多大尺寸時，得再拆庫？或者，達(dá)到其它什么指標(biāo)時，得考慮再拆庫？

A：這個主要還是看物理分區(qū)的容量。因為這個用的不是存儲，而是nvme的閃盤，也是為了保證效率，所以這個盤的擴展數(shù)量肯定是有限的。還有就是CPU和內(nèi)存，當(dāng)這幾方面，還有單點承受的一些QPS、TPS指標(biāo)，當(dāng)它承受到一定量，可能會有些風(fēng)險的時候，可能就會提前做一些數(shù)據(jù)節(jié)點或分片水平擴展的操作。

Q9：備份是如何發(fā)起的，有統(tǒng)一的數(shù)據(jù)庫備份平臺嗎？

A：備份發(fā)起使用control的那個管理組件，它實際上是一個外部的管理臺，用它來調(diào)度響應(yīng)的備份策略的。

Q10：對SQL有限制么，中間件會有內(nèi)存溢出的風(fēng)險么，mycat落地中間數(shù)據(jù)，有內(nèi)存溢出風(fēng)險

A：目前還沒出現(xiàn)，關(guān)于溢出這個問題，目前在測試環(huán)境應(yīng)該是壓到了差不多10000左右的TPS，目前看著是沒有什么問題。

關(guān)于對SQL的限制，是指語法嗎？語法上是確實有些限制的，比如對于過程的調(diào)用、臨時表表或是left join之類的操作，具體的限制要通過開發(fā)手冊作為指引，但目前基本已經(jīng)支持了絕大多數(shù)的開發(fā)語法。

Q11：可以實現(xiàn)在線擴縮容嗎？具體原理是怎樣的？

A：有兩種，一種是要擴物理的機器，一種是要加MySQL實例。擴機器的時候，就是挪動主從的位置，其實也就是一個切換，對局部影響有，但比較小，從測試結(jié)果來看，比加實例挪數(shù)據(jù)的影響小得多。

Q12：讀寫分離是基于中間件還是業(yè)務(wù)層處理？

A：是通過中間件來做的，具備讀寫分離功能但目前未啟用，主要是因為試點業(yè)務(wù)沒有這個需求，所以不是目前主要的測試目標(biāo)。

Q13：DDL變更怎樣保證所有節(jié)點一致，如果某個節(jié)點執(zhí)行失敗，怎么處理？

A：其實現(xiàn)在對于DDL的原子性還是沒有一個很好的保障的，但是對于DDL操作是有相應(yīng)的檢測命令的，所以在DDL場景下，可能還是需要通過操作的標(biāo)準(zhǔn)規(guī)范來避免這個問題。比如說，DDL命令下去之后，要返回一下我所有DDL修改的結(jié)果，因為它畢竟涉及到多個實例，目前還沒有很強的一個DDL保障。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
			

		

		

			
		


			
長按訂閱更多精彩▼
		

			
如有收獲，點個在看，誠摯感謝