一、前言

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

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

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

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

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

2.1 應(yīng)用上云

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

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

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

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

只讀場景

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

讀寫場景

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

2.3 上云成本

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

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

2.4 小結(jié)

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

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

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

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

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

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

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

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

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

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

1）架構(gòu)升級

DRC中有2個核心功能需要跨公網(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，負責在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)一的解決方案，參見《攜程Redis海外機房數(shù)據(jù)同步實踐?》，開源地址：https://github.com/ctripcorp/x-pipe，歡迎關(guān)注。

延遲監(jiān)控

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

Proxy Client

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

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

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

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

心跳檢測

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

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

流量控制

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

運營商線路

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

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

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

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

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

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

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

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

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

位點記錄

海外復(fù)制業(yè)務(wù)集群需要新增復(fù)制庫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ù)庫UUID號
• gno：事務(wù)id。該列值為0的行為匯總行
• gtidset：對于gno=0的匯總行，該列批量存儲gno編號，例如server_uuid:1-10:20:30

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

循環(huán)阻斷

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

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

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

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

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

庫表映射

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

行過濾

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

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

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

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

過濾類型

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

過濾參數(shù)

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

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

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

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

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

表過濾

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

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

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

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

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

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

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

Dal Cluster原理

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

2）流量切分

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

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

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

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

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

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

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

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

四、未來規(guī)劃

• 為了支持更多Binlog消費方，支持消息投遞；

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