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

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

「兩地三中心」就是生產資料中心、同城災備中心、異地災備中心。這種模式下，兩個地域的三個資料中心互聯互通，當一個資料中心發生異常，其他資料中心可以正常執行並進行業務接管。

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

不同資料中心可以接管並恢復業務的前提是多個資料中心無差別，彼此之間可以實時同步資料。通過騰訊雲 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已具備實時資料同步、迴環處理、資料衝突處理、高效能傳輸等能力，可根據企業需求靈活客製化多種同步拓撲架構，用於兩地三中心、異地多活等場景的資料同步。