基于數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱&消費，目前主要支持了mysql.
有關(guān)數(shù)據(jù)增量訂閱與消費的中間件回顧一下：
Canal
Canal架構(gòu)圖：
說明：
模塊：
說明：一臺機器下部署一個canal，一個canal可以運行多個(通過配置等), 一般情況下一個連接一個（每個可以配置功能）, 可以多個連接同一個，但是同一時刻只能有一個消費的數(shù)據(jù)，這個通過控制。
數(shù)據(jù)庫同步Otter
背景： B2B因為業(yè)務(wù)的特性，賣家主要集中在國內(nèi)，買家主要集中在國外，所以衍生出了杭州和美國異地機房的需求，同時為了提升用戶體驗，整個機房的架構(gòu)為雙A，兩邊均可寫，由此誕生了otter這樣一個產(chǎn)品。
otter第一版本可追溯到04~05年，此次外部開源的版本為第4版，開發(fā)時間從2011年7月份一直持續(xù)到現(xiàn)在，目前阿里巴巴B2B內(nèi)部的本地/異地機房的同步需求基本全上了。
基于數(shù)據(jù)庫增量日志解析，準(zhǔn)實時同步到本地機房或異地機房的mysql/數(shù)據(jù)庫，一個分布式數(shù)據(jù)庫同步系統(tǒng)。
工作原理
原理描述：
基于Canal開源產(chǎn)品，獲取數(shù)據(jù)庫增量日志數(shù)據(jù)。
典型管理系統(tǒng)架構(gòu)，(Web管理)+node(工作節(jié)點)
基于，解決分布式狀態(tài)調(diào)度的，允許多node節(jié)點之間協(xié)同工作。
Otter的作用
異構(gòu)庫
單機房同步（數(shù)據(jù)庫之間RTT(Round-Trip Time)
跨機房同步（比如阿里巴巴國際站就是杭州和美國機房的數(shù)據(jù)庫同步，RTT>200ms）
雙向同步
文件同步
單機房復(fù)制示意圖
說明：
- 數(shù)據(jù)On-Fly, 盡可能不落地，更快的進行數(shù)據(jù)同步。（開啟node load 算法, 如果Node節(jié)點S+ETL落在不同的Node上，數(shù)據(jù)會有個網(wǎng)絡(luò)傳輸過程）
- node節(jié)點可以有/.
SETL
S:
為解決數(shù)據(jù)來源的差異性，比如接入canal獲取增量數(shù)據(jù)，也可以接入其他系統(tǒng)獲取其他數(shù)據(jù)等。
E:
T:
L: Load
類似于數(shù)據(jù)倉庫的ETL模型，具體可為數(shù)據(jù)join，數(shù)據(jù)轉(zhuǎn)化，數(shù)據(jù)加載。
跨機房復(fù)制示意圖
數(shù)據(jù)涉及網(wǎng)絡(luò)傳輸，S/E/T/L幾個階段會分散在2個或者更多Node節(jié)點上，多個Node之間通過進行協(xié)同工作（一般是和在一個機房的Node, /Load落在另一個機房的Node）
node節(jié)點可以有/。(每個機房的Node節(jié)點，都可以是集群，一臺或者多臺機器)
More:異地雙活數(shù)據(jù)架構(gòu)基礎(chǔ)設(shè)施DRC
所謂DRC，就是Data 的縮寫，數(shù)據(jù)復(fù)制中心。這種復(fù)制是同步的，支持異構(gòu)的，高可用的（有嚴(yán)格容災(zāi)系統(tǒng)，實時性好），支持訂閱分發(fā)的。項目期初是為了淘寶異地容災(zāi)而成立的，用于數(shù)據(jù)庫之間主備同步，后來采用這套技術(shù)方案衍生出了DRC-TAIR, DRC-DUMP等項目。
所謂異地雙活主要關(guān)注兩件事，一個數(shù)據(jù)同步，一個數(shù)據(jù)分發(fā)。
到底怎樣的應(yīng)用會需要異地的雙活？比較常見的場景有三個：
兩個地域或多個地域都有大量用戶的場景，比如在中國的用戶希望他們用杭州的RDS服務(wù)，在美國的用戶用美國的RDS服務(wù)，這就需要數(shù)據(jù)在異地同步。很多游戲，金融，傳媒，電商業(yè)務(wù)都有這種需求。滿足這個需求的難點在于跨地域的網(wǎng)絡(luò)，比如網(wǎng)絡(luò)延時長，丟包多，而且數(shù)據(jù)在公網(wǎng)傳輸會有數(shù)據(jù)泄露風(fēng)險。
數(shù)據(jù)來源較多，需要介入各種異構(gòu)數(shù)據(jù)的場景。比如一個應(yīng)用需要從ODPS, RDS, OTS， , 這幾個服務(wù)介入數(shù)據(jù)，他們的數(shù)據(jù)結(jié)構(gòu)和接口都不同，這種接入的成本會比較高。因此另一個可用的方法是數(shù)據(jù)寫入的時候就一份多謝為不同數(shù)據(jù)結(jié)構(gòu)
下游訂閱很多的情況，比如一份數(shù)據(jù)，備份系統(tǒng)、通知系統(tǒng)、大數(shù)據(jù)分析系統(tǒng)、索引系統(tǒng)等等都要來取，如果用上面一份數(shù)據(jù)多寫的方案是可以應(yīng)對的，但這里還有其他難點，就是數(shù)據(jù)一致性、可擴展性、跨網(wǎng)同步穩(wěn)定性、以及同步的實時性。
DRC支持讀取集團MySQL, RDS, , HBase, 等多種不同的數(shù)據(jù)源的實時增量數(shù)據(jù)，支持寫入數(shù)據(jù)庫、MetaQ, ODPS等多種存儲媒介.
DRC架構(gòu)
以前在一個城市做雙機房主備，兩個機房是數(shù)據(jù)對等的，寫入是隨機分布，然后通過主備HA進行數(shù)據(jù)同步。這樣機房對等的思路會導(dǎo)致業(yè)務(wù)增長、數(shù)據(jù)增長只能通過兩個機房不停堆機器來解決。另一方面，如果整個城市斷電，那么雙活就成了雙死。下一個思路是做跨城市，早期常用的做法是一個城市寫，另一個城市冷備，就是晚上做同步，但這就意味著白天如果發(fā)生了什么事兒，這一天的數(shù)據(jù)就比較危險。另一個思路是兩個城市多寫，數(shù)據(jù)落兩邊，這樣的問題是應(yīng)用調(diào)用次數(shù)頻繁的話，如果調(diào)用異地數(shù)據(jù)多來那么一兩次，整個應(yīng)用的延時就很長。這個思路再進一步發(fā)展，就是做單元內(nèi)封閉以減少異地調(diào)用，這就涉及到業(yè)務(wù)上的改造。
順著這個思路，阿里的異地雙活重點做了幾件事。一個是熱插拔，可以做到在業(yè)務(wù)高峰時增加節(jié)點，高峰過了把增加的節(jié)點關(guān)閉。做到這個的一個關(guān)鍵是流量實時切換，DRC可以在20秒以內(nèi)把一個單元（）的流量遷移到另一個單元。另一個是數(shù)據(jù)實時恢復(fù)，就是通過一定的冗余設(shè)計數(shù)據(jù)庫中間件原理，一旦一個單元掛掉了，可以在另一個單元做全量恢復(fù)。
異地多活在數(shù)據(jù)方面的挑戰(zhàn)是非常大的。雙十一期間，交易會激增，所以交易鏈路做了單元化。交易鏈路的數(shù)據(jù)分為三個維度：買家、賣家、商品。買家之間通常沒有太多交叉，天然的適應(yīng)這種隔離，而且賣家對延遲的敏感度非常高，所以按照賣家維度切分，在單元內(nèi)封閉，而賣家和商品都是在中心寫入。
數(shù)據(jù)方面的兩個核心要求：
一致性數(shù)據(jù)庫中間件原理，要求賣家和商品一致，單元和中心一致，也就是數(shù)據(jù)同步不能丟數(shù)據(jù)，不能錯數(shù)據(jù)，還要保證事務(wù)。
實時性，需要做到秒級別的延遲。
雙單元的同步架構(gòu)有兩種：
一種是讀寫分離的方式，中心寫，單元讀。單元需要的數(shù)據(jù)如果沒有從中心及時同步過來，或者同步錯了，那有問題這段時間的交易會全部收到影響。這里的核心是，保證秒級延遲，同時保證一致性。（JD的多中心交易系統(tǒng)就采用了這種方式）
第二種同步架構(gòu)是單元封閉的方式。中心和單元各有寫入，我們通過冗余是的中心和單元隨時可以各自接管。（類似Otter）
這里的關(guān)鍵是：
Otter與DRC的區(qū)別：
- Otter是阿里B2B的產(chǎn)品，DRC是阿里技術(shù)保障團隊的產(chǎn)品
- Otter是針對MySQL的，DRC可以支持多種類型的數(shù)據(jù)源
- DRC從業(yè)務(wù)上進行了劃分，可以實現(xiàn)單元內(nèi)封閉，Otter的實現(xiàn)不涉及業(yè)務(wù)，而是在純數(shù)據(jù)庫層打通的技術(shù)
- Otter是雙寫，DRC是中心寫、分中心讀，或者都部分寫，相互同步。
- Otter所處的網(wǎng)絡(luò)環(huán)境較DRC差，解決一致性問題也較復(fù)雜（基于 的單向環(huán)回的補救，基于時間交集的補救），DRC有兩種實現(xiàn)方式，具體參考上面。
異地多活中DRC的核心能力就是在低延遲，一致性和高可用。
JD多中心交易系統(tǒng)
JD. 多中心交易系統(tǒng)。
JD數(shù)據(jù)復(fù)制中間件考察和借鑒了開源社區(qū)的實現(xiàn)，例如、Canal/Otter、等，解析部分使用了Canal的。
多中心交易本質(zhì)上是一個更大的分布式系統(tǒng)，交易流程中依賴和產(chǎn)生的數(shù)據(jù)和服務(wù)有不同的特點，必然涉及到數(shù)據(jù)分區(qū)、路由、復(fù)制、讀寫一致性、延遲等分布式領(lǐng)域的常見問題。
其中，數(shù)據(jù)一致性是電商網(wǎng)站需要面臨的首要問題，越是流量增大的時候越要保證數(shù)據(jù)更新的即時性和準(zhǔn)確性。在多中心之間需要同步賣家數(shù)據(jù)和商品數(shù)據(jù)，如果同步的延時太長，買家、賣家都不可接受。比如，賣家改了價格或庫存，用戶不能過很久才看到。同樣，數(shù)據(jù)正確性也是很大的挑戰(zhàn)，賣掉的商品能夠及時減少，退貨的商品能夠及時增加。這都時刻考驗著后端系統(tǒng)和數(shù)據(jù)庫平臺的健壯性。
除了數(shù)據(jù)一致性之外，如何保證路由規(guī)則的一致性也是關(guān)鍵性的問題。從技術(shù)角度來說，要保障單一用戶從登錄到訪問服務(wù)、到訪問數(shù)據(jù)庫，全鏈路的路由規(guī)則都是完全一致的。如果路由錯誤，看到的數(shù)據(jù)不正確，也會影響到最終用戶的體驗。
架構(gòu)
系統(tǒng)包括一個主中心和多個分中心，主中心與分中心之間通過數(shù)據(jù)總線交換數(shù)據(jù)。數(shù)據(jù)流向中，主數(shù)據(jù)(商品數(shù)據(jù)、商家數(shù)據(jù)、用戶數(shù)據(jù)等)的流向從主中心通過數(shù)據(jù)總線實時同步到分中心，分中心只讀；而交易數(shù)據(jù)(訂單數(shù)據(jù))的流向從分中心實時同步到主中心；在故障時，會從分中心轉(zhuǎn)移到主中心。
在這個系統(tǒng)中，有多處體現(xiàn)分流的概念。首先，買家訪問京東網(wǎng)站下單時，會被優(yōu)先分流到附近的交易中心；其次，根據(jù)交易系統(tǒng)的特點，接單前（包括購物車、結(jié)算頁等），多中心交易按用戶維度分流，如下圖所示。用戶登錄時，查詢用戶與區(qū)域的映射關(guān)系表（類似你是哪個片區(qū)的），標(biāo)識此用戶屬于哪個分中心，并保存標(biāo)識到中，然后將用戶路由到指定的分中心。用戶訪問其他系統(tǒng)，如購物車和結(jié)算頁時，從中讀取標(biāo)識，重定向到相應(yīng)分中心頁面。
通過分流，將用戶分配到相應(yīng)的分中心，一方面響應(yīng)速度快，用戶體驗更好，不用跨地域訪問數(shù)據(jù)中心了；另一方面，每個中心服務(wù)一定數(shù)量的用戶，水平擴展性好，也能支撐更大的交易規(guī)模了。當(dāng)然，多數(shù)據(jù)中心不能盲目干活，還考慮到容災(zāi)備份的問題。（支付寶光纖事件）
交易系統(tǒng)包括應(yīng)用和數(shù)據(jù)部分，應(yīng)用部分是無狀態(tài)的，就是說，這些工作是無差別的，一臺服務(wù)器出問題，我換一臺服務(wù)器來處理就是了，較容易實現(xiàn)多機房多活。但是數(shù)據(jù)不一樣，多中心交易本質(zhì)上是一個更大的分布式系統(tǒng)，必然涉及到數(shù)據(jù)分區(qū)、路由、復(fù)制、讀寫一致性、延遲等分布式領(lǐng)域的常見問題。
另外，交易流程中依賴和產(chǎn)生的數(shù)據(jù)和服務(wù)有不同的特點。比如商品、促銷和價格、庫存的讀服務(wù)，我們可以將之稱為基礎(chǔ)主數(shù)據(jù)，它們在用戶下單流程中是無法分區(qū)的，否則無法實現(xiàn)單機房內(nèi)流量閉環(huán)，也就是說，不能因為分區(qū)數(shù)據(jù)的不一致，導(dǎo)致同一用戶在單一流程中看到不同的數(shù)據(jù)（假如你加入購物車時是促銷20塊，結(jié)賬是25塊，你會不會表情扭曲？）而商品、促銷和價格的寫服務(wù),是給采銷、第三方POP商家應(yīng)用調(diào)用的，這種業(yè)務(wù)場景的可用性目標(biāo)，主機房部署和冷備模式即可滿足，而且業(yè)務(wù)人員的操作流程會抵消寫復(fù)制延遲。
簡單來說，數(shù)據(jù)的問題表現(xiàn)在以下幾個方面：一、 如何保證數(shù)據(jù)的即時性和準(zhǔn)確性，多中心之間需要同步賣家數(shù)據(jù)和商品數(shù)據(jù)，如果同步的延時太長,買家、賣家都不可接受，由于是異地部署，最好延時能控制在1秒內(nèi)。比如，賣家改了價格或庫存，用戶不能過很久才看到。同樣，數(shù)據(jù)正確性也是很大的挑戰(zhàn),因為數(shù)據(jù)故障跟應(yīng)用層故障不一樣，應(yīng)用出故障了，可能只影響用戶訪問；數(shù)據(jù)寫錯了無法恢復(fù)。2、如何保證路由規(guī)則的一致性，要保障這個用戶從進來到訪問服務(wù)，到訪問數(shù)據(jù)庫，全鏈路的路由規(guī)則都是完全一致的；如果路由錯誤，看到的數(shù)據(jù)不正確。
從同城雙機房的分布轉(zhuǎn)變?yōu)楫惖囟鄼C房的分布，給數(shù)據(jù)同步帶來了新的挑戰(zhàn)，因此如何設(shè)計數(shù)據(jù)總線也是項目能否實現(xiàn)的關(guān)鍵因素。京東的多中心交易系統(tǒng)通過數(shù)據(jù)總線進行快速數(shù)據(jù)交換，同步性能是mysql的3倍以上，而且可用性高，架構(gòu)靈活。其中，全新的總線設(shè)計解決了多中心交易跨機房的數(shù)據(jù)庫復(fù)制和多數(shù)據(jù)源間的數(shù)據(jù)異構(gòu)同步等難題，實現(xiàn)了高性能、低延時、健壯的數(shù)據(jù)同步機制。
如圖所示，數(shù)據(jù)總線主要分Relay、和三部分構(gòu)成，其中Relay從來源數(shù)據(jù)庫抽取事務(wù)日志，并對提供日志訂閱服務(wù)，角色上相當(dāng)于Mysql Slave IO 。從Relay訂閱所有事務(wù)日志，寫入持久存儲作為快照，同時向提供批量日志訂閱服務(wù)，角色上相當(dāng)于Mysql Slave Relay Log。：事務(wù)日志的消費端，從Relay或拉取事務(wù)日志將事務(wù)日志按配置的一致性應(yīng)用到目標(biāo)數(shù)據(jù)庫，角色上相當(dāng)于Mysql Slave SQL 。(參考下面MySQL主備復(fù)制原理圖)
正常情況下，直接連接Relay，消費Relay內(nèi)存隊列中的事務(wù)日志。但有些情況下，因為網(wǎng)絡(luò)抖動、目標(biāo)庫的負載過高等因素，可能導(dǎo)致相對Relay落后很多。另外，當(dāng)新的消費端加入同一數(shù)據(jù)源的訂閱者時，新消費端有冷啟動的問題。為了避免重新從數(shù)據(jù)源做全量快照，作為Relay的一個特殊消費端，通過一種高吞吐的消費方式，從Relay源源不斷的消費在線事務(wù)日志，通過對事務(wù)日志的有效處理，最終保存了數(shù)據(jù)源的一份一致快照( )，即包括了數(shù)據(jù)源庫表中每一行的最新狀態(tài)的快照，同時保留了一段比Relay 更舊的事務(wù)日志(Log Store)。由此看來，數(shù)據(jù)總線作為一個數(shù)據(jù)層的通用CDC組件，對于多中心交易項目以及異步復(fù)制場景提供了整體解決方案，奠定了項目的核心內(nèi)容。
跨數(shù)據(jù)庫（數(shù)據(jù)源）遷移
去數(shù)據(jù)遷移同步工具。定位：數(shù)據(jù)庫遷移（目前主要支持->mysql/DRDS）
08年左右，阿里巴巴開始嘗試MySQL的相關(guān)研究，并開發(fā)了基于MySQL分庫分表技術(shù)的相關(guān)產(chǎn)品，Cobar/TDDL(目前為阿里云DRDS產(chǎn)品)，解決了單機無法滿足的擴展性問題，當(dāng)時也掀起一股去IOE項目的浪潮，愚公這項目因此而誕生，其要解決的目標(biāo)就是幫助用戶完成從數(shù)據(jù)遷移到MySQL上，完成去IOE的第一步.
概述
整個數(shù)據(jù)遷移過程，分為兩個部分：
全量遷移
增量遷移
過程描述：
增量數(shù)據(jù)收集（創(chuàng)建表的增量物化視圖）
進行全量復(fù)制
進行增量復(fù)制（可并行進行數(shù)據(jù)校驗）
原庫停寫，切換到新庫
全量基于JDBC拉取數(shù)據(jù)，增量基于物化視圖來實現(xiàn)。
架構(gòu)
說明：
一個JVM 對應(yīng)多個，每個對應(yīng)于一張表的遷移任務(wù)
分為三部分
自定義數(shù)據(jù)轉(zhuǎn)換
如果要遷移的和mysql的表結(jié)構(gòu)不同，比如表名，字段名有差異，字段類型不兼容，需要使用自定義數(shù)據(jù)轉(zhuǎn)換。如果完全相同則可以跳過。
整個數(shù)據(jù)流為：DB->->->->DB, 本程序預(yù)留接口（僅支持Java），允許外部用戶自定義數(shù)據(jù)處理邏輯。比如：
表名不同
字段名不同
字段類型不同
字段個數(shù)不同
運行過程join其他表的數(shù)據(jù)做計算等
運行模式介紹
1.MARK模式（MARK）
開啟增量日志模式，如果是就是創(chuàng)建物化視圖（ view）。
2.CLEAR模式（CLEAR）
清理增量日志的幾率，如果是就是刪除物化視圖
3.全量模式（FULL)
全量模式，顧名思議即為對源表進行一次全量操作，遍歷源表所有的數(shù)據(jù)后，插入目標(biāo)表.
全量有兩種處理方式：
分頁處理：如果源表存在主鍵，只有一個主鍵字段，并且主鍵字段類型為類型，默認(rèn)會選擇該分頁處理模式. 優(yōu)點：支持?jǐn)帱c續(xù)做，對源庫壓力相對較小。 缺點：遷移速度慢
once處理：通過 * from訪問整個源表的某一個mvcc版本的數(shù)據(jù)，通過.next遍歷整個結(jié)果集. 優(yōu)點：遷移速度快，為分頁處理的5倍左右。 缺點：源庫壓力大，如果源庫并發(fā)修改量大，會導(dǎo)致數(shù)據(jù)庫MVCC版本過多，出現(xiàn)棧錯誤. 還有就是不支持?jǐn)帱c續(xù)做.
4.增量模式（INC）
全量模式，顧名思議即為對源表增量變化的數(shù)據(jù)插入目標(biāo)表，增量模式依賴記錄日志功能.
目前增量模式的記錄日志功能，是通過的物化視圖功能。
5.自動模式(ALL)
自動模式，是對全量+增量模式的一種組合，自動化運行，減少操作成本.
自動模式的內(nèi)部實現(xiàn)步驟：
開啟記錄日志功能. (創(chuàng)建物化視圖)
運行全量同步模式. (全量完成后，自動進入下一步)
運行增量同步模式. (增量模式，沒有完成的概念，所以也就不會自動退出，需要業(yè)務(wù)判斷是否可以退出，可以看一下切換流程)
6.對比模式(CHECK)
對比模式，即為對源庫和目標(biāo)庫的數(shù)據(jù)進行一次全量對比，驗證一下遷移結(jié)果. 對比模式為一種可選運行，做完全量/增量/自動模式后，可選擇性的運行對比模式，來確保本次遷移的正確性.
DataX
DataX是一個在異構(gòu)的數(shù)據(jù)庫/文件系統(tǒng)之間高速交換數(shù)據(jù)的工具，實現(xiàn)了在任意的數(shù)據(jù)處理系統(tǒng)(RDBMS/Hdfs/Local ）之間的數(shù)據(jù)交換。
目前成熟的數(shù)據(jù)導(dǎo)入導(dǎo)出工具比較多，但是一般都只能用于數(shù)據(jù)導(dǎo)入或者導(dǎo)出，并且只能支持一個或者幾個特定類型的數(shù)據(jù)庫。
這樣帶來的一個問題是，如果我們擁有很多不同類型的數(shù)據(jù)庫/文件系統(tǒng)(Mysql//Rac/Hive/Other…)，并且經(jīng)常需要在它們之間導(dǎo)入導(dǎo)出數(shù)據(jù)，那么我們可能需要開發(fā)/維護/學(xué)習(xí)使用一批這樣的工具(///+/…)。而且以后每增加一種庫類型，我們需要的工具數(shù)目將線性增長。(當(dāng)我們需要將mysql的數(shù)據(jù)導(dǎo)入的時候，有沒有過想從和上各掰下來一半拼在一起到?jīng)_動？)這些工具有些使用文件中轉(zhuǎn)數(shù)據(jù)，有些使用管道，不同程度的為數(shù)據(jù)中轉(zhuǎn)帶來額外開銷，效率差別很非常大。很多工具也無法滿足ETL任務(wù)中常見的需求，比如日期格式轉(zhuǎn)化，特性字符的轉(zhuǎn)化，編碼轉(zhuǎn)換。另外，有些時候，我們希望在一個很短的時間窗口內(nèi)，將一份數(shù)據(jù)從一個數(shù)據(jù)庫同時導(dǎo)出到多個不同類型的數(shù)據(jù)庫。DataX正是為了解決這些問題而生。
設(shè)計理念
為了解決異構(gòu)數(shù)據(jù)源同步問題，DataX將復(fù)雜的網(wǎng)狀的同步鏈路變成了星型數(shù)據(jù)鏈路，DataX作為中間傳輸載體負責(zé)連接各種數(shù)據(jù)源。當(dāng)需要接入一個新的數(shù)據(jù)源的時候，只需要將此數(shù)據(jù)源對接到DataX，便能跟已有的數(shù)據(jù)源做到無縫數(shù)據(jù)同步。
DataX在阿里巴巴集團內(nèi)被廣泛使用，承擔(dān)了所有大數(shù)據(jù)的離線同步業(yè)務(wù)，并已持續(xù)穩(wěn)定運行了6年之久。目前每天完成同步8w多道作業(yè)，每日傳輸數(shù)據(jù)量超過300TB。
框架設(shè)計
DataX本身作為離線數(shù)據(jù)同步框架，采用+架構(gòu)構(gòu)建。將數(shù)據(jù)源讀取和寫入抽象稱為/插件，納入到整個同步框架中。
DataX框架內(nèi)部通過雙緩沖隊列、線程池封裝等技術(shù)，集中處理了高速數(shù)據(jù)交換遇到的問題，提供簡單的接口與插件交互，插件分為和兩類，基于框架提供的插件接口，可以十分便捷的開發(fā)出需要的插件。比如想要從導(dǎo)出數(shù)據(jù)到mysql，那么需要做的就是開發(fā)出和插件，裝配到框架上即可。并且這樣的插件一般情況下在其他數(shù)據(jù)交換場合是可以通用的。
核心架構(gòu)
.0 開源版本支持單機多線程模式完成同步作業(yè)運行，這里按一個DataX作業(yè)生命周期的時序圖，從整體架構(gòu)設(shè)計非常簡要說明DataX各個模塊相互關(guān)系。
核心模塊介紹：
DataX完成單個數(shù)據(jù)同步的作業(yè)，我們稱之為Job，DataX接受到一個Job之后，將啟動一個進程來完成整個作業(yè)同步過程。DataX Job模塊是單個作業(yè)的中樞管理節(jié)點，承擔(dān)了數(shù)據(jù)清理、子任務(wù)切分(將單一作業(yè)計算轉(zhuǎn)化為多個子Task)、管理等功能。
啟動后，會根據(jù)不同的源端切分策略，將Job切分成多個小的Task(子任務(wù))，以便于并發(fā)執(zhí)行。Task便是DataX作業(yè)的最小單元，每一個Task都會負責(zé)一部分?jǐn)?shù)據(jù)的同步工作。
切分多個Task之后，DataX Job會調(diào)用模塊，根據(jù)配置的并發(fā)數(shù)據(jù)量，將拆分成的Task重新組合，組裝成(任務(wù)組)。每一個負責(zé)以一定的并發(fā)運行完畢分配好的所有Task，默認(rèn)單個任務(wù)組的并發(fā)數(shù)量為5。
每一個Task都由負責(zé)啟動，Task啟動后，會固定啟動—>—>的線程來完成任務(wù)同步工作。
DataX作業(yè)運行起來之后， Job監(jiān)控并等待多個模塊任務(wù)完成，等待所有任務(wù)完成后Job成功退出。否則，異常退出，進程退出值非0。
DataX調(diào)度流程：
舉例來說，用戶提交了一個DataX作業(yè)，并且配置了20個并發(fā)，目的是將一個100張分表的mysql數(shù)據(jù)同步到odps里面。 DataX的調(diào)度決策思路是：
1. 根據(jù)分庫分表切分成了100個Task。
2. 根據(jù)20個并發(fā)，DataX計算共需要分配4個。
3. 4個平分切分好的100個Task，每一個負責(zé)以5個并發(fā)共計運行25個Task。
Datax插件開發(fā)：%E6%8F%92%E4%BB%B6%E5%BC%80%E5%8F%91%E5%AE%9D%E5%85%B8