本文根據洪斌10月27日在「3306π」技術 Meetup - 武漢站現場演講內容整理而成。
主要內容：
本次分享將介紹目前數據遷移、數據同步、數據消費，多IDC架構中數據複製技術所面臨問題及現有的產品和方案，並分享新開源的能在異構數據存儲之間提供高性能和強大複製功能的DTLE相關技術內容。
提綱：
1. MySQL Replication
2. DTLE核心場景
3. DTLE設計原則
4. DTLE相關介紹（架構/集羣機制/拓撲結構/技術棧/功能/限制）
5. 同類對比
6. Demo演示
7. 雲間同步案例
大家好，我今天分享的主題是關於愛可生在前不久開源的數據傳輸中間件DTLE，也可簡稱爲DTS。愛可生作爲一家以MySQL爲主的技術服務公司，在我們服務企業客戶過程中，經常會遇到各種數據同步的需求，能做數據同步的軟件很多，但未能找到滿足我們所有需求的軟件，所以我們決定自研一款數據傳輸軟件，結合我們客戶的需求場景做了DTLE，並選擇在10月24號“程序員節”向社區開源。
今天主要是對DTLE的一些技術架構，跟大家分享。
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地址：https://github.com/actiontech/dtle
4.1 DTLE架構
DTLE架構上包含兩種角色的進程，Agent角色與Manager角色。Manager角色主要負責元數據信息存儲，任務的接收和分發，Agent節點健康狀態檢測、故障轉移。Agent主要負責數據讀取，binlog解析，數據篩選、壓縮、傳輸、回放等。
用戶通過http協議訪問Manager發佈job，job是以json格式的配置項，裏面定義了源數據庫實例，目標數據庫實例，需要複製的schema或table對象，數據的篩選條件等信息，任務提交後manager會分配給可用的agent進程，agent根據任務配置連接數據庫實例，開始全量或增量的數據同步。
4.2 DTLE的集羣機制
DTLE 的manager節點可以部署多個冗餘節點，節點之間的元數據信息同步和故障切換都是利用Raft分佈式一致性協議來保障的。
woker節點接收來自Manager發來的任務請求，並實時上報自己的狀態。當Manager的Leader節點發現worker無響應時，會通知可用的agent繼續執行同步任務。
4.3 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/dtle_demo
感興趣的同學可以自己動手測試！
7.雲間同步案例
我們做了一個雲間同步的測試，源端是阿里雲RDS，目標端是京東雲RDS，分別在華北區，和華東區。
使用TPCC的模型插入20個倉庫，所有表加起來大概約10億條記錄。全量數據同步完耗時約5小時，平均是1000+ row/s，這裏有關於該測試job的github地址，感興趣的同學可以自己測試下。
job鏈接：
https://gist.github.com/kevinbin/718ecdfa9434c7ac544f4685c7d53a6c
未來我們還會繼續去做其他雲廠商RDS的測試，以上是我今天的分享內容，謝謝大家！
我們的開源數據傳輸中間件DTLE是具有專業團隊維護和支持的，在使用過程中遇到任何Bug和疑難問題都可以得到及時的修復和解答，歡迎加入DTLE技術交流（852990221）！
PPT下載鏈接：
github.com/actiontech/slides