[[198675]]

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

[[198676]]

餓了么異地多活背景

在講 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ī)房，在今年的 4 月份投入使用，所以在上海機(jī)房建成之后，異地多活項目能具備在生產(chǎn)環(huán)境上進(jìn)行灰度。

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

這是異地多活的底層數(shù)據(jù)同步實(shí)施的一個簡單的概要圖，大家可以看到，我們有兩個機(jī)房，一個是北京機(jī)房，一個是上海機(jī)房。

在這個時候，我們期望目標(biāo)是北方所有的用戶請求、用戶流量全部進(jìn)入北京機(jī)房，南方所有的用戶請求、用戶流量進(jìn)入上海機(jī)房。

困難的地方是，這個用戶有可能今天在北方，明天在南方，因為他在出差，還有就是存在一些區(qū)域在我們劃分南北 shard 的時候，它是在邊界上面的，這種情況會加劇同一個用戶流量在南北機(jī)房來回漂移的發(fā)生。

還有個情況，當(dāng)我們某個機(jī)房出現(xiàn)故障，如核心交換機(jī)壞掉導(dǎo)致整個機(jī)房服務(wù)不可用，我們希望可以把這個機(jī)房的所有流量快速切到另外的數(shù)據(jù)中心去，從而提高整個餓了么服務(wù)的高可用性。

以上所有的因素，都需要底層數(shù)據(jù)庫的數(shù)據(jù)之間是打通的。而今天我所要分享的 DRC 項目就是餓了么異地 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 項目提出的主要要求。

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

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

DRC 服務(wù)的目標(biāo)對象就是這 250 套 MySQL 集群，因為在正在建設(shè)的第二個數(shù)據(jù)中心里未來也會有對應(yīng)的 250 套 MySQL 集群，我們需要把兩個機(jī)房業(yè)務(wù)對等的集群進(jìn)行數(shù)據(jù)打通。

多活下 MySQL 的用途分類

我們按照業(yè)務(wù)的用途，給它劃分了多種 DB 服務(wù)類型。為什么要總結(jié)這個呢?因為有一些類型，我們是不需要復(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ī)房可讀，因為你要保證數(shù)據(jù)的強(qiáng)一致性的話，必須讓所有機(jī)房的請求處理結(jié)果，最終寫到固定的一個機(jī)房中。

這種 DB 的上層業(yè)務(wù)服務(wù)，在機(jī)房掛掉之后是有損的。比方說機(jī)房掛了，用戶注冊功能可能就不能使用了。

最后一個非多活 DB，它是很少的，主要集中于一些后端的管理平臺，這種項目本身基本上不是多活的，所以這種 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ù)制的問題。我們在考慮這個問題的時候，查了很多資料，也問了很多一些做過類似項目的前輩，當(dāng)時我們認(rèn)為有兩大類辦法。

第一大類辦法一開始否決了，因為我們對 MySQL 的內(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)容易，但是因為 Binlog 記錄沒有產(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ù)的一致性：

首先，因為數(shù)據(jù)庫是多活的，我們必須從數(shù)據(jù)中心層面盡可能把數(shù)據(jù)沖突發(fā)生的概率降到最低，避免沖突，怎么避免呢?就是合理的流量切分，你可以按照用戶的維度，按照地域的維度，對流量進(jìn)行拆分。

剛才我們講的，北方用戶的所有數(shù)據(jù)在北京機(jī)房，這些北方用戶的下單、支付等的所有操作數(shù)據(jù)都是在北方機(jī)房產(chǎn)生的，所以用戶在同一個機(jī)房中發(fā)生的數(shù)據(jù)變更操作絕對是安全的。

我們最怕的是同一個數(shù)據(jù)同時或者是在相近的時間里同時在兩個機(jī)房被修改，我們怕的是這個問題，因為這種情況就會引發(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ōu)先保障產(chǎn)品服務(wù)的可用性，在不得以的情況會不考慮你的復(fù)制延遲，不會等數(shù)據(jù)復(fù)制追平之后再切流量，所以你的數(shù)據(jù)沖突的概率就變的很大。

為了保證復(fù)制低延遲，我們認(rèn)為主要策略、或者你在實(shí)施時主要的做法還是并發(fā)，因為你只有用高效的安全的并發(fā)復(fù)制策略，服務(wù)才有足夠的吞吐處理能力，而不至于你的復(fù)制通道因為遇到“海量”數(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 秒以下。

[[198678]]

陳永庭

餓了么框架工具部高級架構(gòu)師

主要負(fù)責(zé) MySQL 異地雙向數(shù)據(jù)復(fù)制，支撐餓了么異地多活項目。曾就職于 WebEx、Cisco、騰訊等公司。