隨著企業規模的擴大，對資料庫可用性要求越來越高，更多企業採用兩地三中心、異地多活的架構，以提高資料庫的異常事件應對能力。

在資料庫領域，我們常聽的“兩地三中心”、“異地多活”到底是什麼呢？

“兩地三中心”就是生產數據中心、同城災備中心、異地災備中心。這種模式下，兩個地域的三個數據中心互聯互通，當一個數據中心發生異常，其他數據中心可以正常運行併進行業務接管。

“異地多活”就是在多個地域建設多個數據中心， 業務數據能夠在三個及以上的數據中心之間進行雙向同步。異地多活架構具有更高的可用性，抗風險能力極強。

不同數據中心可以接管並恢復業務的前提是多個數據中心無差別，彼此之間可以實時同步數據。通過騰訊雲 DTS 數據同步功能可以實現這一訴求。本文將向您介紹通過騰訊雲 DTS 數據同步功能實現兩地三中心架構的方案以及關鍵原理。

架構介紹

利用騰訊雲DTS數據同步可構建下圖中的兩地三中心架構，其中1~4分別為一條單向的數據同步鏈路；A為生產數據中心，B為同城的災備中心，C為異地的災備中心。

圖：兩地三中心架構示例

關鍵問題

在上圖所示的兩地三中心架構中，數據同步需要解決以下四個關鍵問題：

• 單向鏈路中存量數據和增量數據的同步
• 通過單向鏈路構建的複雜拓撲中迴環問題的處理
• 如何保證三個節點數據一致
• 同步延遲問題

解決方案

1. 單向鏈路中存量數據和增量數據的同步

單向同步鏈路是兩地三中心、多活數據架構的基礎。為了使單向鏈路的目標節點數據和源頭節點一致，既要複製存量數據，又要持續同步增量數據。對於線上系統，源端往往不停地有業務數據寫入，為了得到一份一致性的存量數據，往往需要對源端進行加鎖，比如FTWRL或者備份鎖，這也是mydumper，xtrabackup等備份工具採用的方案。加鎖的弊端在於會影響源庫的業務寫入，這在一些場景下是無法接受的。針對這個問題騰訊雲 DTS 提出了一種無鎖方案，即存量數據導出時不對源庫加鎖，在回放增量數據時修複存量數據的不一致，最終達到源和目標數據的一致性。

DTS在發起數據同步任務的同時，會接管源端的Binlog，然後將Binlog在目標端進行回放，在同步任務期間源端的SQL操作，會重覆在目標端執行一遍。

這跟MySQL Replication主從複製的原理是類似的，通常MySQL為一主多從的架構形式，主庫Master負責數據寫入，從庫Slave負責數據讀取，從庫的IO線程將主庫上的變化寫入到本地Relay log，SQL線程讀取Relay log在從庫上進行回放，從而實現主從數據同步。

圖：MySQL Replication主從複製原理圖

MySQL這種讀寫分離的模式可以大大減少主庫的訪問壓力，但靈活性較差，篩選功能不足。

DTS在主從複製架構的基礎上，引入靈活的拓撲結構，支持一對多、多對一、聯級單向、雙向同步、聯級環形同步等，可滿足各種複雜的資料庫同步場景的應用，如兩地三中心、異地多活等。

2. 解決數據迴環問題

數據同步中會遇到迴環問題，以如下環形同步為例，對A進行SQL操作，A同步到B，B再同步到C，C又同步給A，A會重覆處理該SQL操作，進而陷入無限迴圈中，所以如何進行數據破環，是雙向同步、環形同步等必須要解決的問題。

圖：數據迴環問題

DTS通過在環形拓撲中做標記，從而識別出來接收到的SQL是否已執行過，達到破環的目的。在其他的拓撲結構，如雙向同步、聯級環形同步都可以通過做標記來實現破環。

3. 保證三節點數據一致

在兩地三中心數據架構中，會有兩個或三個節點需要同時進行數據寫入，保證多個節點的一致性至關重要。

3.1 規劃主鍵分區

在兩地三中心的場景中實現數據一致性，常見的方法就是規劃主鍵分區。主鍵分區即多個寫入的資料庫“各司其職“，各自負責更新不同的主鍵數據，從源頭上避免產生主鍵衝突。例如A節點上負責更新ID為1、3、5的主鍵數據，B節點上負責更新ID為2、4、6的主鍵數據。

如果實際業務部分數據存在耦合，無法進行主鍵分區，則可能產生主鍵衝突。DTS支持對衝突進行處理，並提供如下三種衝突策略：

衝突報錯

同步任務中，源庫插入（INSERT）主鍵數據與目標庫存在衝突時，任務報錯並暫停，需要用戶手動處理後才能繼續。

衝突處理時SQL語句改寫如下：
INSERT不改寫
UPDATE 不改寫
DELETE 不改寫

衝突忽略

同步任務中檢測到源庫的主鍵插入（INSERT）數據與目標庫發生衝突時，忽略源庫的主鍵插入數據，以目標庫的內容為準。

衝突處理時SQL語句改寫如下
INSERT -> INSERT IGNORE
UPDATE 不改寫
DELETE 不改寫

衝突覆蓋

同步任務中檢測到源庫的主鍵更新（INSERT和UPDATE）數據與目標庫發生衝突時，用源庫的主鍵數據覆蓋目標的主鍵數據。

衝突處理時SQL語句改寫如下：
INSERT -> REPLACE INTO
UPDATE -> DELETE + REPLACE INTO
DELETE 不改寫

這裡首先需要明確的是，DTS衝突策略的應用，僅針對發生主鍵衝突時的數據，應用後可以按用戶設置的策略進行處理，使任務報錯提醒給用戶或者繼續運行。不產生衝突的場景，如下圖的UPDATE和所有的DELETE主鍵操作，源端的操作都會正常同步到目標端，DTS不會幹預。

圖：不產生衝突的場景下，DTS不幹預

如果沒有主鍵分區，多個源端INSERT同一條主鍵數據引起衝突時，DTS可以按照衝突策略來干預，但多個源端對同一條主鍵數據進行正常的UPDATE時（如上圖，沒有衝突），DTS不會幹預，這樣可能會出現，目標端的數據被重覆刷新或者隨意刷新（不能確定最終刷新的結果是哪個節點同步過來的），同一條主鍵數據在多個節點顯示的不一致。

綜上，要實現多節點數據一致性，進行主鍵分區是非常有效的方法，可以從源頭上避免數據產生衝突。

3.2 兩地三中心數據同步應用

下麵結合兩地三中心的數據架構，介紹數據一致性如何保證，以及通過設置衝突策略來處理衝突問題。

圖：兩地三中心架構示例

圖中1-4為DTS的一條單向同步鏈路，1、2構成A<->B的雙向同步，3、4構成A->C之間的雙向同步。

A、B同時負責數據寫入，提前規劃好A、B各自負責更新的主鍵數據，例如A負責更新主鍵ID為1-100的數據，B負責更新主鍵ID為101-200的數據。

衝突策略給出如下推薦，用戶在實際的場景中可以根據業務的情況進行靈活選擇。

• 如果希望發生INSERT主鍵衝突時DTS給出提示用戶手動處理，則4條鏈路都設置衝突報錯。

• 如果希望INSERT主鍵時以A的為準，則A->B、A->C設置為衝突覆蓋，B->A、C->A設置為衝突忽略。（不能保證UPDATE主鍵和DELETE主鍵操作也以A的為準）

4. 同步延遲問題

目標資料庫相對於源資料庫的延遲也是DTS 關註的一個重要問題，當 DTS 同步數據的速度達不到源端寫入速度，就會出現延遲，這在某些場景下會影響業務對目標資料庫的使用。

騰訊雲 DTS 採用全新自研內核，對同步性能做了極致的優化，能滿足大部分實際業務場景下對同步性能的需求。

如下為當前DTS同步任務中不同規格的RPS參考（RPS表示DTS每秒同步至目標表的數據行數）。
表：DTS同步任務中不同規格的RPS上線參考
micro 1000
small 2000
medium 5000
large >5000

在實際業務場景中，RPS可能會受源和目標資料庫的運行負載、DTS 訪問源和目標資料庫的網路延時、網路帶寬等多種因素的影響。騰訊雲 DTS 經過優化，對網路延時的容忍度較高，在一些跨地域的場景中也能保持較好的性能。如果用戶需要更高的傳輸性能，也可以通過專線接入、VPN接入等方式，保證數據傳輸過程中的網路延時和帶寬質量。

總結

騰訊雲DTS已具備實時數據同步、迴環處理、數據衝突處理、高性能傳輸等能力，可根據企業需求靈活定製多種同步拓撲架構，用於兩地三中心、異地多活等場景的數據同步。