網(wǎng)易分布式數(shù)據(jù)庫(kù)多活架構(gòu)的演進(jìn)與實(shí)踐

大家好，今天給大家分享一些網(wǎng)易近幾年在數(shù)據(jù)庫(kù)多活方向上的工作。

我將簡(jiǎn)單介紹下為什么我們要做數(shù)據(jù)庫(kù)多活，再?gòu)娜齻€(gè)階段介紹網(wǎng)易在數(shù)據(jù)庫(kù)多活上做的工作。

數(shù)據(jù)庫(kù)多活的目標(biāo)包括“容災(zāi)”和“提升處理能力”兩方面。

容災(zāi)可以簡(jiǎn)單理解為當(dāng)系統(tǒng)由于外部或內(nèi)部原因出現(xiàn)部分不可用時(shí)，仍然能在短時(shí)間內(nèi)恢復(fù)可用。而容災(zāi)最常用的手段即是備份，在數(shù)據(jù)庫(kù)領(lǐng)域不僅需要對(duì)計(jì)算能力做備份也要對(duì)數(shù)據(jù)做備份。容災(zāi)級(jí)別可以劃分為宿主機(jī)級(jí)別的容災(zāi)、機(jī)房級(jí)別的容災(zāi)和跨城的容災(zāi)。

要提升數(shù)據(jù)庫(kù)的處理能力，一般有讀寫(xiě)分離和單元化兩種方式，讀寫(xiě)分離將數(shù)據(jù)庫(kù)的備份節(jié)點(diǎn)的讀能力提供出來(lái)，其實(shí)提升了系統(tǒng)的利用率，而單元化則是當(dāng)整個(gè)機(jī)房的資源無(wú)法容納業(yè)務(wù)的增長(zhǎng)時(shí)，加入更多的機(jī)房資源，擴(kuò)展業(yè)務(wù)的處理能力的方法。

網(wǎng)易成立23年以來(lái)，孵化了大量的產(chǎn)品，不同的產(chǎn)品特性、產(chǎn)品發(fā)展到不同階段對(duì)數(shù)據(jù)庫(kù)多活都有不一樣的需求。

像音樂(lè)、新聞這類的泛娛樂(lè)產(chǎn)品，它們每日要處理大量的請(qǐng)求，同時(shí)也會(huì)產(chǎn)生大量的數(shù)據(jù)，而由于其產(chǎn)品的獨(dú)特性，它們對(duì)數(shù)據(jù)的一致性要求往往不是特別高，但對(duì)可用性要求比較高。

而嚴(yán)選這樣的電商類應(yīng)用，由于其獨(dú)有的交易類數(shù)據(jù)，對(duì)數(shù)據(jù)一致性要求是比較高的，流量一般小于娛樂(lè)性應(yīng)用，對(duì)可用性同樣很高。

而最為極端的支付類應(yīng)用，由于所有的業(yè)務(wù)都和錢(qián)掛鉤，對(duì)數(shù)據(jù)一致性要求極高，流量反而最小，可用性要求同樣很高。

對(duì)一致性要求的不同會(huì)導(dǎo)致不同的產(chǎn)品在選擇數(shù)據(jù)庫(kù)多活方案時(shí)有不一樣的選擇，而互聯(lián)網(wǎng)產(chǎn)品對(duì)可用性的要求往往是一致的，都無(wú)法接受產(chǎn)品長(zhǎng)時(shí)間不可用。

我從DBA同事那邊要到了一份網(wǎng)易當(dāng)前的數(shù)據(jù)庫(kù)選型分布數(shù)據(jù)。

由于其穩(wěn)定性和開(kāi)源的特性，超過(guò)一半的數(shù)據(jù)庫(kù)實(shí)例是MySQL。而緩存則是Redis使用最廣，數(shù)據(jù)量較大時(shí)會(huì)選用HBase。Oracle仍然在一些老的系統(tǒng)內(nèi)有使用，而其他一些NewSQL數(shù)據(jù)庫(kù)則還在測(cè)試驗(yàn)證階段。

單實(shí)例的MySQL處理能力有限，無(wú)法滿足網(wǎng)易內(nèi)各個(gè)產(chǎn)品的使用需求，所以網(wǎng)易內(nèi)大量的MySQL實(shí)際是掛在了自研的分布式數(shù)據(jù)庫(kù)DDB的下面，DDB封裝了分庫(kù)分表的能力，對(duì)外提供了可擴(kuò)展的數(shù)據(jù)庫(kù)處理能力。DDB的實(shí)現(xiàn)思路和開(kāi)源的MyCat、ShardingSphere很像，這里就不贅述了。

文章后續(xù)的多活方案都以MySQL作為對(duì)象描述。

機(jī)房?jī)?nèi)的數(shù)據(jù)庫(kù)多活其實(shí)是單機(jī)房?jī)?nèi)數(shù)據(jù)庫(kù)的高可用方案。一個(gè)主節(jié)點(diǎn)提供讀寫(xiě)能力，一個(gè)高可用從作為主實(shí)例的備份，還有一個(gè)只讀從對(duì)外提供只讀的能力。這里三節(jié)點(diǎn)的部署方式能夠保證任何一個(gè)節(jié)點(diǎn)不可用時(shí)，都有備用節(jié)點(diǎn)接替其提供服務(wù)，而整個(gè)系統(tǒng)的處理能力不會(huì)下降。

這個(gè)方案適用發(fā)展初期的業(yè)務(wù)，提供了宿主機(jī)級(jí)別的容災(zāi)能力與讀寫(xiě)分離的能力。

除了異步復(fù)制、半同步復(fù)制外，MySQL從5.7之后便提供了MySQL Group Replication這種新型的復(fù)制模式，相較于傳統(tǒng)的主從方案，MGR提供了自動(dòng)選主、數(shù)據(jù)強(qiáng)一致和主從皆可寫(xiě)入等能力。MGR在網(wǎng)易內(nèi)部大量產(chǎn)品上都有不錯(cuò)的推廣。

無(wú)論是主從復(fù)制還是MGR都逃不開(kāi)一個(gè)復(fù)制延遲的問(wèn)題，MySQL復(fù)制的是Binlog，Binlog發(fā)送到從節(jié)點(diǎn)到Binlog在從節(jié)點(diǎn)上回放執(zhí)行有一段時(shí)間差，這就是復(fù)制延遲。

在主從切換時(shí)，從節(jié)點(diǎn)必須回放完堆積的Binlog才能對(duì)外提供服務(wù)，所以過(guò)大的復(fù)制延遲會(huì)導(dǎo)致不可控的主從切換時(shí)間。另外只讀節(jié)點(diǎn)上復(fù)制延遲過(guò)大，也會(huì)導(dǎo)致業(yè)務(wù)讀到過(guò)時(shí)的數(shù)據(jù)，可能影響到業(yè)務(wù)的正確性。

MySQL后續(xù)版本提升了其并行復(fù)制的能力，但仍然沒(méi)能完全解決復(fù)制延遲過(guò)高的問(wèn)題，我們的做法是監(jiān)控各個(gè)實(shí)例的TPS情況，當(dāng)達(dá)到可能觸發(fā)復(fù)制延遲時(shí)就對(duì)集群做水平拆分（通過(guò)DDB的擴(kuò)容完成）。

業(yè)務(wù)上的話DDB提供了LOADBALANCE這樣的hint語(yǔ)法，允許業(yè)務(wù)指定SQL能容忍的復(fù)制延遲，如果延遲超過(guò)設(shè)定的閾值，則會(huì)調(diào)度到主節(jié)點(diǎn)執(zhí)行。

如果業(yè)務(wù)有跨機(jī)房容災(zāi)的需求，或單一機(jī)房?jī)?nèi)資源已經(jīng)無(wú)法滿足業(yè)務(wù)的發(fā)展需求時(shí)就有跨機(jī)房多活的需求了。最完善的方案是使用單元化來(lái)做，但是單元化對(duì)業(yè)務(wù)的改造代價(jià)過(guò)大，所以出現(xiàn)了一種折中的跨機(jī)房多活方案。

此方案中業(yè)務(wù)層代碼還是在每個(gè)機(jī)房部署一套，但是在數(shù)據(jù)庫(kù)的寫(xiě)操作和對(duì)一致性要求較高的讀請(qǐng)求會(huì)路由到主機(jī)房，而每個(gè)機(jī)房都有自己的只讀實(shí)例提供一致性要求不太高的讀請(qǐng)求。

此方案提供了簡(jiǎn)單的跨機(jī)房容災(zāi)能力，但是跨機(jī)房的讀寫(xiě)會(huì)造成較大的延遲，且對(duì)機(jī)房間的穩(wěn)定性要求也較高。

分享前我簡(jiǎn)單搭了一個(gè)實(shí)驗(yàn)環(huán)境，測(cè)試了在相同的并發(fā)下不同的延遲對(duì)數(shù)據(jù)庫(kù)性能的影響。

當(dāng)延遲上升到3ms時(shí)，數(shù)據(jù)庫(kù)性能下降在30%+，當(dāng)延遲上升到20ms時(shí)，數(shù)據(jù)庫(kù)性能下降在75%+。而3ms和20ms剛好是同城多機(jī)房和跨城多機(jī)房的一個(gè)延遲標(biāo)準(zhǔn)。

從數(shù)據(jù)上看，同城情況下，強(qiáng)一致的同步方案仍然是可行的，而跨城的情況下，基本只能用異步的同步方案了。

應(yīng)用仍然在每個(gè)機(jī)房對(duì)立部署，但是機(jī)房?jī)?nèi)的應(yīng)用只讀寫(xiě)本機(jī)房的數(shù)據(jù)庫(kù)，為了避免多寫(xiě)帶來(lái)的數(shù)據(jù)沖突，每個(gè)機(jī)房只寫(xiě)自己負(fù)責(zé)的數(shù)據(jù)，這就是跨機(jī)房單元化多活。這個(gè)方案中最重要的就是對(duì)流量的路由，每個(gè)機(jī)房負(fù)責(zé)了一部分業(yè)務(wù)流量，常見(jiàn)的劃分方式為按照ID Hash劃分，或者按照地域劃分。

此方案解決了上面方案跨機(jī)房讀寫(xiě)的延遲問(wèn)題，并且具有更好的水平擴(kuò)展性，唯一的弊端是業(yè)務(wù)改造代價(jià)較大。數(shù)據(jù)庫(kù)層要提供較好的數(shù)據(jù)同步能力，緩存、消息隊(duì)列、RPC等組件都要做對(duì)應(yīng)的改造。

不同單元的數(shù)據(jù)庫(kù)雙向同步工作我們使用自研的網(wǎng)易數(shù)據(jù)運(yùn)河（NDC）來(lái)完成。NDC對(duì)外主要提供了數(shù)據(jù)遷移/數(shù)據(jù)同步和數(shù)據(jù)訂閱的能力，數(shù)據(jù)同步將關(guān)系型數(shù)據(jù)庫(kù)的數(shù)據(jù)實(shí)時(shí)同步到異構(gòu)的對(duì)端數(shù)據(jù)庫(kù)或數(shù)倉(cāng)中，數(shù)據(jù)訂閱則將數(shù)據(jù)庫(kù)的增量變更推送進(jìn)消息隊(duì)列，供業(yè)務(wù)方或流計(jì)算任務(wù)消費(fèi)。

數(shù)據(jù)庫(kù)單元化場(chǎng)景下主要用到NDC的雙向同步能力。

雙向同步第一個(gè)要解決的問(wèn)題即是回環(huán)復(fù)制。如果對(duì)同步的數(shù)據(jù)不加過(guò)濾仍由其在不同單元的數(shù)據(jù)庫(kù)中來(lái)回復(fù)制必然消耗大量的網(wǎng)絡(luò)帶寬，最終還會(huì)導(dǎo)致數(shù)據(jù)不一致。

解決回環(huán)復(fù)制的核心是如何給每個(gè)增量變更標(biāo)注其發(fā)生的機(jī)房，然后在同步時(shí)避免將其同步回發(fā)生的機(jī)房，就能解決回環(huán)復(fù)制的問(wèn)題了。這里總結(jié)了三種解決回環(huán)復(fù)制的方案：

• 引入額外字段：給每個(gè)同步的表加入額外字段標(biāo)注上一次對(duì)其操作的機(jī)房信息，此方案對(duì)同步的性能影響最小，切可以做到跨不同數(shù)據(jù)庫(kù)類型使用，但是對(duì)業(yè)務(wù)的表有侵入。

• GTID：使用MySQL自己的GTID來(lái)標(biāo)注事務(wù)的機(jī)房信息，這也是MySQL原生復(fù)制解決回環(huán)復(fù)制的方案，其對(duì)同步的性能影響較小，完全無(wú)侵入，但是只能用于MySQL之間的雙向同步。

• 事務(wù)中引入額外SQL：在業(yè)務(wù)的事務(wù)中加入額外的SQL來(lái)標(biāo)注此事物產(chǎn)生的機(jī)房，此方案也能做到跨數(shù)據(jù)源，對(duì)業(yè)務(wù)侵入較小，但是對(duì)同步的性能影響較大。

三種方案都有各自的優(yōu)缺點(diǎn)，實(shí)現(xiàn)上根據(jù)需要選擇即可。NDC對(duì)三種方案都做了實(shí)現(xiàn)，在單元化場(chǎng)景下實(shí)際選擇的是方案一，主要是其使用的額外字段同時(shí)是另外一個(gè)功能需要的字段，算是重復(fù)利用，沒(méi)有引入額外開(kāi)銷(xiāo)。

正常情況下，每個(gè)單元都寫(xiě)自己負(fù)責(zé)的數(shù)據(jù)，不存在數(shù)據(jù)沖突，但是當(dāng)某個(gè)單元不可用，要做流量切換的時(shí)候，就會(huì)出現(xiàn)多個(gè)單元同時(shí)寫(xiě)入同一行數(shù)據(jù)的情況，從而產(chǎn)生數(shù)據(jù)沖突。數(shù)據(jù)沖突不可避免，我們需要一個(gè)機(jī)制保證產(chǎn)生沖突的數(shù)據(jù)最終能保證一致。

解決數(shù)據(jù)沖突的核心思路是給每個(gè)變更賦予一個(gè)版本信息，當(dāng)產(chǎn)生數(shù)據(jù)沖突時(shí)總是保留高版本的數(shù)據(jù)即可保證最終一致性。NDC采用了最簡(jiǎn)單的物理時(shí)間作為變更的版本信息，在進(jìn)行數(shù)據(jù)同步時(shí)，只有當(dāng)對(duì)端版本低于（或等于）同步的變更時(shí)，才同步到對(duì)端。

這樣的數(shù)據(jù)沖突解決方案能解決99%以上的數(shù)據(jù)沖突，保證數(shù)據(jù)的最終一致。但是在一些特殊情況下可能失效，一個(gè)比較典型的例子就是機(jī)房間由于物理時(shí)間基準(zhǔn)不一致，某個(gè)后發(fā)生的變更它的版本卻更小，這樣這個(gè)變更無(wú)法同步到對(duì)端機(jī)房，最終導(dǎo)致數(shù)據(jù)不一致。

解決這個(gè)問(wèn)題的辦法是將這種特殊數(shù)據(jù)版本信息給提升到發(fā)生變更之前的版本，保證變更能同步到其他機(jī)房。

在實(shí)踐中我們發(fā)現(xiàn)單個(gè)機(jī)房?jī)?nèi)對(duì)同一行數(shù)據(jù)的并發(fā)修改也可能造成版本后退，當(dāng)刪除和插入操作同時(shí)進(jìn)行時(shí)也可能出現(xiàn)版本未知的情況，對(duì)于這樣的特殊場(chǎng)景都只能通過(guò)調(diào)整特殊的同步手段最終來(lái)確保數(shù)據(jù)的一致性。

數(shù)據(jù)校驗(yàn)對(duì)一個(gè)數(shù)據(jù)同步系統(tǒng)是一個(gè)可選但又是必須的功能。在單元化的雙向同步功能中我們不僅使用定期的全量校驗(yàn)發(fā)現(xiàn)系統(tǒng)中存在的不一致風(fēng)險(xiǎn)，還提過(guò)了實(shí)時(shí)數(shù)據(jù)校驗(yàn)功能更實(shí)時(shí)地發(fā)現(xiàn)數(shù)據(jù)不一致的風(fēng)險(xiǎn)。數(shù)據(jù)校驗(yàn)的覆蓋范圍和對(duì)數(shù)據(jù)庫(kù)的性能影響是一個(gè)相悖的問(wèn)題，更大的校驗(yàn)覆蓋范圍必將導(dǎo)致更大的數(shù)據(jù)庫(kù)性能開(kāi)銷(xiāo)。產(chǎn)品上我們?cè)试S用戶選擇實(shí)時(shí)數(shù)據(jù)校驗(yàn)的范圍，可選的范圍包括：

• 雙寫(xiě)數(shù)據(jù)校驗(yàn)：所有在多個(gè)單元都發(fā)生了寫(xiě)入的數(shù)據(jù)都進(jìn)行校驗(yàn)。

• 沖突數(shù)據(jù)校驗(yàn)：產(chǎn)生了數(shù)據(jù)沖突的雙寫(xiě)數(shù)據(jù)才進(jìn)行校驗(yàn)。

• 風(fēng)險(xiǎn)數(shù)據(jù)校驗(yàn)：存在版本回退這樣的特殊數(shù)據(jù)才進(jìn)行數(shù)據(jù)校驗(yàn)。

數(shù)據(jù)校驗(yàn)的實(shí)現(xiàn)比較簡(jiǎn)單，將需要校驗(yàn)的數(shù)據(jù)放入隊(duì)列中，校驗(yàn)線程不斷地去取需要校驗(yàn)的數(shù)據(jù)，并比對(duì)源和目標(biāo)的數(shù)據(jù)是否一致即可。

網(wǎng)易數(shù)據(jù)庫(kù)多活經(jīng)歷了機(jī)房?jī)?nèi)多活、跨機(jī)房多活和跨機(jī)房單元化多活三個(gè)階段。在數(shù)據(jù)庫(kù)多活上積累了一些經(jīng)驗(yàn)，之后也還有更長(zhǎng)的路要走。希望這些經(jīng)驗(yàn)?zāi)軌蚪o各位一些啟發(fā)，也期待和大家在數(shù)據(jù)庫(kù)多活的話題上有更多的交流。

Q1：數(shù)據(jù)變化是通過(guò)什么工具推送到Kafka？

A：通過(guò)網(wǎng)易內(nèi)部自研的數(shù)據(jù)傳輸工具NDC完成，它的工作原理與開(kāi)源的Canal類似，模擬自己為一個(gè)MySQL從節(jié)點(diǎn)，與主節(jié)點(diǎn)建立復(fù)制協(xié)議獲取binlog，解析后得到行變更數(shù)據(jù)然后推送入Kafka。

Q2：請(qǐng)問(wèn)網(wǎng)易的單元化是分了兩個(gè)單元嘛？

A：是的，現(xiàn)在是在杭州的義橋與東冠機(jī)房做同城雙單元，機(jī)房延遲大概在2ms-3ms之間。

Q3：什么時(shí)候用中間件復(fù)制，什么時(shí)候用數(shù)據(jù)庫(kù)自帶復(fù)制？

A：原生復(fù)制是MySQL自身提供的復(fù)制能力，好處是不需要額外的組件部署，也很穩(wěn)定。但是當(dāng)需要進(jìn)行跨大版本復(fù)制，原生復(fù)制的性能不滿足需求，或者想自定義一些復(fù)制特性的時(shí)候就可以使用中間件來(lái)完成復(fù)制工作了，中間件復(fù)制另外的一個(gè)優(yōu)點(diǎn)是可以自定義很多監(jiān)控指標(biāo)，實(shí)時(shí)監(jiān)控復(fù)制的狀態(tài)。

Q4：數(shù)據(jù)同步異常后校驗(yàn)機(jī)制落后于業(yè)務(wù)怎么辦？

A：我猜問(wèn)題是想問(wèn)在校驗(yàn)機(jī)制發(fā)現(xiàn)數(shù)據(jù)不一致問(wèn)題之前，錯(cuò)誤數(shù)據(jù)已經(jīng)暴露給業(yè)務(wù)方時(shí)如何處理。由于校驗(yàn)并發(fā)現(xiàn)問(wèn)題距離問(wèn)題發(fā)生肯定是有延后的，所以這個(gè)問(wèn)題沒(méi)法避免，核心還是在發(fā)現(xiàn)問(wèn)題后能夠快速定位這些不一致數(shù)據(jù)對(duì)業(yè)務(wù)產(chǎn)生的影響，并根據(jù)實(shí)際情況來(lái)處理。

Q5：?jiǎn)卧哂袛U(kuò)展性，怎么理解？

A：單元化的方案對(duì)單元的個(gè)數(shù)理論是沒(méi)有限制的，在業(yè)務(wù)規(guī)模上來(lái)后發(fā)展到幾十個(gè)、上百個(gè)單元都是可行的。

Q6：剛剛物理時(shí)間不一致，數(shù)據(jù)回退怎么解決的？

A：由于不同機(jī)房物理時(shí)間基準(zhǔn)存在偏差，可能在數(shù)據(jù)更新時(shí)發(fā)生更新后的數(shù)據(jù)時(shí)間戳低于更新前的時(shí)間戳，光從時(shí)間戳上看是發(fā)生了版本（物理時(shí)間即為數(shù)據(jù)的版本）回退，此時(shí)我們是通過(guò)將更新后的時(shí)間戳提升到與更新前的時(shí)間戳一樣的大小，來(lái)保證此條數(shù)據(jù)能正確同步到對(duì)端單元。

Q7：說(shuō)數(shù)據(jù)異常了，而業(yè)務(wù)在校驗(yàn)發(fā)現(xiàn)前已經(jīng)用了臟數(shù)據(jù)怎么辦？

A：單元化方案里的雙向同步策略只保證最終一致性，如果中間數(shù)據(jù)出現(xiàn)短暫的異常讀，業(yè)務(wù)上是能容忍的，這里牽扯出一個(gè)問(wèn)題，什么樣的業(yè)務(wù)模塊適合做單元化，我們這里一般認(rèn)為更新不是特別頻繁，且業(yè)務(wù)上自己有比較好的分區(qū)邏輯的業(yè)務(wù)適合做單元化。

Q8：流量切換的時(shí)候，怎么保證業(yè)務(wù)正確性？

A：在計(jì)劃內(nèi)切換的場(chǎng)景下，上層流量控制可以保證在底層同步組件都完成數(shù)據(jù)同步后再將流量切過(guò)來(lái)，這個(gè)過(guò)程一般在1分鐘以內(nèi)，在計(jì)劃外的切換過(guò)程中，無(wú)法做這個(gè)保證，所以可能產(chǎn)生兩邊數(shù)據(jù)不一致，這個(gè)需要在事后找出不一致的數(shù)據(jù)，并按照業(yè)務(wù)自身特點(diǎn)進(jìn)行修復(fù)。

Q9：支付類數(shù)據(jù)，如何保證強(qiáng)一致的？

A：支付類的數(shù)據(jù)為了保證強(qiáng)一致性，一般使用MGR這種類Paxos協(xié)議來(lái)完成數(shù)據(jù)同步。

Q10：這種數(shù)據(jù)的同步是解析的binlog，然后寫(xiě)入NDC同步到異地機(jī)房嗎？

A：是的，具體可以參考Q1的回答。

Q11：系統(tǒng)重構(gòu)、數(shù)據(jù)庫(kù)表設(shè)計(jì)及結(jié)構(gòu)都不一致，一般遷移用什么ETL工具？

A：網(wǎng)易自研的NDC就能滿足這類需求，開(kāi)源的話Canal提供了比較完善的binlog復(fù)制解析能力，但是一些具體的復(fù)雜需求可能需要自己實(shí)現(xiàn)。

Q12：網(wǎng)易少量的Oracle都用在哪些業(yè)務(wù)系統(tǒng)上？如何做多機(jī)房雙活的？

A：Oracle現(xiàn)在基本就只有網(wǎng)易支付在用了，據(jù)我所知他們并沒(méi)有在Oracle上做多機(jī)房雙活的計(jì)劃。

Q13：NDC支持異構(gòu)數(shù)據(jù)庫(kù)同步嗎，SQL Server  Oracle  MySQL？

A：支持，現(xiàn)在支持的系統(tǒng)暫時(shí)只包括Oracle和MySQL，主要還是網(wǎng)易內(nèi)部沒(méi)有使用SQL Server。

Q14：Redis，MQ復(fù)制用什么中間件？

A：Redis據(jù)我所知是使用的Redis Cluster方案，MQ的復(fù)制是業(yè)務(wù)自研的一個(gè)同步工具。

Q15：MGR怎么處理DDL？

A：MGR對(duì)于DDL的復(fù)制和對(duì)于普通事務(wù)的復(fù)制沒(méi)有太大區(qū)別，不過(guò)如果是大表的阻塞性DDL，由于執(zhí)行時(shí)間過(guò)長(zhǎng)，可能造成較大的復(fù)制延遲，網(wǎng)易內(nèi)部對(duì)于大表的DDL一般是用PT-OSC這樣的在線修改表結(jié)構(gòu)工具完成。

Q16：一個(gè)單元就是一個(gè)閉環(huán)的機(jī)房嗎？

A：一般是的，單元化方案里一般要求流量盡量在單元內(nèi)閉環(huán)。

Q17：一個(gè)交易，做到一半，掛了，流量切換后，是把交易重新做嗎？之前做的怎么處理？

A：交易一般具有事務(wù)性，所以做到一半掛了一般理解為這個(gè)事務(wù)沒(méi)有提交，切換后整個(gè)過(guò)程需要重做。

Q18：如果解決分庫(kù)分表后，數(shù)據(jù)一致性的問(wèn)題？本來(lái)應(yīng)該放在一個(gè)事務(wù)的兩個(gè)SQL，分庫(kù)分表后寫(xiě)往兩個(gè)實(shí)例？有哪些方法可以解決，除了分布式事務(wù)，性能太低？

A：分布式數(shù)據(jù)庫(kù)中的事務(wù)基本都是按分布式事務(wù)的方式解決的，比較經(jīng)典的是兩階段提交，如果覺(jué)得兩階段提交效率太低，可以業(yè)務(wù)層使用基于MQ的柔性事務(wù)方案。

Q19：版本提升的依據(jù)是什么呢？怎么判斷是不是時(shí)間戳延遲引起的？

A：版本回退的判斷即是通過(guò)binlog中的時(shí)間戳列的數(shù)據(jù)得到的，所以依據(jù)就是binlog中的數(shù)據(jù)。

Q20：MGR能用在異地多活場(chǎng)景嗎？延時(shí)太大吧？對(duì)網(wǎng)絡(luò)有哪些要求？

A：可以用在同城單元化的方案里，同城的延遲情況對(duì)性能的影響較為可控，同城延遲一般在3ms以下。

Q21：Canal+RocketMQ可以用在異地復(fù)制嗎？

A：可以。

Q22：銀行級(jí)的場(chǎng)景下使用哪種方案做多活好??？

A：銀行對(duì)數(shù)據(jù)庫(kù)一致性要求比較高，除了一些強(qiáng)一致的商業(yè)方案外，MySQL的MGR是一個(gè)不錯(cuò)的選擇。

Q23：流量切換之前，做個(gè)一個(gè)操作。切換后，發(fā)現(xiàn)數(shù)據(jù)沒(méi)同步過(guò)來(lái)，又做了，那不是做了兩次嗎？

A：答案參考問(wèn)題8，計(jì)劃內(nèi)和計(jì)劃外可能要分開(kāi)討論。

Q24：MGR 和 RAC有比較過(guò)嗎 同城雙活部署的話 MGR是否可以達(dá)到RAC的同步能力？

A：MGR本質(zhì)上還是日志的同步，和RAC存儲(chǔ)共享的思路是完全不一樣的，性能上MGR也肯定是不如RAC的，但是好像MGR部署門(mén)檻低。

Q25：人工做DDL，那人比數(shù)據(jù)同步慢怎么辦？數(shù)據(jù)過(guò)來(lái)了，但是表還沒(méi)改過(guò)來(lái)，就出錯(cuò)了。

A：流程上一定是DDL在所有單元都執(zhí)行完成后再開(kāi)放給業(yè)務(wù)使用。

Q26：MGR多活現(xiàn)在有在核心業(yè)務(wù)上生產(chǎn)的嗎？

A：網(wǎng)易內(nèi)部暫時(shí)還沒(méi)有。