MySQL異地多活的數(shù)據(jù)雙向復(fù)制方案

1、 MySQL異地多活的數(shù)據(jù)雙向復(fù)制方案異地多活背景在講DRC或者講數(shù)據(jù)復(fù)制之前，先跟大家回顧一下異地多活的背景。今天我主要分享餓了么多活的底層數(shù)據(jù)實(shí)施，介紹在整個(gè)多活的設(shè)計(jì)和實(shí)施過(guò)程中我們是怎么處理異地?cái)?shù)據(jù)同步的，而這個(gè)數(shù)據(jù)同步組件在我們公司內(nèi)部稱之為DRC。去年我們?cè)谧龆嗷钫{(diào)研的時(shí)候，整個(gè)公司所有的業(yè)務(wù)服務(wù)都是部署在北京機(jī)房，服務(wù)器大概有四千多臺(tái)，災(zāi)備的機(jī)器是在云端，都是虛擬機(jī)，大概有三千多臺(tái)。當(dāng)時(shí)我們峰值的業(yè)務(wù)訂單數(shù)量已經(jīng)接近了千萬(wàn)級(jí)別，但是基本上北京機(jī)房（IDC）已經(jīng)無(wú)法再擴(kuò)容了，也就是說(shuō)我們沒有空余的機(jī)架，沒有辦法添加新的服務(wù)器了，必須要再建一個(gè)新的機(jī)房，于是我們?cè)谏虾＝ㄒ粋€(gè)新的機(jī)房，

2、上海機(jī)房要在今年的4月份才會(huì)投入使用，所以需要在上海機(jī)房建成之后，異地多活項(xiàng)目能具備在生產(chǎn)環(huán)境上進(jìn)行灰度。異地多活的底層數(shù)據(jù)同步實(shí)施這是異地多活的底層數(shù)據(jù)同步實(shí)施的一個(gè)簡(jiǎn)單的概要圖，大家可以看到，我們有兩個(gè)機(jī)房，一個(gè)是北京機(jī)房，一個(gè)是上海機(jī)房。在這個(gè)時(shí)候，我們期望目標(biāo)是北方所有的用戶請(qǐng)求、用戶流量全部進(jìn)入北京機(jī)房，南方所有的用戶請(qǐng)求、用戶流量進(jìn)入上海機(jī)房。困難的地方是，這個(gè)用戶有可能今天在北方，明天在南方，因?yàn)樗诔霾睿€有就是存在一些區(qū)域在我們劃分南北shard的時(shí)候，它是在邊界上面的，這種情況會(huì)加劇同一個(gè)用戶流量在南北機(jī)房來(lái)回漂移的發(fā)生。還有個(gè)情況，當(dāng)我們某個(gè)機(jī)房出現(xiàn)故障，如核心交換機(jī)壞掉

3、導(dǎo)致整個(gè)機(jī)房服務(wù)不可用，我們希望可以把這個(gè)機(jī)房的所有流量快速切到另外的數(shù)據(jù)中心去，從而提高整個(gè)餓了么服務(wù)的高可用性。以上所有的因素，都需要底層數(shù)據(jù)庫(kù)的數(shù)據(jù)之間是打通的。而今天我所要分享的DRC項(xiàng)目就是餓了么異地MySQL數(shù)據(jù)庫(kù)雙向復(fù)制的組件服務(wù)，即上圖中紅色框標(biāo)記的部分。異地多活對(duì)底層數(shù)據(jù)的要求我們?cè)谇捌谡{(diào)研DRC實(shí)現(xiàn)的時(shí)候，主要總結(jié)了的三點(diǎn)，而在后續(xù)的設(shè)計(jì)和實(shí)施當(dāng)中，基本上也是圍繞這三點(diǎn)來(lái)去解決問(wèn)題。第一個(gè)我們覺得是延遲要低，當(dāng)時(shí)給自己定的目標(biāo)是秒級(jí)的，我們希望在北京機(jī)房或上海機(jī)房寫入的數(shù)據(jù)，需要在1秒鐘之內(nèi)同步到上?；蛘弑本C(jī)房。整個(gè)延遲要小于1秒鐘。第二個(gè)就是我們要確保數(shù)據(jù)的一致性，數(shù)據(jù)

4、是不能丟也不能錯(cuò)的，如果出現(xiàn)數(shù)據(jù)的不一致性，可能會(huì)給上層的業(yè)務(wù)服務(wù)、甚至給產(chǎn)品帶來(lái)災(zāi)難性的問(wèn)題。第三個(gè)就是保證整個(gè)復(fù)制組件具備高吞吐處理能力，指的是它可以面對(duì)各種復(fù)雜的環(huán)境，比方說(shuō)業(yè)務(wù)正在進(jìn)行數(shù)據(jù)的批量操作、數(shù)據(jù)的維護(hù)、數(shù)據(jù)字典的變更情況，這些會(huì)產(chǎn)生瞬間大量的變更數(shù)據(jù)，DRC需要面對(duì)這種情況，需要具備高吞吐能力去扛住這些情況。數(shù)據(jù)低延遲和一致性之間，我們認(rèn)為主要從數(shù)據(jù)的并發(fā)復(fù)制這個(gè)策略上去解決，安全、可靠、高效的并發(fā)策略，才能保證數(shù)據(jù)是低延遲的復(fù)制，在大量數(shù)據(jù)需要復(fù)制時(shí)，DRC并發(fā)處理才能快速在短時(shí)間內(nèi)解決。數(shù)據(jù)一致性，用戶的流量可能被路由到兩個(gè)機(jī)房的任何一個(gè)機(jī)房去，也就是說(shuō)同樣一條記錄可能在

5、兩個(gè)機(jī)房中被同時(shí)更改，所以DRC需要做數(shù)據(jù)沖突處理，最終保持?jǐn)?shù)據(jù)一致性，也就是數(shù)據(jù)不能出錯(cuò)。如果出現(xiàn)沖突且DRC自身無(wú)法自動(dòng)處理沖突，我們還提供了一套數(shù)據(jù)沖突訂正平臺(tái)，會(huì)要求業(yè)務(wù)方一道來(lái)制定數(shù)據(jù)訂正規(guī)則。高吞吐剛才已經(jīng)介紹了，正常情況用戶流量是平穩(wěn)的，DRC是能應(yīng)對(duì)的，在1秒鐘之內(nèi)將數(shù)據(jù)快速?gòu)?fù)制到對(duì)端機(jī)房。當(dāng)DBA對(duì)數(shù)據(jù)庫(kù)數(shù)據(jù)進(jìn)行數(shù)據(jù)歸檔、大表DDL等操作時(shí)，這些操作會(huì)在短時(shí)間內(nèi)快速產(chǎn)生大量的變更數(shù)據(jù)需要我們復(fù)制，這些數(shù)據(jù)可能遠(yuǎn)遠(yuǎn)超出了DRC的最大處理能力，最終會(huì)導(dǎo)致DRC復(fù)制出現(xiàn)延遲，所以DRC與現(xiàn)有的DBA系統(tǒng)需要進(jìn)行交互，提供一種彈性的數(shù)據(jù)歸檔機(jī)制，如當(dāng)DRC出現(xiàn)大的復(fù)制延遲時(shí)，終止歸檔

6、JOB，控制每輪歸檔的數(shù)據(jù)規(guī)模。如DRC識(shí)別屬于大表DDL產(chǎn)生的binlog events，過(guò)濾掉這些events，避免這些數(shù)據(jù)被傳輸?shù)狡渌麢C(jī)房，占用機(jī)房間帶寬資源。以上是我們?cè)趯?shí)施異地多活的數(shù)據(jù)層雙向復(fù)制時(shí)對(duì)DRC項(xiàng)目提出的主要要求。數(shù)據(jù)集群規(guī)模（多活改造前）這是我們?cè)谧龆嗷钪暗谋本?shù)據(jù)中心的數(shù)據(jù)規(guī)模，這個(gè)數(shù)據(jù)中心當(dāng)時(shí)有超過(guò)250套MySQL的集群，一千多臺(tái)MySQL的實(shí)例，Redis也超過(guò)四百個(gè)集群。DRC服務(wù)的目標(biāo)對(duì)象就是這250套MySQL集群，因?yàn)樵谡诮ㄔO(shè)的第二個(gè)數(shù)據(jù)中心里未來(lái)也會(huì)有對(duì)應(yīng)的250套MySQL集群，我們需要把兩個(gè)機(jī)房業(yè)務(wù)對(duì)等的集群進(jìn)行數(shù)據(jù)打通。多活下MySQL的用途

7、分類我們按照業(yè)務(wù)的用途，給它劃分了多種DB服務(wù)類型。為什么要總結(jié)這個(gè)呢？因?yàn)橛幸恍╊愋?，我們是不需要?fù)制的，所以要甄別出來(lái)，首先第一個(gè)多活DB，我們認(rèn)為它的服務(wù)需要做多活的。比方說(shuō)支付、訂單、下單，一個(gè)機(jī)房掛了，用戶流量切到另外新的機(jī)房，這些業(yè)務(wù)服務(wù)在新的機(jī)房是工作的。我們把這些多活服務(wù)依賴的DB稱為多活DB，我們優(yōu)先讓業(yè)務(wù)把DB改造成多活DB，DRC對(duì)多活DB進(jìn)行數(shù)據(jù)雙向復(fù)制，保障數(shù)據(jù)一致性。多活DB的優(yōu)勢(shì)剛才已經(jīng)講了，如果機(jī)房出現(xiàn)故障、核心交換機(jī)出問(wèn)題，整個(gè)機(jī)房垮了，運(yùn)維人員登不進(jìn)機(jī)房機(jī)器，那么我們可以在云端就把用戶流量切到其它的機(jī)房。有些業(yè)務(wù)對(duì)數(shù)據(jù)有強(qiáng)一致性要求，后面我會(huì)講到其實(shí)DRC是

8、沒有辦法做到數(shù)據(jù)的強(qiáng)一致性要求的，它是有數(shù)據(jù)沖突發(fā)生的，需要引入數(shù)據(jù)訂正措施。業(yè)務(wù)如果對(duì)數(shù)據(jù)有強(qiáng)一致性要求，比方說(shuō)用戶注冊(cè)，要求用戶登錄名全局唯一（DB字段上可能加了唯一約束），兩個(gè)機(jī)房可能會(huì)在同一時(shí)間接收了相同用戶登錄名的注冊(cè)請(qǐng)求，這種情況下，DRC是無(wú)法自身解決掉這個(gè)沖突，而且業(yè)務(wù)方對(duì)這個(gè)結(jié)果也是無(wú)法接受的，這種DB我們會(huì)把它歸納到GlobalDB里面，它的特性是什么呢？它的特性是單機(jī)房可寫，多機(jī)房可讀，因?yàn)槟阋ＷC數(shù)據(jù)的強(qiáng)一致性的話，必須讓所有機(jī)房的請(qǐng)求處理結(jié)果，最終寫到固定的一個(gè)機(jī)房中。這種DB的上層業(yè)務(wù)服務(wù)，在機(jī)房掛掉之后是有損的。比方說(shuō)機(jī)房掛了，用戶注冊(cè)功能可能就不能使用了。最后一

9、個(gè)非多活DB，它是很少的，主要集中于一些后端的管理平臺(tái)，這種項(xiàng)目本身基本上不是多活的，所以這種DB我們不動(dòng)它，還是采用原生的主備方式。DRC總體架構(gòu)設(shè)計(jì)這是DRC復(fù)制組件的總體架構(gòu)設(shè)計(jì)。我們有一個(gè)組件叫Replicator，它會(huì)從MySQL集群的Master上把binlog日志記錄抽取出來(lái)，解析binlog記錄并轉(zhuǎn)換成我們自定義的數(shù)據(jù)，存放到一個(gè)超大的event buffer里面，event buffer支持TB級(jí)別的容量。在目標(biāo)機(jī)房里我們會(huì)部署一個(gè)Applier服務(wù)，這個(gè)服務(wù)啟一個(gè)TCP長(zhǎng)連接到Replicator服務(wù)，Replicator會(huì)不斷的推送數(shù)據(jù)到Applier，Applier通過(guò)

10、JDBC最終把數(shù)據(jù)寫入到目標(biāo)數(shù)據(jù)庫(kù)。我們會(huì)通過(guò)一個(gè)Console控制節(jié)點(diǎn)來(lái)進(jìn)行配置管理、部署管理以及進(jìn)行各個(gè)組件的HA協(xié)調(diào)工作。DRC Replicator Server這是DRC Replicator Server組件比較細(xì)的結(jié)構(gòu)描述，主要是包含了一個(gè)MetaDB模塊，MetaDB主要用來(lái)解決歷史的Binlog的解析問(wèn)題。我們成功解析Binlog記錄之后，會(huì)把它轉(zhuǎn)換成我們自己定義的一種數(shù)據(jù)結(jié)構(gòu)，這種結(jié)構(gòu)相對(duì)于原生的結(jié)構(gòu)，Size更小，MySQL binlog event的定義在size角度上考慮事實(shí)上已經(jīng)很極致了，但是可以結(jié)合我們自己的特性，我們會(huì)把不需要的event全部過(guò)濾掉（如table

11、_map_event），把可以忽略的數(shù)據(jù)全部忽略掉。我們比對(duì)的結(jié)果是需要復(fù)制的event數(shù)據(jù)只有原始數(shù)據(jù)size的70%。DRC Applier Server往目標(biāo)的MySQL集群復(fù)制寫的時(shí)候，由DRC Applier Server負(fù)責(zé)，它會(huì)建一個(gè)長(zhǎng)連接到Replicator上去，Replicator PUSH數(shù)據(jù)給Applier。Applier把數(shù)據(jù)拿到之后做事務(wù)的還原，最后通過(guò)JDBC把事務(wù)重新寫到目標(biāo)DB里面，寫的過(guò)程當(dāng)中，我們應(yīng)用了并發(fā)的策略。并發(fā)策略在提供復(fù)制吞吐能力，降低復(fù)制延遲起到?jīng)Q定的作用，還有冪等也是非常重要的，后面有很多運(yùn)維操作，還有一些Failover回退操作，會(huì)導(dǎo)致發(fā)生

12、數(shù)據(jù)被重復(fù)處理的情況，冪等操作保障重復(fù)處理數(shù)據(jù)不會(huì)發(fā)生問(wèn)題。DRC防止循環(huán)復(fù)制在做復(fù)制的時(shí)候，大家肯定會(huì)碰到解決循環(huán)復(fù)制的問(wèn)題。我們?cè)诳紤]這個(gè)問(wèn)題的時(shí)候，查了很多資料，也問(wèn)了很多一些做過(guò)類似項(xiàng)目的前輩，當(dāng)時(shí)我們認(rèn)為有兩大類辦法，第一大類辦法一開始否決了，因?yàn)槲覀儗?duì)MySQL的內(nèi)核原碼不熟悉，而且時(shí)間上也來(lái)不及，雖然我們知道通過(guò)MySQL的核內(nèi)解決回路復(fù)制是最佳的、最優(yōu)的?？緿RC自身解決這個(gè)問(wèn)題，也有兩種辦法，一種辦法是我們?cè)贏pply數(shù)據(jù)到目標(biāo)DB的時(shí)候把binlog關(guān)閉掉，另外一種辦法就是寫目標(biāo)DB的時(shí)候在事物中額外增加checkpoint表的數(shù)據(jù)，用于記錄源DB的server_id。后來(lái)

13、我們比較了一下，第一個(gè)辦法是比較簡(jiǎn)單，實(shí)現(xiàn)容易，但是因?yàn)锽inlog記錄沒有產(chǎn)生，導(dǎo)致不支持級(jí)聯(lián)復(fù)制，也對(duì)后續(xù)的運(yùn)維帶來(lái)麻煩。所以我們最后選擇的是第二個(gè)辦法，通過(guò)把事務(wù)往目標(biāo)DB復(fù)制的時(shí)候，在事務(wù)中hack一條checkpoint的數(shù)據(jù)來(lái)標(biāo)識(shí)事務(wù)產(chǎn)生的原始server，DRC在解析MySQL binlog記錄時(shí)就能正確分辨出數(shù)據(jù)的真正來(lái)源。DRC數(shù)據(jù)一致性保障在剛開始研發(fā)、設(shè)計(jì)的時(shí)候，數(shù)據(jù)一致性保障是我們很頭疼的問(wèn)題。并不是在一開始就把所有的點(diǎn)都想全了，是在做的過(guò)程當(dāng)中出現(xiàn)了問(wèn)題，一步步解決的，回顧一下，我們大概從三個(gè)方面去保證數(shù)據(jù)的一致性：首先，因?yàn)閿?shù)據(jù)庫(kù)是多活的，我們必須從數(shù)據(jù)中心層面盡可

14、能把數(shù)據(jù)沖突發(fā)生的概率降到最低，避免沖突，怎么避免呢？就是合理的流量切分，你可以按照用戶的維度，按照地域的維度，對(duì)流量進(jìn)行拆分。剛才我們講的，北方用戶的所有數(shù)據(jù)在北京機(jī)房，這些北方用戶的下單、支付等的所有操作數(shù)據(jù)都是在北方機(jī)房產(chǎn)生的，所以用戶在同一個(gè)機(jī)房中發(fā)生的數(shù)據(jù)變更操作絕對(duì)是安全的。我們最怕的是同一個(gè)數(shù)據(jù)同時(shí)或者是在相近的時(shí)間里同時(shí)在兩個(gè)機(jī)房被修改，我們怕的是這個(gè)問(wèn)題，因?yàn)檫@種情況就會(huì)引發(fā)數(shù)據(jù)沖突。所以我們通過(guò)合理的流量切分，保證絕大部分時(shí)候數(shù)據(jù)是不會(huì)沖突的。第二個(gè)我們認(rèn)為你要保障數(shù)據(jù)一致性，首先你要確保數(shù)據(jù)不丟，一旦發(fā)生可能數(shù)據(jù)丟失的情況，我們會(huì)做一個(gè)比較保險(xiǎn)的策略，就是把數(shù)據(jù)復(fù)制的時(shí)間

15、位置回退，即使重復(fù)處理數(shù)據(jù)，也避免丟數(shù)據(jù)的可能，但是這個(gè)時(shí)候會(huì)帶來(lái)數(shù)據(jù)重復(fù)處理的問(wèn)題，所以數(shù)據(jù)的冪等操作特別重要。這些都是我們避免數(shù)據(jù)發(fā)生沖突的方法，那沖突實(shí)際上是不可避免的，沖突發(fā)生后，我們?cè)趺唇鉀Q？最終采用的辦法是在數(shù)據(jù)庫(kù)表上隱含地加一個(gè)時(shí)間字段(數(shù)據(jù)最后更新時(shí)間)，這個(gè)字段對(duì)業(yè)務(wù)是透明的，主要用來(lái)輔助DRC復(fù)制，一旦數(shù)據(jù)發(fā)生沖突，DRC復(fù)制組件可以通過(guò)這個(gè)時(shí)間來(lái)判斷兩個(gè)機(jī)房或者三個(gè)機(jī)房中的哪條數(shù)據(jù)是最后被更新的，最新優(yōu)先的原則，誰(shuí)最后的修改時(shí)間是最新的，就以它為準(zhǔn)。DRC數(shù)據(jù)復(fù)制低延遲保障剛才我們講的是數(shù)據(jù)的一致性，還有一個(gè)點(diǎn)非常重要，就是數(shù)據(jù)復(fù)制的低延遲保障。我們現(xiàn)在延遲包括用戶高峰時(shí)

16、間也是小于1秒的，只有在凌晨之后，各種歸檔、批量數(shù)據(jù)處理、DDL變更等操作會(huì)導(dǎo)致DRC延遲出現(xiàn)毛刺和抖動(dòng)。如果你的延遲很高的話，第一在做流量切換時(shí)，因?yàn)檫\(yùn)維優(yōu)先保障產(chǎn)品服務(wù)的可用性，在不得以的情況會(huì)不考慮你的復(fù)制延遲，不會(huì)等數(shù)據(jù)復(fù)制追平之后再切流量，所以你的數(shù)據(jù)沖突的概率就變的很大。為了保證復(fù)制低延遲，我們認(rèn)為主要策略、或者你在實(shí)施時(shí)主要的做法還是并發(fā)，因?yàn)槟阒挥杏酶咝У陌踩牟l(fā)復(fù)制策略，服務(wù)才有足夠的吞吐處理能力，而不至于你的復(fù)制通道因?yàn)橛龅健昂Ａ俊睌?shù)據(jù)而導(dǎo)致數(shù)據(jù)積壓，從而加劇了復(fù)制延遲的產(chǎn)生。我們一開始采用的基于表級(jí)別的并發(fā)，但是表級(jí)別的并發(fā)在很多情況下，并發(fā)策略沒辦法被有效的利用，比方

17、說(shuō)有的業(yè)務(wù)線的數(shù)據(jù)庫(kù)可能90%的數(shù)據(jù)集中在一張表或者是幾個(gè)表里面，而大部分表數(shù)據(jù)量很小，那基于表的并發(fā)策略就并發(fā)不起來(lái)了。我們現(xiàn)在跑的是基于行級(jí)別的并發(fā)，這種并發(fā)它更能容忍和適應(yīng)很多場(chǎng)景。DRC & MySQL Master切換這個(gè)是DRC復(fù)制組件與MySQL集群的關(guān)系關(guān)聯(lián)圖，一旦MySQL集群里面的Master發(fā)生了主備切換，原來(lái)的Master掛了，DRC怎么處理？目前的解決方案是DBA系統(tǒng)的MHA工具會(huì)通知DRC控制中心，DRC的控制中心會(huì)找到對(duì)應(yīng)的復(fù)制鏈路，然后把復(fù)制鏈路從老的Master切到新的Master，但是關(guān)鍵點(diǎn)是MHA在通知之前先把老的Master設(shè)置為不可寫，阻斷DRC可能往

18、老的Master繼續(xù)寫數(shù)據(jù)。DRC線上運(yùn)行狀況（規(guī)模）這個(gè)是我們DRC上線之后的運(yùn)行狀況。現(xiàn)在大概有有將近400多條復(fù)制鏈路。這個(gè)復(fù)制鏈路是指單向的鏈路。我們提供的消息訂閱大概有17個(gè)業(yè)務(wù)方接入，每天產(chǎn)生超過(guò)1億條的消息。DRC線上運(yùn)行狀況（性能）這是DRC線上運(yùn)行的一個(gè)性能監(jiān)控快照，我們可以看到，它是上午11點(diǎn)多到12點(diǎn)多的一個(gè)小時(shí)的性能，你會(huì)發(fā)現(xiàn)其實(shí)有一個(gè)DB是有毛刺的，有一個(gè)復(fù)制鏈路有毛刺，復(fù)制延遲最高達(dá)到4s，但是大部分的復(fù)制鏈路的延遲大概也是在1秒或1秒以下。我的分享到此結(jié)束了，謝謝大家。Q&AQ1：你好，想問(wèn)一下餓了么是怎么避免各個(gè)機(jī)房中的PK沖突的？A1：主鍵自增的步長(zhǎng)在各個(gè)機(jī)房中是固定相同的，但是每個(gè)機(jī)房的增長(zhǎng)offset是不同的，所以不會(huì)出現(xiàn)PK沖突。Q2：DRC復(fù)制會(huì)不會(huì)對(duì)目標(biāo)數(shù)據(jù)庫(kù)造成性能影響？A2：有影響。因?yàn)镈RC會(huì)占用目標(biāo)DB的IOPS。DRC Apply本身就是目標(biāo)DB的上層服務(wù)。Q3：DRC Applier采用JDBC去寫目標(biāo)DB，除了這個(gè)辦法還有其它途徑嗎？A3：目前我們分析binlog還原事務(wù)，然后通過(guò)JDBC把事務(wù)寫到目