1. 關於DataX
1.1. 前言
為什么寫這篇文章，因為初出茅廬的時候，曾經遇到的一個面試官就是DataX的作者之一，而當時我還偏偏因為業務需求做了個數據庫的同步工具，我當時不知道他做過這么專業的同步工具，被虐的老慘了，他面試的其中一個問題就是，如果要你去推銷一款數據庫同步工具，你該怎么推銷？
相信沒有深入了解過這個領域的可能說不出一兩點優勢來，而我當時做的工具，也就重在實現功能上了，唯一的優點我覺得就是還算通用，因為也是通過配置json文件設置對應表間的關系來實現不同數據庫之間的數據同步
1.2. DataX的優勢
所以現在在來談談數據同步工具該怎么推銷，那不就是把數據同步工具可完善，可擴展的部分盡可能的講一遍嗎
- 首先是工具本身方面，我們需要DataX在傳輸性能上有保證，它采用的任務架構可以保證在單機多線程上速度隨並發線性增長
- 那么如何保證傳輸過快，導致數據接收方崩掉呢，所以DataX提供了精准的速度控制模式，可以隨意調整作業速度，保證達到最高效的同步速度
- 數據同步還需要什么？多了，不同的數據庫可能字段類型需要一定轉換，根據需要對數據可能需要進行特定的過濾，脫敏，補全操作，最好還可以用戶自定義操作，這些DataX也提供了
- 同步的時候我們需要關注什么？對了，最好還有同步的進度，速度，錯誤情況，傳輸流量，cpu狀況等等的可視化監控
- 對開發者而言，我們需要什么？我們需要的是配置簡單，操作容易，依賴少，這也是DataX的特點
- 上述這些都是在正常情況下的操作，我們需要應對異常情況，比如網絡波動，甚至宕機，所以我們需要DataX具有健壯的容錯機制，對於這個，它提供了豐富的重試策略，和Task級別的重新調度（一個Job任務它會分成多個Task）
- 好了，你們還能想出同步工具需要支持的額外需求嗎？
這里給出DataX的官方Github地址，我並沒有在推廣這個工具哦，如果你們的系統用了大量阿里雲提供的服務比如odps，ads，那它倒是天然適配了，用它正合適，不過如果是mysql到mysql的同步就不一定要用這個了，業界流行的似乎是
canal也是阿里的，至於這兩個哪個快，我沒有測過，感興趣的可以自行嘗試