DRC數據庫雙向同步復制

DRC介紹

餓了么的 Data Replicate Center（DRC）項目用於數據雙向復制和數據訂閱，使用場景如下圖：

要點說明：

• 跨機房的 Mysql 數據復制完全通過 DRC 來完成

• 還有很多業務團隊通過 DRC 來實現數據訂閱

目前餓了么100%的跨機房數據復制，90%的數據訂閱都通過DRC完成，每天有大量的數據流經DRC。復制延遲保持在1s以下，從來沒有發生過數據丟失和錯亂的情況。

 

DRC的設計目標包括：

1. 實時雙向數據復制，延時 < 1s ，並能夠解決雙向修改時的數據沖突

2. 數據變更訂閱，能夠在DB數據發生變化時通知到相關訂閱方

3. 高度可靠和保持順序，不能丟失數據，也不能因為錯亂執行順序導致數據錯誤

我們最終達到了這3個目標，下面圍繞着如何設計以滿足以上目標介紹一下。

 

DRC的總體設計

DRC采用了多組件的集群化設計，整體結構如下圖：

要點說明：

• DRC有兩個核心服務，Replicator 和 Apply，他們以集群化的方式部署，一個負責從源頭數據庫拉取變更，一個負責應用變更到目標數據庫。

• Master Replicator目前實現了 Mysql Binary Log Dump 協議，從Source Mysql 中取得 DataChangeEvent。

• 對於任何唯一的數據源，數據修改事件（DataChangeEvent）需要能夠映射為唯一的單調遞增的SCN（System Change Number），如果不能執行這樣的映射，則DRC的一致性就不能得到保證。

• Replicator接收到 DataChangeEvent 數據后使用一個Heap外的環狀內存結構（MMAP）保存，減少GC負荷，為了保證低延遲的復制，不寫入本地文件。

• Replicator Slave是一種稍微特殊的 Replicator，從 Master Replicator 拉取 DataChangeEvent，並保存到本地EventBuffer中。

• Replicator中保存當前 SCN Number，有一個 Master 和任意多個 Slave ，當 Masters失效后，Slave Replicator 可以選舉新的 Master

• Client SDK 從 Replicator 中拉取 DataChange Event序列，拉取時需要提供當前位置（SCN）和過濾條件，過濾條件支持基於庫名，或者表名的過濾。

• Replicator 中不保存任何 Client SDK 相關的狀態信息（SCN），該信息由 Client SDK 調用方維護。

• Data Apply負責把ChangeEvent按照需要的格式應用到數據庫中，需要保持事務一致性，按照SCN的順序執行。

其中 SCN 和 DataChangeEvent 是整個DRC的兩個核心概念，需要詳細說明一下：

SCN是一個結構體，能夠單調有續，並全局唯一，綁定到唯一的事件上，每當 DRC 從 Mysql 拿到一個新的 Data Change Event，就會分配一個新的 SCN 與之對應。

每種數據源對應於一種 SCN 的結構，對於 Mysql 數據源的SCN結構體代碼如下：

SCN要求單調有續，並全局唯一，所以SCN 的產生邏輯大部分情況下需要綁定到數據源的唯一邏輯上，例如 Mysql 的 SCN 實現就嵌入了 mysql 的 serverid，logIndex，logPostion，這樣能保證對於一個唯一的 mysql server 來說，scn 是單調有序並唯一的，我們還加上了一個 changeId 字段，這樣，如果數據抽取切換到另外一個 mysql 上了，changeId 只需要 +1，就可以保證產生的SCN依然有序，關於 Mysql Bin Log 結構的詳細信息

整個SCN的產生邏輯如下圖：

有了唯一的 SCN 之后，整個系統就有了保證一致性的最基礎保障。SCN是在 Replicator 端生成的，並貫穿了整個 DRC 系統的各個組件，所有的組件都用相同的SCN來標志event，也用SCN來記錄當前復制的位點。

 

下面簡單介紹一下各個組件的要點，以方便之后的介紹。

Replicator： replicator 負責變更事件的抽取，SCN的生成，以及維護了一個Event Buffer 來存儲取到的 event，結構如下圖：

要點說明：

• replicator 有一個 master 多個 slave，只有 master 會連接 DB，其他的 slave 只連接 master replicator。

• SCN在各個Replicator中是一致的，當 master 失效后會選舉出新的 master（zk），並從該 master 的當前位置開始復制，這樣就避免了非常復雜的在多個 replicator 間保持一致的問題。

• Replicator 中不保存客戶端狀態，Client SDK Pull 數據的時候需要指定開始 SCN 位置，所以可以隨時切換到任何一個Replicator拉取數據。

• 如果客戶端提交的SCN超過當前Replicator的最老數據，Replicator 會回源到源頭的數據庫拉取。

• Replicator 在維護了一個 RingBuffer，用於保存 ChangeEvent，這個buffer我們叫做 EventBuffer，EventBuffer 是 DRC 提高性能的一個非常關鍵的環節，之后回詳細說明。

 

Apply ：Apply 部署在目標端，負責把讀取到的數據寫入目標數據庫，或者把變更消息發送到指定的消息隊列中，目前 DRC 支持 Kafka / RabbitMQ / MaxQ 等多種消息隊列。

要點說明：

• Apply 以 Channel 的形式在 DataApply Server 上組織復制單元

• Channel 是一張表或者一組表

• Channel 內部邏輯通過串聯的 Filter 實現

• Change 上實現了諸多的業務邏輯，例如冪等，沖突檢查，並行化性能優化等等。

• 以上就是 DRC 的一個整體介紹，下面說一下 DRC 的實現中一些具體的技術點。

 

DRC 實現

• 數據一致保證

如何保證數據一致：一致性是 DRC 的最基本要求，DRC 通過一系列的方法保證雙向復制中兩邊的數據一致。這其中有三個問題要說一下：

• 問題一：如何防止循環復制？

雙向復制要解決的一個重要問題是循環復制，要能夠識別出一個改變動作是來自產研，還是來自DRC工具本身。來自產研的數據變更需要復制出去，而來自DRC的數據復制不需要復制。

DRC防止沖突的方案是在由DRC產生的事務中加入DRC標記。如下圖的事務2，Apply在寫入時，會在事務的開頭處加上一個 insert 或者是 update 語句，其中包含了 DRC 的信息。當Replicator 發現一個事物包涵該特殊標記時，就不會再復制出去。

這種方式雖然避免了循環復制，帶給目標端數據庫帶來了一些性能開銷，我們會在之后的版本中通過修改 Mysql Binlog 機制來更為高效的阻斷循環復制。

• 問題二：萬一發生中斷或者是故障，如果保證數據正確？

中斷恢復：從中斷恢復，主要靠的是SCN，因為SCN有序，並保存在可靠存儲中，任何節點的失效，都可以通過SCN位點來恢復，SCN可以被保存在本地文件，ZK和數據庫中，達到性能和可靠性的平衡。

冪等：另外，大部分的DB操作在DRC下是冪等的，從任意一點開始，重復執行一次，還是會得到相同的結果。DRC能夠處理各種重復執行帶來的異常，並且保證最終數據始終一致。這里主要靠的是詳細分析各種重復執行可能帶來的異常，對能夠跳過的異常就直接跳過，而不停止復制。

• 問題三：萬一一筆數據在兩邊都修改了，如何解決沖突？

避免沖突：首先我們通過全局定義的規則避免數據沖突，仔細設計的數據規則，讓每筆數據都有自己的歸屬機房，兩個機房同時修改一筆數據的情況很少出現。兩個機房產生的數據在 ID 上是錯開的，各種和業務相關的ID 也通過設計避免了重復，這樣數據復制到一起后，不會發生沖突。對於有唯一鍵索引的數據，我們也進行了改造，加上了用於區別機房的數據字段。

沖突解決：即使如此，有時候沖突還是不可避免的，比如發生機房切換，或者是業務方的代碼有Bug等，所以我們還提供2層沖突解決方案，萬一發生同一筆數據，在兩個機房同時修改，則引入沖突處理：

• 基本的沖突處理，通過時間戳完成，兩邊機房的都有實時同步的毫秒級別的NTP服務，每筆數據上都打上了變更時間戳。在發生沖突的時候，最后發生的修改會勝出，最終兩個機房的數據都會被同步成最后的數據。

• 如果時間戳不能滿足需要，還可以通過調用業務提供的沖突解決方案解決，沖突解決時，為業務方提供了原始數據和最新數據，由業務邏輯來決定哪個數據才是最終正確的數據。

• 但是我們不會對數據進行合並，因為合並帶來的問題比較多，事實上看，基於時間戳已經解決了99%的數據沖突問題。

• 性能優化

DRC 具有非常高的吞吐量，主要歸功於Replicator的本地EventBuffer，幾個月的Event數據都會被緩沖到 EventBuffer 中，EventBuffer 是一個跳表結構，如下圖：

其中跳表的索引是SCN，通過SCN能夠快速的找到對應Event，之后按照順序輸出其后的 Event，每次輸出一批Event，磁盤讀取和網絡傳輸都很高效。

EventBuffer 落地在磁盤上，通過內存映射Map到內存中。Java Heap 中只保存比較少的索引數據，大量的Event數據維持在堆外，避免大內存帶來的GC開銷。大部分 EventBuffer 的大小維持在512G空間，能夠支持數月到數個星期的事件。

EventBuffer 中只保存了二進制的數據，數據的結構被保存在另外一個獨立的存儲中，我們稱為MetaData Store。MetaData Store 保存了每個表的歷史數據格式的快照，每次發生表結構變化，都會創建一個新的快照，結構如下：

要點說明：

• Meta History 記錄了數據結構以及對應的 SCN

• 通過 Meta History，可以回放任意時間點的數據

• 通過 Meta Histroy 的翻譯，可以把數據翻譯成業務需要的格式，或者組裝成對應的SQL