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

標籤：MySQL

上一篇：mongodb在雙活（主備）機房的部署方案和切換方案設計

下一篇：DRC資料庫雙向同步復制