一、前言

在攜程國(guó)際化戰(zhàn)略背景下，海外業(yè)務(wù)將成為新的發(fā)力點(diǎn)，為了保證用戶高品質(zhì)的服務(wù)體驗(yàn)，底層數(shù)據(jù)勢(shì)必需要就近服務(wù)業(yè)務(wù)應(yīng)用。一套標(biāo)準(zhǔn)且普適的數(shù)據(jù)復(fù)制解決方案能夠提升業(yè)務(wù)決策效率，助力業(yè)務(wù)更快地觸達(dá)目標(biāo)用戶。

DRC (Data Replicate Center) 作為攜程內(nèi)部數(shù)據(jù)庫(kù)上云標(biāo)準(zhǔn)解決方案，支撐了包括但不限于即時(shí)通訊、用戶賬號(hào)、IBU在內(nèi)的核心基礎(chǔ)服務(wù)和國(guó)際業(yè)務(wù)順利上云。

二、業(yè)務(wù)上云場(chǎng)景

業(yè)務(wù)上云前，要先要思考2個(gè)問(wèn)題：

• 數(shù)據(jù)庫(kù)是否需要上云？
• 在數(shù)據(jù)庫(kù)上云情況下，海外數(shù)據(jù)庫(kù)提供只讀還是讀寫(xiě)操作？

2.1 應(yīng)用上云

針對(duì)用戶延遲不敏感或者離線業(yè)務(wù)，可以采用只應(yīng)用上云數(shù)據(jù)庫(kù)不上云，請(qǐng)求回源國(guó)內(nèi)。該方案下業(yè)務(wù)需要改造應(yīng)用中讀寫(xiě)數(shù)據(jù)庫(kù)操作，根據(jù)應(yīng)用部署地，決定流量是否需要轉(zhuǎn)發(fā)。

不建議海外應(yīng)用直連國(guó)內(nèi)數(shù)據(jù)庫(kù)，網(wǎng)絡(luò)層面專線距離遠(yuǎn)，成本太高，不現(xiàn)實(shí)；安全層面應(yīng)禁止跨海訪問(wèn)，否則可能導(dǎo)致預(yù)期就近訪問(wèn)流量由于非預(yù)期錯(cuò)誤，將海外流量寫(xiě)入國(guó)內(nèi)數(shù)據(jù)庫(kù)，從而引起國(guó)內(nèi)數(shù)據(jù)錯(cuò)誤。

2.2 數(shù)據(jù)庫(kù)上云

對(duì)于在線用戶延遲敏感應(yīng)用，數(shù)據(jù)庫(kù)必須跟隨應(yīng)用一同上云，將請(qǐng)求閉環(huán)在海外，從而就近提供服務(wù)響應(yīng)。在確定數(shù)據(jù)庫(kù)上云的前提下，根據(jù)不同業(yè)務(wù)特點(diǎn)，可再細(xì)分為海外只讀和讀寫(xiě)兩種場(chǎng)景。

只讀場(chǎng)景

對(duì)于海外只讀場(chǎng)景，國(guó)內(nèi)數(shù)據(jù)只需要單向復(fù)制，該方案下業(yè)務(wù)海外賬號(hào)默認(rèn)無(wú)寫(xiě)權(quán)限或者業(yè)務(wù)改造寫(xiě)操作，避免出現(xiàn)由于誤寫(xiě)導(dǎo)致國(guó)內(nèi)海外數(shù)據(jù)不一致。

讀寫(xiě)場(chǎng)景

對(duì)于海外讀寫(xiě)場(chǎng)景，國(guó)內(nèi)海外數(shù)據(jù)需要雙向復(fù)制，業(yè)務(wù)代碼無(wú)需改造。該方案下由于有2個(gè)Master可以寫(xiě)入，業(yè)務(wù)需要在應(yīng)用層對(duì)流量進(jìn)行切分，比如用戶歸屬地維度，從而避免在兩側(cè)同時(shí)修改同一條數(shù)據(jù)，進(jìn)而導(dǎo)致復(fù)制過(guò)程出現(xiàn)數(shù)據(jù)沖突。

2.3 上云成本

數(shù)據(jù)距離用戶越近，應(yīng)用直接提供的服務(wù)功能越豐富，對(duì)應(yīng)業(yè)務(wù)改造量越小，機(jī)器資源消耗量越大。攜程海外應(yīng)用部署在AWS公有云上，AWS入口流量不計(jì)費(fèi)，只針對(duì)出口流量計(jì)費(fèi)。應(yīng)用上云數(shù)據(jù)庫(kù)不上云場(chǎng)景，請(qǐng)求回源國(guó)內(nèi)產(chǎn)生出口流量費(fèi)用；只讀業(yè)務(wù)單方向數(shù)據(jù)復(fù)制流入，不收費(fèi)；讀寫(xiě)業(yè)務(wù)數(shù)據(jù)復(fù)制回國(guó)內(nèi)產(chǎn)生出口流量費(fèi)用。

上云成本主要集中在流量和數(shù)據(jù)庫(kù)費(fèi)用。AWS出口Internet流量0.09$/GB，當(dāng)流量大時(shí)，可通過(guò)數(shù)據(jù)壓縮，損耗復(fù)制延遲降低出口流量；RDS根據(jù)核數(shù)計(jì)費(fèi)，1004元/核/月，業(yè)務(wù)流量少時(shí)采用普通4C16G機(jī)型即可，流量增加后動(dòng)態(tài)提升配置。核心業(yè)務(wù)RDS配置一主一從，非核心業(yè)務(wù)單主即可，并且多個(gè)DB可共用一個(gè)集群，進(jìn)而降低成本。

2.4 小結(jié)

為了提供高品質(zhì)的用戶體驗(yàn)，數(shù)據(jù)勢(shì)必需要上云。在解決了是否上云的問(wèn)題后，如何上云就成為新的疑問(wèn)點(diǎn)。下面就詳細(xì)分析攜程內(nèi)部上云過(guò)程中依賴的數(shù)據(jù)庫(kù)復(fù)制組件DRC實(shí)現(xiàn)細(xì)節(jié)。

三、數(shù)據(jù)庫(kù)上云方案

DRC基于開(kāi)源模式開(kāi)發(fā)，公司內(nèi)部生產(chǎn)版本和開(kāi)源保持一致，開(kāi)源地址https://github.com/ctripcorp/drc?，歡迎關(guān)注。

DRC孵化于異地多活項(xiàng)目，參見(jiàn)《攜程異地多活-MySQL實(shí)時(shí)雙向（多向）復(fù)制實(shí)踐》?，解決國(guó)內(nèi)異地機(jī)房間數(shù)據(jù)庫(kù)同步問(wèn)題。當(dāng)其中一個(gè)或多個(gè)機(jī)房位置轉(zhuǎn)變?yōu)楣性茣r(shí)，伴隨著物理距離的擴(kuò)大，新的問(wèn)題應(yīng)運(yùn)而生。

就DRC自身架構(gòu)實(shí)現(xiàn)而言：

• 公有云和國(guó)內(nèi)機(jī)房間互不聯(lián)通，同步鏈路被物理阻斷
• 公網(wǎng)傳輸不如國(guó)內(nèi)跨機(jī)房之間專線質(zhì)量，丟包頻發(fā)
• 公有云數(shù)據(jù)庫(kù)自主運(yùn)維靈活性下降，如無(wú)法獲取root權(quán)限，直接導(dǎo)致set gtid_next無(wú)法正常工作

就業(yè)務(wù)接入而言：

• 國(guó)內(nèi)海外數(shù)據(jù)隔離，按需復(fù)制成為剛需
• 公有云數(shù)據(jù)庫(kù)成本壓力導(dǎo)致混部，一對(duì)一復(fù)制不再滿足業(yè)務(wù)靈活多變的真實(shí)部署場(chǎng)景

基于以上限制，DRC調(diào)整架構(gòu)，引入代理模塊解決網(wǎng)絡(luò)聯(lián)通性問(wèn)題，借用事務(wù)表降低復(fù)制鏈路對(duì)權(quán)限的要求；為了適應(yīng)業(yè)務(wù)的多樣性，分別從庫(kù)、表和行維度支持按需復(fù)制。

3.1 架構(gòu)改造挑戰(zhàn)

1）架構(gòu)升級(jí)

DRC中有2個(gè)核心功能需要跨公網(wǎng)傳輸數(shù)據(jù)：

• 業(yè)務(wù)Binlog數(shù)據(jù)復(fù)制
• DRC內(nèi)部延遲監(jiān)控探針

數(shù)據(jù)復(fù)制

以單向復(fù)制為例，在Binlog拉取模塊Replicator和解析應(yīng)用模塊Applier之間引入Proxy，負(fù)責(zé)在TCP層將內(nèi)網(wǎng)/公網(wǎng)流量轉(zhuǎn)發(fā)到公網(wǎng)/內(nèi)網(wǎng)。Proxy綁定公網(wǎng)IP，采用TLS協(xié)議加密傳輸內(nèi)網(wǎng)流量。鑒于公網(wǎng)質(zhì)量不穩(wěn)定特性，Proxy使用BBR擁塞控制算法，優(yōu)化丟包引起的卡頓。

Proxy作為公網(wǎng)數(shù)據(jù)傳輸攜程內(nèi)部統(tǒng)一的解決方案，參見(jiàn)《攜程Redis海外機(jī)房數(shù)據(jù)同步實(shí)踐?》，開(kāi)源地址：https://github.com/ctripcorp/x-pipe，歡迎關(guān)注。

延遲監(jiān)控

延遲監(jiān)控探針從業(yè)務(wù)流量同側(cè)機(jī)房的Console寫(xiě)入到業(yè)務(wù)數(shù)據(jù)庫(kù)延遲監(jiān)控表(初始化時(shí)新建)，經(jīng)過(guò)雙向復(fù)制鏈路，從異側(cè)機(jī)房接收延遲探針，從而計(jì)算差值得到復(fù)制延遲。為了提升Proxy間隔離性，數(shù)據(jù)復(fù)制和延遲監(jiān)控可以分別配置不同的Proxy實(shí)例實(shí)現(xiàn)數(shù)據(jù)傳輸。

Proxy Client

由于Applier和Console都需要對(duì)接Proxy，如何降低Proxy對(duì)DRC系統(tǒng)的侵入性就成為一個(gè)需要解決的問(wèn)題。為此我們借助Java Agent技術(shù)，動(dòng)態(tài)修改字節(jié)碼，實(shí)現(xiàn)了可插拔的接入方式。接入方只需要引入proxy-client獨(dú)立Jar包，業(yè)務(wù)層按需實(shí)現(xiàn)Proxy的注冊(cè)和注銷。

2）網(wǎng)絡(luò)優(yōu)化

公網(wǎng)網(wǎng)絡(luò)丟包和擁塞頻發(fā)，為了在弱網(wǎng)環(huán)境下實(shí)現(xiàn)平穩(wěn)復(fù)制，就需要快速地異常檢測(cè)恢復(fù)機(jī)制。除了在系統(tǒng)層將Proxy擁塞控制算法優(yōu)化為BBR外，DRC在應(yīng)用層額外增加：

• 心跳檢測(cè)，實(shí)現(xiàn)連接自動(dòng)切換
• 流量控制，避免突增流量引起資源耗盡進(jìn)而影響數(shù)據(jù)復(fù)制
• 2條互備海外出口運(yùn)營(yíng)商線路，隨機(jī)切換

心跳檢測(cè)

Binlog生產(chǎn)方Replicator定時(shí)對(duì)下游消費(fèi)方進(jìn)行心跳檢測(cè)，消費(fèi)方接收到心跳檢測(cè)需回復(fù)響應(yīng)，Replicator根據(jù)最后一次接收時(shí)間檢測(cè)并自動(dòng)關(guān)閉長(zhǎng)期沒(méi)有響應(yīng)的連接。

這里有一種場(chǎng)景需要特別處理，當(dāng)下游消費(fèi)方比較忙，主動(dòng)關(guān)閉連接auto_read屬性時(shí)，由于應(yīng)用層無(wú)法讀取暫存在緩沖區(qū)的心跳包，從而造成無(wú)法響應(yīng)。這就需要消費(fèi)方在auto_read改變時(shí)，主動(dòng)上報(bào)生產(chǎn)方自身的auto_read狀態(tài)。

流量控制

公網(wǎng)網(wǎng)絡(luò)質(zhì)量下降導(dǎo)致復(fù)制延遲變大，數(shù)據(jù)堆積在發(fā)送端Proxy，進(jìn)而引起Replicator和Proxy觸發(fā)流控；MySQL性能抖動(dòng)，應(yīng)用Binlog速度減緩，數(shù)據(jù)堆積在Applier，進(jìn)而引起Applier觸發(fā)流控并逐層反饋到Replicator。

運(yùn)營(yíng)商線路

針對(duì)Proxy出口IP，分別配置移動(dòng)和聯(lián)通兩條運(yùn)營(yíng)商線路，當(dāng)Binlog消費(fèi)方由于觸發(fā)空閑檢測(cè)出現(xiàn)超時(shí)重連時(shí)，Proxy會(huì)隨機(jī)選擇一個(gè)運(yùn)營(yíng)商出口IP，從而實(shí)現(xiàn)運(yùn)營(yíng)商線路的互備。

3）事務(wù)表復(fù)制

國(guó)內(nèi)機(jī)房間數(shù)據(jù)復(fù)制時(shí)，DBA可以給予DRC擁有root權(quán)限的賬號(hào)，以實(shí)現(xiàn)Applier模擬原生Slave節(jié)點(diǎn)set gtid_next工作方式應(yīng)用Binlog，從而將一個(gè)事務(wù)變更從源機(jī)房復(fù)制到目標(biāo)機(jī)房，并且在兩端分配到同一個(gè)gtid下。但是公有云上RDS出于安全原因是無(wú)法開(kāi)放root權(quán)限，直接從原理上否定了原有的復(fù)制方案。

為了找到合理的替換方案，我們首先從MySQL服務(wù)端視角分析下set gtid_next的效果：

• 事務(wù)在提交后會(huì)被分配指定的gtid值，否則MySQL服務(wù)端會(huì)自動(dòng)分配一個(gè)gtid值
• gtid值加入MySQL服務(wù)端全局變量gtid_executed中

其根本性作用在于將DRC指定的gtid值保存到MySQL系統(tǒng)變量。既然無(wú)法利用MySQL系統(tǒng)變量，那么從業(yè)務(wù)層增加一個(gè)復(fù)制變量保存gtid信息即可實(shí)現(xiàn)同等效果。

其次，轉(zhuǎn)換到DRC復(fù)制視角，set gtid_next起到如下作用：

• 記錄Applier復(fù)制消費(fèi)位點(diǎn)，并以此向Replicator請(qǐng)求Binlog
• 解決循環(huán)復(fù)制，Replicator根據(jù)gtid_event中的uuid判斷是否是DRC復(fù)制產(chǎn)生的事件

綜上分析，新的替代方案需要引入持久化變量，記錄復(fù)制位點(diǎn)并且能夠提供循環(huán)阻斷信息功效，為此DRC引入基于事務(wù)表的同步方案解決了海外復(fù)制難題。

位點(diǎn)記錄

海外復(fù)制業(yè)務(wù)集群需要新增復(fù)制庫(kù)drcmonitordb，其中新建事務(wù)表gtid_executed。

CREATE TABLE `drcmonitordb`.`gtid_executed` (
  `id` int(11) NOT NULL,
  `server_uuid` char(36) NOT NULL,
  `gno` bigint(20) NOT NULL,
  `gtidset` longtext,
  PRIMARY KEY (`id`,`server_uuid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

• server_uuid：源端數(shù)據(jù)庫(kù)UUID號(hào)
• gno：事務(wù)id。該列值為0的行為匯總行
• gtidset：對(duì)于gno=0的匯總行，該列批量存儲(chǔ)gno編號(hào)，例如server_uuid:1-10:20:30

當(dāng)Applier應(yīng)用SQL到目標(biāo)數(shù)據(jù)庫(kù)前，需要先更新事務(wù)表，記錄gtid，然后再執(zhí)行事務(wù)中變更語(yǔ)句，完整的復(fù)制流程如下圖所示。事務(wù)表中g(shù)no=0行中g(shù)tidset等效MySQL系統(tǒng)變量gtid_executed，Applier執(zhí)行過(guò)程中定時(shí)匯總非0行事務(wù)gno，從而達(dá)到記錄位點(diǎn)功能。

循環(huán)阻斷

針對(duì)Binlog中第一個(gè)寫(xiě)事件是事務(wù)表gtid_executed操作的事務(wù)，Replicator將其判斷為DRC復(fù)制數(shù)據(jù)，從而阻斷循環(huán)復(fù)制，否則一條數(shù)據(jù)會(huì)在雙向復(fù)制環(huán)內(nèi)無(wú)限死循環(huán)。

3.2 業(yè)務(wù)落地挑戰(zhàn)

至此DRC解決了理論上阻礙復(fù)制的已知技術(shù)問(wèn)題，在實(shí)際業(yè)務(wù)落地過(guò)程中，出于數(shù)據(jù)安全、費(fèi)用和改造成本的考慮，業(yè)務(wù)對(duì)數(shù)據(jù)復(fù)制提出了更精細(xì)化控制的需求。

1）數(shù)據(jù)隔離

出于合規(guī)的要求，業(yè)務(wù)上云后，需要完成國(guó)內(nèi)和海外用戶數(shù)據(jù)的隔離。業(yè)務(wù)上云前，國(guó)內(nèi)和海外用戶數(shù)據(jù)全部在國(guó)內(nèi)數(shù)據(jù)庫(kù)；上云時(shí)就需要將海外用戶數(shù)據(jù)單獨(dú)復(fù)制到公有云而過(guò)濾掉國(guó)內(nèi)用戶數(shù)據(jù)。

庫(kù)表映射

上云前國(guó)內(nèi)和海外數(shù)據(jù)在同一張母表。為了上云，業(yè)務(wù)通過(guò)在國(guó)內(nèi)數(shù)據(jù)庫(kù)新增子表，實(shí)現(xiàn)國(guó)內(nèi)數(shù)據(jù)的分離。海外由于只存在海外數(shù)據(jù)，所以物理上只需要一張母表即可，即國(guó)內(nèi)子表與海外母表相對(duì)應(yīng)，搭建DRC實(shí)現(xiàn)雙向復(fù)制即可。由于母表和子表表名不同，復(fù)制時(shí)需要做庫(kù)表映射，從而屏蔽應(yīng)用層對(duì)不同表名的感知，降低業(yè)務(wù)改造量。

行過(guò)濾

庫(kù)表映射不涉及數(shù)據(jù)過(guò)濾，經(jīng)過(guò)DRC的流量都會(huì)進(jìn)行復(fù)制，因此映射在Applier端處理，直接根據(jù)映射規(guī)則替換表名即可。為此業(yè)務(wù)需要進(jìn)行2處改造：

• 人工分離國(guó)內(nèi)機(jī)房國(guó)內(nèi)和海外數(shù)據(jù)
• 為了使國(guó)內(nèi)母表保存全量數(shù)據(jù)，海外用戶數(shù)據(jù)經(jīng)過(guò)DRC復(fù)制回國(guó)內(nèi)時(shí)，需要通過(guò)觸發(fā)器自動(dòng)同步到母表

為了進(jìn)一步降低業(yè)務(wù)改造量，DRC提供行過(guò)濾功能，用戶無(wú)需進(jìn)行業(yè)務(wù)改造，只需保證表中包含Uid字段即可，DRC根據(jù)Uid自動(dòng)判斷數(shù)據(jù)歸屬地，進(jìn)行數(shù)據(jù)過(guò)濾。

單向復(fù)制鏈路級(jí)別添加行過(guò)濾配置，其中包括：

過(guò)濾類型

• Uid過(guò)濾，業(yè)務(wù)層面一般通過(guò)Uid維度進(jìn)行拆分，通過(guò)SPI動(dòng)態(tài)加載Uid過(guò)濾實(shí)現(xiàn)，攜程內(nèi)部由于Uid無(wú)特殊標(biāo)記，無(wú)法通過(guò)Uid名稱判斷出歸屬地，只能通過(guò)SOA遠(yuǎn)程調(diào)用實(shí)時(shí)判斷Uid歸屬地獲得過(guò)濾結(jié)果；如果Uid有規(guī)則可循，則可以通過(guò)正則表達(dá)式匹配即可
• Java正則表達(dá)式，支持針對(duì)單字段的Java正則表達(dá)式簡(jiǎn)單匹配計(jì)算，適合單一維度數(shù)值有規(guī)則的業(yè)務(wù)場(chǎng)景
• Aviator表達(dá)式，支持針對(duì)多字段的Aviator表達(dá)式復(fù)雜匹配計(jì)算，適合多維度數(shù)值相關(guān)聯(lián)的業(yè)務(wù)場(chǎng)景

過(guò)濾參數(shù)

包含表到過(guò)濾字段的映射關(guān)系，以及與過(guò)濾類型對(duì)應(yīng)的上下文，比如正則表達(dá)式。

Applier Binlog請(qǐng)求中攜帶行過(guò)濾配置，Replicator根據(jù)過(guò)濾類型加載對(duì)應(yīng)的過(guò)濾規(guī)則，從而計(jì)算出過(guò)濾結(jié)果。

行過(guò)濾在發(fā)送端Replicator實(shí)現(xiàn)，這樣實(shí)現(xiàn)的好處是跨海發(fā)送數(shù)據(jù)量大大降低，但同時(shí)也帶來(lái)了解析和重構(gòu)Rows Event的復(fù)雜性和性能損耗，即先解析Rows Event并根據(jù)過(guò)濾后的行數(shù)據(jù)生成新的Rows Event。Rows Event的解析需要表結(jié)構(gòu)信息，而表結(jié)構(gòu)信息是保存在Binlog的頭中，勢(shì)必在Rows Event前保證能夠獲得對(duì)應(yīng)的表結(jié)構(gòu)；解析后就可以將每行過(guò)濾字段值應(yīng)用到過(guò)濾規(guī)則上，若匹配出需要過(guò)濾的行，則需要根據(jù)過(guò)濾后的行構(gòu)造新的Rows Event并發(fā)送，否則直接發(fā)送即可。

2）數(shù)據(jù)庫(kù)混部

核心業(yè)務(wù)隨著數(shù)據(jù)量的膨脹，會(huì)采用分庫(kù)來(lái)降低數(shù)據(jù)庫(kù)壓力，在公有云部署時(shí)，鑒于云上初始流量不多，并且可動(dòng)態(tài)提升機(jī)器配置，DBA部署時(shí)會(huì)將所有分庫(kù)部署在同一個(gè)RDS集群，此時(shí)復(fù)制從一對(duì)一變成一對(duì)多。

表過(guò)濾

單向復(fù)制鏈路級(jí)別添加庫(kù)表過(guò)濾配置，支持Aviator表達(dá)式。Replicator發(fā)送前，通過(guò)將從Binlog中解析的庫(kù)表名作用于Aviator表達(dá)式從而得到過(guò)濾結(jié)果。

3.3 數(shù)據(jù)庫(kù)上云流程

完整的業(yè)務(wù)上云流程一般分為四步：

• 數(shù)據(jù)庫(kù)先上云，搭建國(guó)內(nèi)海外數(shù)據(jù)庫(kù)復(fù)制，驗(yàn)證海外數(shù)據(jù)可用性和完整性
• 在海外數(shù)據(jù)可用的前提下，應(yīng)用上云，就近訪問(wèn)海外數(shù)據(jù)庫(kù)，驗(yàn)證部署海外應(yīng)用可行性
• 流量路由層灰度業(yè)務(wù)流量，可根據(jù)Uid白名單、流量百分比在流量接入層進(jìn)行灰度，驗(yàn)證業(yè)務(wù)邏輯正確性
• 灰度完成，國(guó)內(nèi)和海外流量完成切分，驗(yàn)證國(guó)內(nèi)和海外業(yè)務(wù)隔離性，為此后下線底層數(shù)據(jù)復(fù)制做準(zhǔn)備

數(shù)據(jù)庫(kù)上云在每一步都有所涉及，第一步通過(guò)DRC解決了數(shù)據(jù)的可用性問(wèn)題，第二步通過(guò)數(shù)據(jù)庫(kù)訪問(wèn)中間件解決了數(shù)據(jù)可達(dá)性問(wèn)題，第三步業(yè)務(wù)通過(guò)流量準(zhǔn)確切分保證數(shù)據(jù)一致性問(wèn)題，第四步國(guó)內(nèi)海外實(shí)現(xiàn)數(shù)據(jù)隔離后，即可下線DRC數(shù)據(jù)復(fù)制。在分析完DRC原理后，下面再分析下其他幾步數(shù)據(jù)庫(kù)相關(guān)問(wèn)題。

1）數(shù)據(jù)訪問(wèn)層

Dal包含中心化配置管理服務(wù)端Dal Cluster和Dal客戶端兩部分。上云前同一個(gè)數(shù)據(jù)庫(kù)物理上只有一個(gè)集群，上云后海外增加相同集群，服務(wù)端Dal Cluster就需要根據(jù)客戶端環(huán)境下發(fā)正確的MySQL配置文件。

Dal Cluster原理

Dal Cluster變更推送功能借由分布式配置中心完成，配置中心提供子環(huán)境功能，國(guó)內(nèi)數(shù)據(jù)庫(kù)配置默認(rèn)放在父環(huán)境，海外數(shù)據(jù)庫(kù)則會(huì)在上線流程中生成對(duì)應(yīng)的子環(huán)境數(shù)據(jù)庫(kù)配置。這樣在Dal Client啟動(dòng)時(shí)，帶有不同環(huán)境配置的客戶端會(huì)拉取到不同的配置，從而實(shí)現(xiàn)數(shù)據(jù)庫(kù)的就近訪問(wèn)，整個(gè)過(guò)程對(duì)業(yè)務(wù)透明，代碼無(wú)需改造。

2）流量切分

業(yè)務(wù)上云一般采用Uid歸屬地進(jìn)行流量切分，當(dāng)流量開(kāi)始灰度后，兩端數(shù)據(jù)庫(kù)都開(kāi)始接收寫(xiě)流量。如果流量灰度不干凈，針對(duì)同一個(gè)Uid數(shù)據(jù)在兩端同時(shí)被修改，則會(huì)導(dǎo)致底層DRC數(shù)據(jù)復(fù)制時(shí)出現(xiàn)數(shù)據(jù)沖突。

當(dāng)沖突發(fā)生時(shí)，Applier默認(rèn)根據(jù)時(shí)間戳進(jìn)行沖突策處理，接入DRC的表都有一個(gè)精確到毫秒自動(dòng)更新的時(shí)間戳，時(shí)間戳最新的數(shù)據(jù)會(huì)被采用，從而實(shí)現(xiàn)數(shù)據(jù)的一致。

3）表結(jié)構(gòu)變更

通過(guò)DRC復(fù)制的集群，在表結(jié)構(gòu)變更流程中，會(huì)自動(dòng)關(guān)聯(lián)到公有云集群，在兩端同時(shí)進(jìn)行變更操作。

由于變更完成時(shí)間有先后，假設(shè)一個(gè)增加字段的變更海外先完成，在國(guó)內(nèi)完成變更前的時(shí)間范圍內(nèi)，針對(duì)該表海外到國(guó)內(nèi)的復(fù)制將出現(xiàn)復(fù)制沖突，默認(rèn)DRC會(huì)捕獲該異常，并從異常信息中提取出列名，將多出的列從SQL中移除后再執(zhí)行，從而自動(dòng)處理掉沖突。

當(dāng)國(guó)內(nèi)集群完成表結(jié)構(gòu)變更后，新增列的值在兩端都為默認(rèn)值，數(shù)據(jù)仍然一致。

3.4 業(yè)務(wù)落地成果

• 海外數(shù)據(jù)庫(kù)復(fù)制從2021年11月上線至今，接入公司90+復(fù)制集群；
• 上海?新加坡AWS復(fù)制平均延遲90ms，上海?法蘭克福AWS復(fù)制平均延遲260ms；
• 賬號(hào)集群通過(guò)庫(kù)表映射，常旅、收藏等通過(guò)行過(guò)濾實(shí)現(xiàn)用戶數(shù)據(jù)隔離；
• 通過(guò)一對(duì)多部署，公有云/國(guó)內(nèi)機(jī)房MySQL集群比維持在1/5，DRC復(fù)制成本/MySQL集群成本維持在2/5；

四、未來(lái)規(guī)劃

• 為了支持更多Binlog消費(fèi)方，支持消息投遞；

• DRC當(dāng)前只支持增量數(shù)據(jù)的實(shí)時(shí)復(fù)制，后續(xù)會(huì)支持存量數(shù)據(jù)的復(fù)制以及敏感數(shù)據(jù)的初始化過(guò)濾，覆蓋業(yè)務(wù)上云過(guò)程中更多數(shù)據(jù)復(fù)制場(chǎng)景；
• Replicator作為有狀態(tài)實(shí)例，使用本地磁盤(pán)保存Binlog，公有云使用的塊存儲(chǔ)本身即是分布式存儲(chǔ)系統(tǒng)，Replicator可探究存儲(chǔ)架構(gòu)改造，實(shí)現(xiàn)主備共用同一份存儲(chǔ)，從而降低使用成本。