MySQL開源資料傳輸中介軟體架構設計實踐
本文根據洪斌10月27日在「3306π」技術 Meetup - 武漢站現場演講內容整理而成。
主要內容：
本次分享將介紹目前資料遷移、資料同步、資料消費，多IDC架構中資料複製技術所面臨問題及現有的產品和方案，並分享新開源的能在異構資料儲存之間提供高效能和強大複製功能的DTLE相關技術內容。
提綱：
大家好，我今天分享的主題是關於愛可生在前不久開源的資料傳輸中介軟體DTLE，也可簡稱為DTS。愛可生作為一家以MySQL為主的技術服務公司，在我們服務企業客戶過程中，經常會遇到各種資料同步的需求，能做資料同步的軟體很多，但未能找到滿足我們所有需求的軟體，所以我們決定自研一款資料傳輸軟體，結合我們客戶的需求場景做了DTLE，並選擇在10月24號“程式員節”向社群開源。
今天主要是對DTLE的一些技術架構，跟大家分享。
1. MySQL Replication
MySQL如此受歡迎，其原因和MySQL原生支援了 Replication密不可分。基於replication能力社群也是玩出了各種拓撲架構。
1.1 MySQL Replication架構
這張圖對DBA們應該並不陌生，左邊是MySQL主例項，右邊是MySQL從例項，資料變更記錄在binlog中。主例項的Dump執行緒，將binlog 事件通過網路推送給從例項。
從例項的IO執行緒將接收到事件寫入本地relay log，SQL執行緒讀取relay log bing進行回放執行，這是MySQL Replication的基本流程。
既然MySQL已經有了資料同步能力，那為何還要做DTLE呢？
1.2 MySQL Replication的限制
- 篩選功能不足
MySQL Replication只能在庫表級別做篩選，無法在行級別進行篩選。
- 資料落地，開銷較大
MySQL Replication需要日誌或資料落地，這會產生儲存空間的開銷。
- 靈活性較弱
無法支援較為複雜的複製拓撲結構，以及在跨網路邊界不同資料中心場景的。
- 應用場景多為高可用
MySQL replication更多以高可用、讀寫分離應用場景為主，利用開源工具實現Master failover以及讀寫分離架構。
2. DTLE的核心場景
MySQL Replication主要應用在資料全同步的場景。而對於DTLE主要解決以下場景：
- 異地多活
異地多活的場景通常建立在網路環境不佳的條件下，我們通過資料壓縮、加密、限速等方法，保障複製的可靠性、安全性、效率。解鎖跨網路邊際、雙向同步等能力，在業務配合下，實現異地多活的。
- 資料匯聚分發
資料的匯聚和分發，需要支援到庫、表、行這幾個級別。比如：在業務垂直分庫場景下可將前端多個分庫例項彙總到例項中進行統計分析。資料行按不同條件分發到下游節點，條件可以是簡單的where條件，也可是簡單函式表示式等。
- 資料訂閱
資料訂閱的場景是對MySQL binlog日誌進行解析，將增量變化實時同步給Kafka訊息佇列，其他系統通過kafka訂閱需要的資料。
- 線上資料遷移
線上資料遷移，要簡化MySQL到MySQL或其他DB到MySQL的遷移過程，減少停機時間，目前還只支援MySQL間的遷移。首先抽取全量的資料，並獲取增量起始的快照點，當全量回放完畢後，從增量起始點開始同步增量資料。
這對MySQL分散式架構的資料分片擴容特別有幫助，一般我們將先預分片好的物理分片放在相同MySQL例項中，當資料量增長超過例項處理能力時，就需要講分片遷移到新的例項節點，遷移過程肯定希望儘量平滑不影響業務。DTLE可以配合我們之前開源分散式中介軟體DBLE，進行線上擴容 。
- 雲間同步
公有云RDS使用者會有一些上下雲和雲間遷移同步的需求，我們測試了幾家雲廠商，針對雲廠商自研的RDS for MySQL的特點，實現不同雲廠商的RDS之間進行資料同步。
3. DTLE設計原則
以上是DTLE主要的應用場景。軟體設計DTLE力求兩個基本原則：易用性與可靠性 。
- 易用性
作為軟體的使用者和開發者，我們特別重視產品的使用體驗，上手簡單，易於部署 是必須的，沒有複雜的部署條件要求，沒有外部依賴，安裝配置步驟越簡單越好，儘可能符合使用者的操作習慣。
- 可靠性
可靠性也必不可少，我們將DTLE的設計採用分散式的架構，具備扛單點風險和故障切換的能力 。元資料資訊儲存在分散式一致性KV儲存中，如果某工作節點或程序掛了，工作任務會轉移至其他程序繼續之前的斷點處理資料同步，不影響服務連續性。
4. DTLE相關介紹
DTLE （Data-Transformation-le） 是愛可生10月24日在“程式設計師節”貢獻開源社群的 CDC 工具，主要具備以下特點：
•多種資料傳輸模式 ：支援鏈路壓縮，支援同構傳輸和異構傳輸，支援跨網路邊際的傳輸
•多種資料處理理模式 ：支援庫/表/行級別 資料過濾
•多種資料通道模式 ：支援多對多的資料傳輸、支援迴環傳輸
•多種源/目標端 ：支援MySQL - MySQL的資料傳輸，支援MySQL - Kafka的資料傳輸
•叢集模式部署
•提供可靠的元資料儲存
•可進行自動任務分配
•支援自動故障轉移
Github地址：ofollow,noindex" target="_blank">https://github.com/actiontech...
4.1 DTLE架構
DTLE架構上包含兩種角色的程序，Agent角色與Manager角色。Manager角色主要負責元資料資訊儲存，任務的接收和分發，Agent節點健康狀態檢測、故障轉移。Agent主要負責資料讀取，binlog解析，資料篩選、壓縮、傳輸、回放等。
使用者通過http協議訪問Manager釋出job，job是以json格式的配置項，裡面定義了源資料庫例項，目標資料庫例項，需要複製的schema或table物件，資料的篩選條件等資訊，任務提交後manager會分配給可用的agent程序，agent根據任務配置連線資料庫例項，開始全量或增量的資料同步。
4.2 DTLE的叢集機制
DTLE支援的多種拓撲結構，最簡單的1對1同步，n對1的匯聚同步模式，1對n的資料分發同步模式。
在跨資料中心的場景，虛線框內是兩個不同的資料中心，DTLE部署在不同的資料中心，DTLE負責本資料中心的資料讀取或回放，DTLE將資料壓縮後通過網路傳送到對端，減少了對頻寬的利用，適用於窄頻寬的網路環境下。
在跨資料中心有多個例項之間需要資料同步，如果通過MySQL Replication需要建立多條鏈路通道，而通過DTLE可以在資料中心間建立一條通道同步多個例項的資料，網路策略配置更簡單，也避免了MySQL服務對外暴露。
跨資料中心的雙向同步能力，可以應用在資料中心雙活的場景，但資料層自身還無法做衝突檢測，需要在應用層來保障資料不會衝突。
4.4 DTLE技術棧
在DTLE的開發過程中我們藉助了一些優秀的開源元件，來支撐起整個架構。
我們選用的開發語言是Golang ，它的好處是開發效率高，效能有保障，部署也方便，build後的二進位制檔案自帶執行時環境，完全不需要擔心軟體依賴問題。
網上有許多優秀的Golang開源專案，Hashicorp公司就是其中一家以分散式應用見長的開源軟體公司，他們開發了很多優秀的DevOps 基礎設施元件，包括Vagrant、Packer 、 Terraform 、Serf 、Consul , Vault 和 Nomad 等，我們使用了部分元件來構建DTLE。
nomad是一個叢集管理器和排程器，我們利用它來構建基礎架構，解決的任務排程和叢集管理的問題，在此基礎上我們開發所需的任務模板。
consul是一個分散式KV儲存，nomad也集成了consul，我們用它來做manager元資料資訊儲存。
serf是基於gossip協議的節點狀態檢測元件，能夠快速檢測到故障節點並踢出叢集，主要用來解決agent節點的failover，如果某個agent節點不可用，這個節點就會被移出叢集。
NATS是一款開源的輕量級訊息系統元件，我們在agent之間的資料傳遞使用了NATS。
以上是DTLE採用的開源元件。如果之前對這些元件由所瞭解，可以幫助理解DTLE的架構原理。
4.5 DTLE功能
DTLE的回放是支援binlog回放和SQL回放。binlog回放不需要對binlog事件進行轉換，可以直接在MySQL中回放，精度高，但無法做資料轉換或篩選。SQL回放是直接把binlog事件解析成SQL文字，可以進行資料的轉換和篩選。
我們模仿了MySQL MTS並行回放機制，基於MySQL 5.7的邏輯時鐘模式，提高並行回放的效率。
自動建表，在資料遷移的場景下，目標端不需要事先建立表結構，只需要定義好job需要同步的物件，DTLE會自動建表並同步存量資料。
DTLE的全部功能總結：
- 叢集式架構部署，支援故障轉移
- binlog回放、SQL回放
- 仿MySQL MTS機制並行回放
- 支援增量斷點續傳
- 全量&增量同步
- 庫級、表級、行級篩選
- 鏈路壓縮、跨網路邊際
- 自動建表
- 支援DDL
4.6 DTLE限制
- 僅支援 MySQL 5.6/5.7 版本
- 僅支援 InnoDB 引擎
- 僅支援以下字符集: latin1、latin2、gbk、utf8、utf8mb4、binary
- 僅支援binlog_format=row和binlog_row_image=full
- 源端和目標端lower_case_table_names配置必須保持⼀一致
- 必須開啟 GTID
- 不支援 Trigger
- 僅支援MySQL認證方式 mysql_native_password, 暫不支援其他型別的
default_authentication_plugin
5. 同類對比
我們選取了其他同類的開源軟體debezium、streamsets、otter、DTLE，一起橫向對比了相關特性。
- 全量/增量
debezium是支援全量增量的，對於streamsets和otter他們並沒有全量支援，只能做一些增量資料的支援，DTLE支援全量和增量。
- 元資料全域性一致性
元資料資訊的全域性一致性是指在做全量資料遷移時如何獲得增量資料起始的一致性位點。debezium是通過全域性讀鎖或者快照讀索實現的。streamsets和otter不支援全量，所以也不用考慮這個場景。
DTLE沒有使用全域性讀鎖，它在快照讀的事務中讀取存量資料，並在事務開啟前後分別獲取GTID。如果前後兩個GTID是相等的，意味著在這個事務開啟之後即使沒有新的更新，後續可以從此GTID做增量同步。如果說前後兩個GTID不等，事務將回滾，再重複上述流程。
- 資料過濾
在資料過濾方面，debezium支援庫級， streamsets支援行級，otter可以自定義，DTLE是庫、表、行三個等級都支援。
- 資料對映
資料對映上，debezium能夠支援到表級的對映到普通表之間，原表、錄入表可能不同的表之間可以進行資料對映。同樣streamsets也是，otter也可以靈活自定義。DTLE當前不支援資料對映，還在Roadmap中。
- 事務性
在MySQL binlog中一個事務可能包含多個event，我們選擇相容在回放時保持其事務性。debezium可以做到源端的事物性，但不支援目標端的事務性。streamsets本身是沒有事務性的，按event產生進行回放。otter不保持回放的事務性，為了提高入庫的效率會進行合併操作。DTLE其實目標端和源端都可以保證事務性。
- GTID
DTLE會維護一份獨立的GTID資訊，主要來解決一些環形複製場景。其他三者都是不維護GTID資訊的。
- 源端型別
源端型別，debezium支援的資料型別比較多，包括MySQL、Mongo、PostgreSQL、Oracle這幾種都支援。MySQL是基於binlog，mongo是基於 Oplog，其他幾種PG，SQL sever應該是通過CDC的方式，而非基於日誌方式。streamsets支援許多中資料來源，不詳細展開了，otter主要是MySQL。DTLE還只是支援MySQL一種資料庫。
- 目標端型別
debezium僅限於Kafka作為目標端。streamsets支援很多的目標端，不再詳細展開。otter支援 MySQL和Oracle，DTLE當前僅支援MySQL和Kafka。
- 部署方式
在部署方式上，debezium和streamsets都是單節點，otter是叢集化的部署方式，DTLE支援單機和叢集化部署。
6.DEMO演示
我這裡準備了一些演示用例，主要演示以下幾個場景，單向同步，表級匯聚，資料分發以及跨IDC雙向複製。
Demo演示指令碼：https://github.com/kevinbin/d...
感興趣的同學可以自己動手測試！
7.雲間同步案例
我們做了一個雲間同步的測試，源端是阿里雲RDS，目標端是京東雲RDS，分別在華北區，和華東區。
使用TPCC的模型插入20個倉庫，所有表加起來大概約10億條記錄。全量資料同步完耗時約5小時，平均是1000+ row/s，這裡有關於該測試job的github地址，感興趣的同學可以自己測試下。
未來我們還會繼續去做其他雲廠商RDS的測試，以上是我今天的分享內容，謝謝大家！
我們的開源資料傳輸中介軟體DTLE是具有專業團隊維護和支援的，在使用過程中遇到任何Bug和疑難問題都可以得到及時的修復和解答，歡迎加入DTLE技術交流群（852990221）！
PPT下載連結： github.com/actiontech/slides