轉(zhuǎn)載:餓了么MySQL異地多活的數(shù)據(jù)雙向復(fù)制經(jīng)驗(yàn)談（附PPT）

本文根據(jù)陳永庭老師在〖DAMS 2017中國數(shù)據(jù)資產(chǎn)管理峰會〗現(xiàn)場演講內(nèi)容整理而成讨跟。

（點(diǎn)擊底部“閱讀原文”獲取陳永庭演講完整PPT）

講師介紹

陳永庭骂远，餓了么框架工具部高級架構(gòu)師蜈块，主要負(fù)責(zé)MySQL異地雙向數(shù)據(jù)復(fù)制，支撐餓了么異地多活項(xiàng)目酪碘。曾就職于WebEx、Cisco、騰訊等公司管呵。

今天我主要分享餓了么多活的底層數(shù)據(jù)實(shí)施，會和大家介紹在整個多活的設(shè)計和實(shí)施過程中我們是怎么處理異地數(shù)據(jù)同步的哺窄，而這個數(shù)據(jù)同步組件在我們公司內(nèi)部稱之為DRC捐下。

異地多活背景

在講DRC或者講數(shù)據(jù)復(fù)制之前，先跟大家回顧一下異地多活的背景萌业。

去年我們在做多活調(diào)研的時候坷襟，整個公司所有的業(yè)務(wù)服務(wù)都是部署在北京機(jī)房，服務(wù)器大概有四千多臺生年，災(zāi)備的機(jī)器是在云端婴程，都是虛擬機(jī)，大概有三千多臺抱婉。當(dāng)時我們峰值的業(yè)務(wù)訂單數(shù)量已經(jīng)接近了千萬級別排抬，但是基本上北京機(jī)房（IDC）已經(jīng)無法再擴(kuò)容了懂从，也就是說我們沒有空余的機(jī)架，沒有辦法添加新的服務(wù)器了蹲蒲，必須要再建一個新的機(jī)房番甩，于是我們在上海建一個新的機(jī)房，上海機(jī)房要在今年的4月份才會投入使用届搁，所以需要在上海機(jī)房建成之后缘薛，異地多活項(xiàng)目能具備在生產(chǎn)環(huán)境上進(jìn)行灰度。

異地多活的底層數(shù)據(jù)同步實(shí)施

這是異地多活的底層數(shù)據(jù)同步實(shí)施的一個簡單的概要圖卡睦，大家可以看到宴胧，我們有兩個機(jī)房，一個是北京機(jī)房表锻，一個是上海機(jī)房恕齐。在這個時候，我們期望目標(biāo)是北方所有的用戶請求瞬逊、用戶流量全部進(jìn)入北京機(jī)房显歧，南方所有的用戶請求、用戶流量進(jìn)入上海機(jī)房确镊。困難的地方是士骤，這個用戶有可能今天在北方，明天在南方蕾域，因?yàn)樗诔霾羁郊。€有就是存在一些區(qū)域在我們劃分南北shard的時候，它是在邊界上面的旨巷，這種情況會加劇同一個用戶流量在南北機(jī)房來回漂移的發(fā)生巨缘。還有個情況，當(dāng)我們某個機(jī)房出現(xiàn)故障采呐，如核心交換機(jī)壞掉導(dǎo)致整個機(jī)房服務(wù)不可用若锁，我們希望可以把這個機(jī)房的所有流量快速切到另外的數(shù)據(jù)中心去，從而提高整個餓了么服務(wù)的高可用性懈万。

以上所有的因素拴清，都需要底層數(shù)據(jù)庫的數(shù)據(jù)之間是打通的。而今天我所要分享的DRC項(xiàng)目就是餓了么異地MySQL數(shù)據(jù)庫雙向復(fù)制的組件服務(wù)会通，即上圖中紅色框標(biāo)記的部分口予。

異地多活對底層數(shù)據(jù)的要求

我們在前期調(diào)研DRC實(shí)現(xiàn)的時候，主要總結(jié)了的三點(diǎn)涕侈，而在后續(xù)的設(shè)計和實(shí)施當(dāng)中沪停，基本上也是圍繞這三點(diǎn)來去解決問題。

第一個我們覺得是延遲要低，當(dāng)時給自己定的目標(biāo)是秒級的木张，我們希望在北京機(jī)房或上海機(jī)房寫入的數(shù)據(jù)众辨，需要在1秒鐘之內(nèi)同步到上海或者北京機(jī)房舷礼。整個延遲要小于1秒鐘鹃彻。

第二個就是我們要確保數(shù)據(jù)的一致性，數(shù)據(jù)是不能丟也不能錯的妻献，如果出現(xiàn)數(shù)據(jù)的不一致性蛛株，可能會給上層的業(yè)務(wù)服務(wù)、甚至給產(chǎn)品帶來災(zāi)難性的問題育拨。

第三個就是保證整個復(fù)制組件具備高吞吐處理能力谨履，指的是它可以面對各種復(fù)雜的環(huán)境，比方說業(yè)務(wù)正在進(jìn)行數(shù)據(jù)的批量操作熬丧、數(shù)據(jù)的維護(hù)笋粟、數(shù)據(jù)字典的變更情況，這些會產(chǎn)生瞬間大量的變更數(shù)據(jù)析蝴，DRC需要面對這種情況害捕，需要具備高吞吐能力去扛住這些情況。

數(shù)據(jù)低延遲和一致性之間嫌变，我們認(rèn)為主要從數(shù)據(jù)的并發(fā)復(fù)制這個策略上去解決吨艇，安全躬它、可靠腾啥、高效的并發(fā)策略，才能保證數(shù)據(jù)是低延遲的復(fù)制冯吓，在大量數(shù)據(jù)需要復(fù)制時倘待，DRC并發(fā)處理才能快速在短時間內(nèi)解決。數(shù)據(jù)一致性组贺，用戶的流量可能被路由到兩個機(jī)房的任何一個機(jī)房去，也就是說同樣一條記錄可能在兩個機(jī)房中被同時更改，所以DRC需要做數(shù)據(jù)沖突處理掷倔，最終保持?jǐn)?shù)據(jù)一致性纬朝，也就是數(shù)據(jù)不能出錯。如果出現(xiàn)沖突且DRC自身無法自動處理沖突掀潮，我們還提供了一套數(shù)據(jù)沖突訂正平臺菇夸，會要求業(yè)務(wù)方一道來制定數(shù)據(jù)訂正規(guī)則。

高吞吐剛才已經(jīng)介紹了仪吧，正常情況用戶流量是平穩(wěn)的庄新，DRC是能應(yīng)對的，在1秒鐘之內(nèi)將數(shù)據(jù)快速復(fù)制到對端機(jī)房。當(dāng)DBA對數(shù)據(jù)庫數(shù)據(jù)進(jìn)行數(shù)據(jù)歸檔择诈、大表DDL等操作時械蹋，這些操作會在短時間內(nèi)快速產(chǎn)生大量的變更數(shù)據(jù)需要我們復(fù)制，這些數(shù)據(jù)可能遠(yuǎn)遠(yuǎn)超出了DRC的最大處理能力羞芍，最終會導(dǎo)致DRC復(fù)制出現(xiàn)延遲哗戈，所以DRC與現(xiàn)有的DBA系統(tǒng)需要進(jìn)行交互，提供一種彈性的數(shù)據(jù)歸檔機(jī)制荷科，如當(dāng)DRC出現(xiàn)大的復(fù)制延遲時谱醇，終止歸檔JOB，控制每輪歸檔的數(shù)據(jù)規(guī)模步做。如DRC識別屬于大表DDL產(chǎn)生的binlog events副渴，過濾掉這些events，避免這些數(shù)據(jù)被傳輸?shù)狡渌麢C(jī)房全度，占用機(jī)房間帶寬資源煮剧。

以上是我們在實(shí)施異地多活的數(shù)據(jù)層雙向復(fù)制時對DRC項(xiàng)目提出的主要要求。

數(shù)據(jù)集群規(guī)模（多活改造前）

這是我們在做多活之前的北京數(shù)據(jù)中心的數(shù)據(jù)規(guī)模将鸵，這個數(shù)據(jù)中心當(dāng)時有超過250套MySQL的集群勉盅，一千多臺MySQL的實(shí)例，Redis也超過四百個集群顶掉。

DRC服務(wù)的目標(biāo)對象就是這250套MySQL集群草娜，因?yàn)樵谡诮ㄔO(shè)的第二個數(shù)據(jù)中心里未來也會有對應(yīng)的250套MySQL集群，我們需要把兩個機(jī)房業(yè)務(wù)對等的集群進(jìn)行數(shù)據(jù)打通痒筒。

多活下MySQL的用途分類

我們按照業(yè)務(wù)的用途宰闰，給它劃分了多種DB服務(wù)類型。為什么要總結(jié)這個呢簿透？因?yàn)橛幸恍╊愋鸵婆郏覀兪遣恍枰獜?fù)制的，所以要甄別出來老充，首先第一個多活DB葡盗，我們認(rèn)為它的服務(wù)需要做多活的。

比方說支付啡浊、訂單觅够、下單，一個機(jī)房掛了巷嚣，用戶流量切到另外新的機(jī)房喘先，這些業(yè)務(wù)服務(wù)在新的機(jī)房是工作的。我們把這些多活服務(wù)依賴的DB稱為多活DB涂籽，我們優(yōu)先讓業(yè)務(wù)把DB改造成多活DB苹祟，DRC對多活DB進(jìn)行數(shù)據(jù)雙向復(fù)制，保障數(shù)據(jù)一致性。多活DB的優(yōu)勢剛才已經(jīng)講了树枫，如果機(jī)房出現(xiàn)故障直焙、核心交換機(jī)出問題，整個機(jī)房垮了砂轻，運(yùn)維人員登不進(jìn)機(jī)房機(jī)器奔誓，那么我們可以在云端就把用戶流量切到其它的機(jī)房。有些業(yè)務(wù)對數(shù)據(jù)有強(qiáng)一致性要求搔涝，后面我會講到其實(shí)DRC是沒有辦法做到數(shù)據(jù)的強(qiáng)一致性要求的厨喂，它是有數(shù)據(jù)沖突發(fā)生的，需要引入數(shù)據(jù)訂正措施庄呈。

業(yè)務(wù)如果對數(shù)據(jù)有強(qiáng)一致性要求蜕煌，比方說用戶注冊，要求用戶登錄名全局唯一（DB字段上可能加了唯一約束）诬留，兩個機(jī)房可能會在同一時間接收了相同用戶登錄名的注冊請求斜纪，這種情況下，DRC是無法自身解決掉這個沖突文兑，而且業(yè)務(wù)方對這個結(jié)果也是無法接受的盒刚，這種DB我們會把它歸納到GlobalDB里面，它的特性是什么呢绿贞？

它的特性是單機(jī)房可寫因块，多機(jī)房可讀，因?yàn)槟阋ＷC數(shù)據(jù)的強(qiáng)一致性的話籍铁，必須讓所有機(jī)房的請求處理結(jié)果涡上，最終寫到固定的一個機(jī)房中。這種DB的上層業(yè)務(wù)服務(wù)寨辩，在機(jī)房掛掉之后是有損的吓懈。比方說機(jī)房掛了歼冰，用戶注冊功能可能就不能使用了靡狞。

最后一個非多活DB，它是很少的隔嫡，主要集中于一些后端的管理平臺甸怕，這種項(xiàng)目本身基本上不是多活的，所以這種DB我們不動它腮恩，還是采用原生的主備方式梢杭。

DRC總體架構(gòu)設(shè)計

這是DRC復(fù)制組件的總體架構(gòu)設(shè)計。我們有一個組件叫Replicator秸滴，它會從MySQL集群的Master上把binlog日志記錄抽取出來武契，解析binlog記錄并轉(zhuǎn)換成我們自定義的數(shù)據(jù)，存放到一個超大的event buffer里面，event buffer支持TB級別的容量咒唆。

在目標(biāo)機(jī)房里我們會部署一個Applier服務(wù)届垫，這個服務(wù)啟一個TCP長連接到Replicator服務(wù)，Replicator會不斷的推送數(shù)據(jù)到Applier全释，Applier通過JDBC最終把數(shù)據(jù)寫入到目標(biāo)數(shù)據(jù)庫装处。我們會通過一個Console控制節(jié)點(diǎn)來進(jìn)行配置管理、部署管理以及進(jìn)行各個組件的HA協(xié)調(diào)工作浸船。

DRC Replicator Server

這是DRC Replicator Server組件比較細(xì)的結(jié)構(gòu)描述妄迁，主要是包含了一個MetaDB模塊，MetaDB主要用來解決歷史的Binlog的解析問題李命。

我們成功解析Binlog記錄之后登淘，會把它轉(zhuǎn)換成我們自己定義的一種數(shù)據(jù)結(jié)構(gòu)，這種結(jié)構(gòu)相對于原生的結(jié)構(gòu)封字，Size更小形帮，MySQL binlog event的定義在size角度上考慮事實(shí)上已經(jīng)很極致了，但是可以結(jié)合我們自己的特性周叮，我們會把不需要的event全部過濾掉（如table_map_event）辩撑，把可以忽略的數(shù)據(jù)全部忽略掉。我們比對的結(jié)果是需要復(fù)制的event數(shù)據(jù)只有原始數(shù)據(jù)size的70%仿耽。

DRC Applier Server

往目標(biāo)的MySQL集群復(fù)制寫的時候合冀，由DRC Applier Server負(fù)責(zé)，它會建一個長連接到Replicator上去项贺，Replicator PUSH數(shù)據(jù)給Applier君躺。Applier把數(shù)據(jù)拿到之后做事務(wù)的還原，最后通過JDBC把事務(wù)重新寫到目標(biāo)DB里面开缎，寫的過程當(dāng)中棕叫，我們應(yīng)用了并發(fā)的策略。

并發(fā)策略在提供復(fù)制吞吐能力奕删，降低復(fù)制延遲起到?jīng)Q定的作用俺泣，還有冪等也是非常重要的，后面有很多運(yùn)維操作完残，還有一些Failover回退操作伏钠，會導(dǎo)致發(fā)生數(shù)據(jù)被重復(fù)處理的情況，冪等操作保障重復(fù)處理數(shù)據(jù)不會發(fā)生問題谨设。

DRC防止循環(huán)復(fù)制

在做復(fù)制的時候熟掂，大家肯定會碰到解決循環(huán)復(fù)制的問題。我們在考慮這個問題的時候扎拣，查了很多資料赴肚，也問了很多一些做過類似項(xiàng)目的前輩素跺，當(dāng)時我們認(rèn)為有兩大類辦法，第一大類辦法一開始否決了誉券，因?yàn)槲覀儗ySQL的內(nèi)核原碼不熟悉亡笑，而且時間上也來不及，雖然我們知道通過MySQL的核內(nèi)解決回路復(fù)制是最佳的横朋、最優(yōu)的仑乌。

靠DRC自身解決這個問題，也有兩種辦法琴锭，一種辦法是我們在Apply數(shù)據(jù)到目標(biāo)DB的時候把binlog關(guān)閉掉晰甚，另外一種辦法就是寫目標(biāo)DB的時候在事物中額外增加checkpoint表的數(shù)據(jù)，用于記錄源DB的server_id决帖。

后來我們比較了一下厕九，第一個辦法是比較簡單，實(shí)現(xiàn)容易地回，但是因?yàn)锽inlog記錄沒有產(chǎn)生扁远，導(dǎo)致不支持級聯(lián)復(fù)制，也對后續(xù)的運(yùn)維帶來麻煩刻像。所以我們最后選擇的是第二個辦法畅买，通過把事務(wù)往目標(biāo)DB復(fù)制的時候，在事務(wù)中hack一條checkpoint的數(shù)據(jù)來標(biāo)識事務(wù)產(chǎn)生的原始server细睡，DRC在解析MySQL binlog記錄時就能正確分辨出數(shù)據(jù)的真正來源谷羞。

DRC數(shù)據(jù)一致性保障

在剛開始研發(fā)、設(shè)計的時候溜徙，數(shù)據(jù)一致性保障是我們很頭疼的問題湃缎。并不是在一開始就把所有的點(diǎn)都想全了，是在做的過程當(dāng)中出現(xiàn)了問題蠢壹，一步步解決的嗓违，回顧一下，我們大概從三個方面去保證數(shù)據(jù)的一致性：

首先图贸，因?yàn)閿?shù)據(jù)庫是多活的蹂季，我們必須從數(shù)據(jù)中心層面盡可能把數(shù)據(jù)沖突發(fā)生的概率降到最低，避免沖突求妹，怎么避免呢乏盐？就是合理的流量切分，你可以按照用戶的維度制恍，按照地域的維度，對流量進(jìn)行拆分神凑。剛才我們講的净神，北方用戶的所有數(shù)據(jù)在北京機(jī)房何吝，這些北方用戶的下單、支付等的所有操作數(shù)據(jù)都是在北方機(jī)房產(chǎn)生的鹃唯，所以用戶在同一個機(jī)房中發(fā)生的數(shù)據(jù)變更操作絕對是安全的爱榕。我們最怕的是同一個數(shù)據(jù)同時或者是在相近的時間里同時在兩個機(jī)房被修改，我們怕的是這個問題坡慌，因?yàn)檫@種情況就會引發(fā)數(shù)據(jù)沖突黔酥。所以我們通過合理的流量切分，保證絕大部分時候數(shù)據(jù)是不會沖突的洪橘。

第二個我們認(rèn)為你要保障數(shù)據(jù)一致性跪者，首先你要確保數(shù)據(jù)不丟，一旦發(fā)生可能數(shù)據(jù)丟失的情況熄求，我們會做一個比較保險的策略渣玲，就是把數(shù)據(jù)復(fù)制的時間位置回退，即使重復(fù)處理數(shù)據(jù)弟晚，也避免丟數(shù)據(jù)的可能忘衍，但是這個時候會帶來數(shù)據(jù)重復(fù)處理的問題，所以數(shù)據(jù)的冪等操作特別重要卿城。

這些都是我們避免數(shù)據(jù)發(fā)生沖突的方法枚钓，那沖突實(shí)際上是不可避免的，沖突發(fā)生后瑟押，我們怎么解決秘噪？最終采用的辦法是在數(shù)據(jù)庫表上隱含地加一個時間字段(數(shù)據(jù)最后更新時間)，這個字段對業(yè)務(wù)是透明的勉耀，主要用來輔助DRC復(fù)制指煎，一旦數(shù)據(jù)發(fā)生沖突，DRC復(fù)制組件可以通過這個時間來判斷兩個機(jī)房或者三個機(jī)房中的哪條數(shù)據(jù)是最后被更新的便斥，最新優(yōu)先的原則至壤，誰最后的修改時間是最新的，就以它為準(zhǔn)枢纠。

DRC數(shù)據(jù)復(fù)制低延遲保障

剛才我們講的是數(shù)據(jù)的一致性像街，還有一個點(diǎn)非常重要，就是數(shù)據(jù)復(fù)制的低延遲保障晋渺。我們現(xiàn)在延遲包括用戶高峰時間也是小于1秒的镰绎，只有在凌晨之后，各種歸檔木西、批量數(shù)據(jù)處理畴栖、DDL變更等操作會導(dǎo)致DRC延遲出現(xiàn)毛刺和抖動。如果你的延遲很高的話八千，第一在做流量切換時吗讶，因?yàn)檫\(yùn)維優(yōu)先保障產(chǎn)品服務(wù)的可用性燎猛，在不得以的情況會不考慮你的復(fù)制延遲，不會等數(shù)據(jù)復(fù)制追平之后再切流量照皆，所以你的數(shù)據(jù)沖突的概率就變的很大重绷。

為了保證復(fù)制低延遲，我們認(rèn)為主要策略膜毁、或者你在實(shí)施時主要的做法還是并發(fā)昭卓，因?yàn)槟阒挥杏酶咝У陌踩牟l(fā)復(fù)制策略，服務(wù)才有足夠的吞吐處理能力瘟滨，而不至于你的復(fù)制通道因?yàn)橛龅健昂Ａ俊睌?shù)據(jù)而導(dǎo)致數(shù)據(jù)積壓候醒，從而加劇了復(fù)制延遲的產(chǎn)生。

我們一開始采用的基于表級別的并發(fā)室奏，但是表級別的并發(fā)在很多情況下火焰，并發(fā)策略沒辦法被有效的利用，比方說有的業(yè)務(wù)線的數(shù)據(jù)庫可能90%的數(shù)據(jù)集中在一張表或者是幾個表里面胧沫，而大部分表數(shù)據(jù)量很小昌简，那基于表的并發(fā)策略就并發(fā)不起來了。我們現(xiàn)在跑的是基于行級別的并發(fā)绒怨，這種并發(fā)它更能容忍和適應(yīng)很多場景纯赎。

DRC & MySQL Master切換

這個是DRC復(fù)制組件與MySQL集群的關(guān)系關(guān)聯(lián)圖，一旦MySQL集群里面的Master發(fā)生了主備切換南蹂，原來的Master掛了犬金，DRC怎么處理？目前的解決方案是DBA系統(tǒng)的MHA工具會通知DRC控制中心六剥，DRC的控制中心會找到對應(yīng)的復(fù)制鏈路晚顷，然后把復(fù)制鏈路從老的Master切到新的Master，但是關(guān)鍵點(diǎn)是MHA在通知之前先把老的Master設(shè)置為不可寫疗疟，阻斷DRC可能往老的Master繼續(xù)寫數(shù)據(jù)该默。

DRC線上運(yùn)行狀況（規(guī)模）

這個是我們DRC上線之后的運(yùn)行狀況。現(xiàn)在大概有有將近400多條復(fù)制鏈路策彤。這個復(fù)制鏈路是指單向的鏈路栓袖。我們提供的消息訂閱大概有17個業(yè)務(wù)方接入，每天產(chǎn)生超過1億條的消息店诗。

DRC線上運(yùn)行狀況（性能）

這是DRC線上運(yùn)行的一個性能監(jiān)控快照裹刮，我們可以看到，它是上午11點(diǎn)多到12點(diǎn)多的一個小時的性能庞瘸，你會發(fā)現(xiàn)其實(shí)有一個DB是有毛刺的捧弃，有一個復(fù)制鏈路有毛刺，復(fù)制延遲最高達(dá)到4s恕洲，但是大部分的復(fù)制鏈路的延遲大概也是在1秒或1秒以下塔橡。

我的分享到此結(jié)束了梅割，謝謝大家霜第。

Q&A

Q1：你好葛家，想問一下餓了么是怎么避免各個機(jī)房中的PK沖突的？

A1：主鍵自增的步長在各個機(jī)房中是固定相同的泌类，但是每個機(jī)房的增長offset是不同的癞谒，所以不會出現(xiàn)PK沖突。

Q2：DRC復(fù)制會不會對目標(biāo)數(shù)據(jù)庫造成性能影響刃榨？

A2：有影響弹砚。因?yàn)镈RC會占用目標(biāo)DB的IOPS。DRC Apply本身就是目標(biāo)DB的上層服務(wù)枢希。

Q3：DRC Applier采用JDBC去寫目標(biāo)DB桌吃，除了這個辦法還有其它途徑嗎？

A3：目前我們分析binlog還原事務(wù)苞轿，然后通過JDBC把事務(wù)寫到目標(biāo)DB茅诱。我們曾經(jīng)模擬過MySQL的binlog server，讓目標(biāo)DB啟動一個Replication連接到我們偽造的binlog server上搬卒，我們的binlog server會把binlog記錄發(fā)給目標(biāo)DB瑟俭，這個辦法會存在很多問題，我們就放棄了這個辦法契邀。

Q4：有監(jiān)測數(shù)據(jù)一致性的工具嗎摆寄？

A4：這個是有的。DBA團(tuán)隊(duì)開發(fā)了一套checksum工具來實(shí)時監(jiān)測數(shù)據(jù)一致性坯门。

Q5：餓了么做異地雙活主要的原因就是剛剛提到的單個機(jī)房是無法擴(kuò)容嗎微饥？

A5：是的。

Q6：雙向同步后期的運(yùn)維成本高嗎古戴？

A6：對DBA的運(yùn)維會造成影響欠橘，DBA的歸檔job、DDL發(fā)布等操作都需要考慮DRC的雙向同步因素允瞧。