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