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

于樹(shù)文

光大銀行資深DBA

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

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

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

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

一、光大云繳費(fèi)平臺(tái)的基本情況

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

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

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

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

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

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

• 數(shù)據(jù)一致性是通過(guò)存儲(chǔ)復(fù)制技術(shù)來(lái)保證的：這個(gè)相對(duì)來(lái)講，光大用的時(shí)間也比較長(zhǎng)，而且也證明了這種數(shù)據(jù)一致性保護(hù)機(jī)制是比較可靠的。

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

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

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

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

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

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

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

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

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

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

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

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

• 跨數(shù)據(jù)庫(kù)中心多活部署：對(duì)于傳統(tǒng)數(shù)據(jù)庫(kù)來(lái)說(shuō)，這種部署模式也非常困難。可能只有通過(guò)分布式的引入，才能提升多活部署的可能、提升可用性、加快切換速度，突破特性軟硬件的成本和性能限制。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EverDB有三個(gè)主要的組件：

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

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

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

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

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

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

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

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

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

3）橫向擴(kuò)展

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

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

• 一個(gè)是可以稀釋實(shí)例分布（因?yàn)楫吘挂彩强紤]到成本，有可能物理設(shè)備是復(fù)用的，會(huì)存在一個(gè)物理機(jī)上跑著一個(gè)MySQL集群的主，同時(shí)還跑著別的集群的從實(shí)例，所以通過(guò)這種物理設(shè)備的擴(kuò)展，可以通過(guò)切換并移動(dòng)MySQL的實(shí)例，來(lái)減少物理設(shè)備的容量壓力）。

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

4）遷移備份

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

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

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

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

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

• 支持絕大部分MySQL語(yǔ)法（不是全支持，像我印象中，有一些像left join之類的支持程度是有限的，因?yàn)楫吘顾慕馕鍪强縢rid來(lái)完成的，所以它的語(yǔ)法在這層的邏輯實(shí)現(xiàn)上是有一定的限制的）。

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

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

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

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

1）測(cè)試場(chǎng)景設(shè)計(jì)

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

• 各功能節(jié)點(diǎn)的故障切換（因?yàn)橄鄬?duì)傳統(tǒng)的架構(gòu)來(lái)說(shuō)，雖然不集中了，但是功能節(jié)點(diǎn)變多了。同時(shí)也擺脫了傳統(tǒng)的小機(jī)，因?yàn)楝F(xiàn)在用的都是X86的服務(wù)器了，所以它硬件的故障率可能是有一定上升的，所以我們模擬了每個(gè)功能節(jié)點(diǎn)的故障）。

• 節(jié)點(diǎn)間網(wǎng)絡(luò)故障（因?yàn)榫W(wǎng)絡(luò)整個(gè)的交易鏈路比原來(lái)的長(zhǎng)了很多，所以跨機(jī)房或者是網(wǎng)卡的網(wǎng)絡(luò)故障都有可能發(fā)生）。

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

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

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

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

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

• 各故障場(chǎng)景的影響范圍（因?yàn)楫吘拱搭A(yù)期，是想將整體全局的故障轉(zhuǎn)換成局部的故障）。

• 交易總體受影響時(shí)間時(shí)長(zhǎng)。

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

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

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

在云繳費(fèi)系統(tǒng)實(shí)施的過(guò)程當(dāng)中，也有一些重點(diǎn)，簡(jiǎn)單給大家介紹一下：

1）邏輯設(shè)計(jì)

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

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

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

2）開(kāi)發(fā)設(shè)計(jì)

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

• 開(kāi)發(fā)過(guò)程中盡量避免使用存儲(chǔ)過(guò)程。相對(duì)來(lái)講，這次做的應(yīng)用改造就是將交易邏輯變得簡(jiǎn)單化了，把原來(lái)復(fù)雜的地方都給優(yōu)化掉了，同時(shí)也選擇了相對(duì)合理的字符集，因?yàn)檫@個(gè)系統(tǒng)原庫(kù)的字符集其實(shí)不太合適，所以借著這個(gè)機(jī)會(huì)把這個(gè)問(wèn)題解決掉。

• 分布式數(shù)據(jù)庫(kù)存在多個(gè)接入IP，需合理設(shè)計(jì)負(fù)載均衡和故障重連機(jī)制。因?yàn)閯偛拍菑埣軜?gòu)圖中，它是從應(yīng)用連接到F5，再?gòu)腇5分發(fā)到每一個(gè)中間件節(jié)點(diǎn)，中間件節(jié)點(diǎn)再到MySQL。中間件節(jié)點(diǎn)到MySQL是長(zhǎng)連接的，但從F5到中間件這層是不能用長(zhǎng)連接的，因?yàn)槿绻沁@個(gè)時(shí)候用長(zhǎng)連接，可能就會(huì)失去F5負(fù)載均衡的作用，所以在這種情況下，又要用短連接，又要保證在出現(xiàn)分布式事務(wù)的時(shí)候不能因?yàn)檫B接中斷導(dǎo)致分布式事務(wù)失敗（或者如果沒(méi)有分布式事務(wù)，可能一筆交易中，需要做多個(gè)DML操作，可能因?yàn)槎踢B接斷開(kāi)了導(dǎo)致它做了3個(gè)DML，最后一個(gè)沒(méi)有做成）這種情況肯定是不可能出現(xiàn)的。所以這時(shí)候我們調(diào)整了一下短連接的配置，讓短連接的配置足夠長(zhǎng)，然后F5的連接斷開(kāi)釋放由應(yīng)用層來(lái)控制。比如說(shuō)做十筆交易之后斷一次。所以這塊兒的負(fù)載均衡是靠這個(gè)來(lái)設(shè)計(jì)的。

3）批量設(shè)計(jì)

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

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

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

4）試運(yùn)行方案設(shè)計(jì)

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

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

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

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

目前云繳費(fèi)系統(tǒng)試運(yùn)行也有半年了，這里是對(duì)它簡(jiǎn)單的一個(gè)總結(jié)：

1）分布式改造收益

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

• 降低對(duì)高度存儲(chǔ)的依賴。因?yàn)閯偛拍菑埐渴饒D里，所有的機(jī)器都沒(méi)有用存儲(chǔ)，像EMC或者其它牌子的存儲(chǔ)，都沒(méi)有在用，實(shí)際上就用了本地的NVME的閃盤；這個(gè)性能確實(shí)比存儲(chǔ)要高很多，所以它其實(shí)從一定程度上彌補(bǔ)了網(wǎng)絡(luò)上鏈路邊長(zhǎng)帶來(lái)的損耗。

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

2）運(yùn)維方案積累

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

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

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

• 對(duì)各分布式組件進(jìn)行功能增強(qiáng)。因?yàn)橥ㄟ^(guò)這次開(kāi)發(fā)和上線工作，也發(fā)現(xiàn)了數(shù)據(jù)庫(kù)架構(gòu)中的一些問(wèn)題。

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

4）技術(shù)難點(diǎn)

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

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

1）近期

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

2）中期

• 我們想簡(jiǎn)化部署方式，來(lái)實(shí)現(xiàn)輕量級(jí)的部署。而且像中間件的組件還有bridge的組件，我們想應(yīng)用到單元化架構(gòu)里去，就是把它拿出來(lái)，不一定就只能在我們這個(gè)架構(gòu)里用。因?yàn)樗旧砭褪撬神詈系?，拿到別的場(chǎng)景下，一樣可以比較好的發(fā)揮它的作用。

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

3）遠(yuǎn)期

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

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

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

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

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

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

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

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

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

Q & A

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

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

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

A：目前使用的還是MySQL 5.7.26，暫時(shí)還沒(méi)考慮MySQL 8。MySQL 8我們也在學(xué)習(xí)當(dāng)中，因?yàn)樗壳俺霈F(xiàn)的時(shí)間也不算太長(zhǎng)，相對(duì)來(lái)說(shuō)現(xiàn)在比較穩(wěn)定的還是MySQL 5.7.26或者M(jìn)ySQL 5.7.28這種版本。

Q3：跨機(jī)房的延時(shí)怎么解決呢？

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

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

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

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

A：是的，用的就是utf8mb4。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A：是通過(guò)中間件來(lái)做的，具備讀寫分離功能但目前未啟用，主要是因?yàn)樵圏c(diǎn)業(yè)務(wù)沒(méi)有這個(gè)需求，所以不是目前主要的測(cè)試目標(biāo)。

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

A：其實(shí)現(xiàn)在對(duì)于DDL的原子性還是沒(méi)有一個(gè)很好的保障的，但是對(duì)于DDL操作是有相應(yīng)的檢測(cè)命令的，所以在DDL場(chǎng)景下，可能還是需要通過(guò)操作的標(biāo)準(zhǔn)規(guī)范來(lái)避免這個(gè)問(wèn)題。比如說(shuō)，DDL命令下去之后，要返回一下我所有DDL修改的結(jié)果，因?yàn)樗吘股婕暗蕉鄠€(gè)實(shí)例，目前還沒(méi)有很強(qiáng)的一個(gè)DDL保障。

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

		

		

			
		


			
長(zhǎng)按訂閱更多精彩▼
		

			
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝