這裏主要介紹互聯網行業內有關數據庫的相關中間件。數據庫相關平臺主要解決以下三個方面的問題：

爲海量前臺數據提供高性能、大容量、高可用性的訪問
爲數據變更的消費提供準實時的保障
高效的異地數據同步

應用層通過分表分庫中間件訪問數據庫，包括讀操作（Select）和寫操作（update, insert和delete等，DDL, DCL）。寫操作會在數據庫上產生變更記錄，MySQL的變更記錄叫binlog, Oracle的稱之爲redolog, 增量數據訂閱與消費中間件解析這些變更，並以統一的格式保存起來，下層應用根據這些數據進行消費應用。當然，在數據庫與數據庫本身之間也會有數據庫遷移的操作，這種操作可以不需要增量數據訂閱與消費中間件的數據，而可以自行處理。

數據庫中間件有以下幾種：

分佈式數據庫分表分庫
數據增量訂閱與消費
數據庫同步（全量、增量、跨機房、複製）
跨數據庫（數據源）遷移

整個產品族圖如下：

最上層的是分佈式數據庫分表分庫中間件，負責和上層應用打交道，對應用可表現爲一個獨立的數據庫，而屏蔽底層複雜的系統細節。分佈式數據庫中間件除了基本的分表分庫功能，還可以豐富一下，比如講讀寫分離或者水平擴容功能集成在一起，或者比如讀寫分離本身也可以作爲一個獨立的中間件。（Cobar, MyCAT, TDDL, DRDS, DDB）
增量數據訂閱和消費，用戶對數據庫操作，比如DML, DCL, DDL等，這些操作會產生增量數據，下層應用可以通過監測這些增量數據進行相應的處理。典型代表Canal，根據MySQL的binlog實現。也有針對Oracle(redolog)的增量數據訂閱與消費的中間件。（Canal, Erosa）
數據庫同步中間件涉及數據庫之間的同步操作，可以實現跨（同）機房同步以及異地容災備份、分流等功能。可以涉及多種數據庫，處理之後的數據也可以以多種形式存儲。（Otter, JingoBus, DRC）
數據庫與數據庫之間會有數據遷移（同步）的動作，同款數據同步原理比較簡單，比如MySQL主備同步，只要在數據庫層進行相應的配置既可，但是跨數據庫同步就比較複雜了，比如Oracle->MySQL. 數據遷移一般包括三個步驟：全量複製，將原數據庫的數據全量遷移到新數據庫，在這遷移的過程中也會有新的數據產生；增量同步，對新產生的數據進行同步，並持續一段時間以保證數據同步；原庫停寫，切換新庫。將“跨數據庫”這個含義擴大一下——“跨數據源”，比如HDFS, HBase, FTP等都可以相互同步。（yugong, DataX）

分佈式數據庫

隨着互聯網產品在體量和規模上日益膨脹，無論是Oracle還是MySQL，都會第一時間面臨來自磁盤，CPU和內存等單機瓶頸，爲此，產品方除了需要不斷購買成本難以控制的高規格服務器，還要面臨不斷迭代的在線數據遷移。在這種情況下，無論是海量的結構化數據還是快速成長的業務規模，都迫切需要一種水平擴展的方法將存儲成本分攤到成本可控的商用服務器上。同時，也希望通過線性擴容降低全量數據遷移對線上服務帶來的影響，分庫分表方案便應運而生。

分表分庫類的中間件主要有兩種形式嚮應用提供服務：

一種是以JDBC的jar包形式爲Java應用提供直接依賴，Java應用通過提供的JDBC包實現透明訪問分佈式數據庫集羣中的各個分庫分表，典型代表網易的DDB和阿里的TDDL.
另一種是爲應用部署獨立的服務來滿足應用分庫分表的需求，在這種方式下通過標準JDBC訪問Proxy，而Proxy則根據MySQL標準通信協議對客戶端請求解析，還原應用SQL請求，然後通過本地訪問數據庫集羣，最後再將得到的結果根據MySQL標準通信協議編碼返回給客戶端。典型代表阿里的Cobar, Cobar變種MyCAT, 阿里的DRDS，網易的DDB proxy模式以及DDB的私有云模式。

Cobar

Cobar 是提供關係型數據庫（MySQL）分佈式服務的中間件，它可以讓傳統的數據庫得到良好的線性擴展，並看上去還是一個數據庫，對應用保持透明。

Cobar以Proxy的形式位於前臺應用和實際數據庫之間，對前臺的開放的接口是MySQL通信協議。將前臺SQL語句變更並按照數據分佈規則發到合適的後臺數據分庫，再合併返回結果，模擬單庫下的數據庫行爲。

Cobar屬於阿里B2B事業羣，始於2008年，在阿里服役3年多，接管3000+個MySQL數據庫的schema,集羣日處理在線SQL請求50億次以上。由於Cobar發起人的離職，Cobar停止維護。後續的類似中間件，比如MyCAT建立於Cobar之上，包括現在阿里服役的RDRS其中也複用了Cobar-Proxy的相關代碼。

Cobar結構

與應用之間通過MySQL protocol進行交互，是一個proxy的結構，對外暴露jdbc:mysql://CobarIP:port/schema。對應用透明。
無需引入新的jar包，從訪問遷移到數據庫訪問Cobar可以複用原有的基於JDBC的DAO。
Cobar前後端都實現了MySQL協議，當接受到SQL請求時，會一次進行解釋（SQL Parser）和路由（SQL Router）工作，然後使用SQL Executor去後端模塊獲取數據集（後端模塊還負責心跳檢查功能）；如果數據集來自多個數據源，Cobar則需要把數據集進行組合（Result Merge），最後返回響應。
數據庫連接複用。Cobar使用連接詞與後臺真是數據庫進行交互。（實際應用中，根據應用的不同，使用proxy結構後數據庫連接數能夠節約2-10倍不等。）
Cobar事務，Cobar在單庫的情況下保持事務的強一致性，分庫的情況下保持事務的弱一致性，分庫事務採用2PC協議，包括執行階段和提交階段。

Cobar的前端是NIO的，而後端跟MySQL交互是阻塞模式，其NIO代碼只給出了框架，還沒有來得及實現。據稱未開源版的Cobar實現了後端的NIO。
Cobar會出現假死，假死以後Cobar會頻繁進行主從切換（如果配置了的話），自動切換本身也存在隱患。
可以計算：Cobar的TPS=5,000,000,000/(3000*24*60*60)=20。
與Cobar相關的還有一共Cobar-Client.

Cobar通過SQL語句轉發的方式實現數據訪問。用戶發來的SQL語句，Cobar解析其內容，判斷該語句所涉及的數據分佈在哪個分庫上，再將語句轉發給此分庫執行。當SQL語句中涉及的拆分字段有多值，如 IN, 或where條件中沒有出現拆分字段時，該語句將會轉發至後臺所有分庫執行，再將執行結果以MySQL協議包的形式送回應用端。

通信模塊，負責從連續的網絡數據流中識別出一個個MySQL協議包，再解析協議包識別出SQL語句輸出給Parser模塊，同時，把Result Merge模塊輸入的執行結果，編碼成MySQL的協議包。它以NIO方式實現，有很高的執行效率。之後進行優化，引入了一個ByteBuffer池，將NIO的Buffer統一管理起來，減少了NIO數據交互時的垃圾回收。

Cobar前端使用的是優化後的NIO通信模塊，爲了讓該模塊在後端使用，Cobar去除了JDBC。與後端數據庫交互，Cobar直接面向協議，目前實現了基於MySQL協議的後端交互。

水平拆分後，後臺有多個數據源，對他們的管理分爲兩個層次：DataNode和replica(HA Pool)。
DataNode管理拆分，一個DataNode存放一個分片的數據，彼此無數據交集。每個分片的數據存多份以保證高可用，每一份叫做一個replica，由HA層管理。每一個replica表示一個具體的數據源，它是一個連接池，池內管理每一個具體的JDBC連接。路由運算只關注到DataNode層，之下的層次對其不可見。
每一份replica之間的數據複製和同步由MySQL本身的replication協議完成，同一時刻只有一個replica提供服務（稱爲Master，其餘replica稱爲Slave）.Cobar會與之保持心跳，一旦發現它不可用，會切換至另一個replica，解決Oracle單點的第二個問題。

爲了節省數據庫的機器數量，可以採用下圖中的方式部署：

HA

在用戶配置了MySQL心跳的情況下，Cobar可以自動向後端連接的MySQL發生心跳，判斷MySQL運行狀況，一旦運行出現異常，Cobar可以自動切換到備機工作，但需要強調的是：

Cobar的主備切換有兩種觸發方式，一種是用戶手動觸發，一種是Cobar的心跳語句檢測到異常後自動觸發。那麼，當心跳檢測到主機異常，切換到備機，如果主機恢復了，需要用戶手動切回主機工作，Cobar不會在主機恢復時自動切換回主機，除非備機的心跳也返回異常。
Cobar只檢查MySQL主備異常，不關心主備之間的數據同步，因此用戶需要在使用Cobar之前在MySQL主備上配置雙向同步，詳情可以參閱MySQL參考手冊。

Cobar解決的問題

分佈式：Cobar的分佈式主要是通過將表放入不同的庫來實現。

Cobar支持將一張表水平拆分成多份分別放入不同的庫來實現表的水平拆分
Cobar也支持將不同的表放入不同的庫
多數情況下，用戶將以上兩種方式混合使用

這裏需要強調的是，Cobar不支持將一張表，例如test表拆分成test_1, test_2, test_3….放在同一個庫中，必須拆分後的表分別放入不同的庫來實現分佈式。

Cobar的約束

不支持跨庫情況下的join、分頁、排序、子查詢操作
SET語句執行會被忽略，事務和字符集設置除外
分庫情況下，insert語句必須包括拆分字段列名
分庫情況下，update語句不能更新拆分字段的值
不支持SAVEPOINT操作
暫時只支持MySQL數據節點
使用JDBC時，不支持rewriteBatchedStatements=true參數設置（默認爲false）
使用JDBC時，不支持useServerPrepStmts=true參數設置（默認爲false)
使用JDBC時，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()方法設置參數

MyCAT

從定義和分類看，它是一個開源的分佈式數據庫系統，是一個實現了MySQL協議的Server，前端用戶可以把它看做是一個數據庫代理，用MySQL客戶端工具和命令行訪問，而其後端可以用MySQL Native Protocol與多個MySQL服務器通信，也可以用JDBC協議與大多數主流數據庫服務器通信，其核心功能是分表分庫，即將一個大表水平分割爲N個小表，存儲在後端MySQL服務器裏或者其他數據庫裏。

MyCAT發展到目前的版本，已經不是一個單純的MySQL代理了，它的後端可以支持MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流數據庫，也支持MongoDB這種新型NoSQL方式的存儲，未來還會支持更多類型的存儲。

MyCAT是一個強大的數據庫中間件，不僅僅可以用作讀寫分離，以及分表分庫、容災管理，而且可以用於多租戶應用開發、雲平臺基礎設施，讓你的架構具備很強的適應性和靈活性，藉助於即將發佈的MyCAT只能優化模塊，系統的數據訪問瓶頸和熱點一目瞭然，根據這些統計分析數據，你可以自動或手工調整後端存儲，將不同的表隱射到不同存儲引擎上，而整個應用的代碼一行也不用改變。

MyCAT是在Cobar基礎上發展的版本，兩個顯著提高：

後端由BIO改爲NIO，併發量有大幅提高；
增加了對Order By, Group By, Limit等聚合功能（雖然Cobar也可以支持Order By, Group By, Limit語法，但是結果沒有進行聚合，只是簡單返回給前端，聚合功能還是需要業務系統自己完成）

MyCAT架構

事務是弱XA
MyCAT的原理中最重要的一個動詞是“攔截”，它攔截了用戶發來的SQL語句，首先對SQL語句做了一些特定的分析：如分片分析，路由分析、讀寫分離分析、緩存分析等，然後將此SQL發往後端的真實數據庫，並將返回的結果做適當的處理，最終再返回給用戶。
MyCAT對自身不支持的SQL語句提供了一種解決方案——在要執行的SQL語句前添加額外的一段由註解SQL組織的代碼，這樣SQL就能正確執行，這段代碼稱之爲“註解”。註解的使用相當於對MyCAT不支持的SQL語句做了一層透明代理轉發，直接交給目標的數據節點進行SQL語句執行。
MyCAT自身有類似其他數據庫的管理監控方式，可以通過MySQL命令行，登錄管理端口（9066）執行相應的SQL進行管理，也可以通過jdbc的方式進行遠程連接管理。

HA

MyCAT作爲一個代理層中間件，MyCAT系統的高可用設計到MyCAT本身的高可用以及後端MySQL的高可用. 在多數情況下，建議採用MySQL主從複製高可用性配置並交付給MyCAT來完成後端MySQL節點的主從自動切換。

MySQL側的HA

MySQL節點開啓主從複製的配置方案，並將主節點配置爲MyCAT的dataHost裏的writeNode，從節點配置爲readNode，同時MyCAT內部定期對一個dataHost裏的所有writeHost與readHost節點發起心跳檢測。
正常情況下，MyCAT將第一個writeHost作爲寫節點，所有的DML SQL會發送此節點。
若MyCAT開啓了讀寫分離，則查詢節點會根據讀寫分離的策略發往readHost(+writeHost)執行。
如果第一個writeHost宕機，MyCAT會在默認的三次心跳檢測失敗後，自動切換到下一個可用的writeHost執行DML SQL語句
當原來配置的MySQL寫節點宕機恢復後，作爲從節點，跟隨新的主節點，重新配置主從同步。

MyCAT自身的HA

官方建議是採用基於硬件的負載聚亨或者軟件方式的HAproxy等。
如果還擔心HAproxy的穩定性和但節點問題，則可以用keepalived的VIP的浮動功能，加以強化。

MyCAT功能和特性

支持SQL 92標準
支持Mysql集羣，可以作爲Proxy使用
支持JDBC連接多數據庫
支持NoSQL數據庫
支持galera sfor mysql集羣，percona-cluster或者mariadb cluster，提供高可用性分片集羣
自動故障切換，高可用性
支持讀寫分離，支持MySQL雙主多從，以及一主多從的模式
支持全局表，數據自動分片到多個節點，用於高效表關聯查詢
支持一致性Hash分片，有效解決分片擴容難題
多平臺支持，部署和試試簡單
支持Catelet開發，類似數據庫存儲過程，用於跨分片複雜SQL的人工智能編碼實現
支持NIO與AIO兩種網絡通信機制，windows下建議AIO,Linux下目前建議NIO
支持MySQL存儲過程調用
以插件的方式支持SQL攔截和改寫
支持自增長逐漸、支持Oracle的Sequence機制
支持Mysql, MongoDB，Oracle, SQL Server, Hive, DB2, PostgreSQL等。

MyCAT目前的項目

MyCAT-Server:MyCAT核心服務
MyCAT-Spider:MyCAT爬蟲技術
MyCAT-ConfigCenter:MyCAT配置中心
MyCAT-BigSQL:MyCAT大數據處理（暫未更細）
MyCAT-Web:MyCAT監控及web（新版開發中）
MyCAT-Balance:MyCAT負載均衡（暫未更細）

DRDS/TDDL

alibaba. Distributed Relational Database Service.

阿里分佈式數據庫DRDS的前身是淘寶分佈式數據庫層TDDL，大概在2012年的時候，阿里開始嘗試將TDDL這套體系輸出到阿里雲上，也有了一個新的名字：DRDS.

TDDL

Tabao根據自己的業務特點開發了TDDL(Tabao Distributed Data Layer, 外號：頭都大了)。主要解決了分庫分表對應用的透明化以及異構數據庫之間的數據複製，它是一個基於集中式配置的jdbc datasourcce實現，具有主備，讀寫分離，動態數據庫配置等功能。

TDDL並非獨立的中間件，只能算作中間層，是以Jar包方式提供給應用調用。屬於JDBC Shard的思想。

TDDL處於業務層和JDBC層中間。

TDDL其實主要可以劃分爲3層架構，分別是Matrix層，Group層和Atom層。Matrix層用於實現分庫分表邏輯，底層多個Group實例。而Group和Atom共同組成了動態數據源，Group層實現了數據庫的Master/Slave模式的寫分離邏輯，底層持有多個Atom實例。最後Atom層（持有數據源）實現數據庫ip, port, password, connectionProperties等信息的動態推送，以及持有院子的數據源分離的JBoss數據源。

TDDL社區處於停滯狀態，網上可查資源也較少。

RDRS

DRDS/TDDL是阿里巴巴自主研發的分佈式數據庫服務。DRDS脫胎於阿里巴巴開源的Cobar分佈式數據庫引擎，吸收了Cobar核心的Cobar-Proxy源碼，實現了一套獨立的類似MySQL-Proxy協議的解析端，能夠對傳入的SQL進行解析和處理，對應用程序屏蔽各種複雜的底層DB拓撲結構，獲得單機數據庫一樣的使用體驗，同時借鑑了淘寶TDDL豐富的分佈式數據庫實踐經驗，實現了對分佈式Join支持，SUM/MAX/COUNT/AVG等聚合函數支持以及排序等函數支持，通過異構索引、小表廣播等解決分佈式數據庫使用場景下衍生出的一系列問題，最終形成了完整的分佈式數據庫方案。

DRDS在整個阿里系統中所處的位置：

對於很多應用而言，單機數據庫最終都會碰到單機性能上的天花板，在TPS/QPS/內存容量/磁盤容量等等一系列系統資源上會碰到各類限制。DRDS的主要目標就是幫您解決這方面的各類問題，他主要提供了兩個功能，讀寫分離和數據庫切分:

讀寫分離，能夠運行實現一臺機器寫入，多臺機器讀取，這對於讀多寫少的應用，能夠以極低的成本解決系統的瓶頸。
數據庫切分是一個解決系統存儲瓶頸的最終極解決方案，數據庫切分的核心思想其實很簡單，就是分而治之。將數據分散到多臺機器，並保證請求能夠平均的分發到這些機器上，就可以以極低的成本來解決業務的各類性能瓶頸。當然切分也是有代價的，最明顯的代價就是，分佈式數據庫會對一些原有單機數據的場景進行限制，因爲這些操作，在分佈式環境下的延遲或效率非常低效，就算是能夠實現出來，也會因爲性能問題而無法使用。

其他功能特性

1.分佈式MySQL執行引擎

主要目標是實現與單機數據庫SQL引擎的完全兼容，實現SQL的智能下推，能夠智能分析SQL，解析出那些SQL可以直接下發，那些SQL需要進行優化改造，優化成什麼樣，以及路由到哪些實例節點上執行，充分發揮數據庫實例的全部能力，減少網絡之間的數據傳輸量，最終對不同實例處理後的少量結果進行聚合計算返回給應用調用方。這就是分佈式SQL引擎的智能下推功能。
分佈式引擎的職責包含SQL解析，優化，執行和合並四個流程。

支持市面上幾乎所有的語言（具有MySQL訪問能力的），兼容90%以上MySQL語法。

案例分析：
比如一個簡單的AVG操作，對於一些比較初級的分佈式數據庫模型而言，常見做法是把AVG直接下發到所有存儲節點，這樣造成的結果就是語法兼容，語義不兼容，最終拿到的是錯誤結果。而DRDS的智能下推引擎，對SQL的語法做充分的語義兼容性適配，針對AVG操作，只能由引擎將邏輯AVG SQL解析優化爲SUM和COUNT的SQL然後進行下推，由底層的數據庫實例節點完成SUM和COUNT計算，充分利用底層節點的計算能力，在引擎層將各個存儲節點的SUM和COUNT結果聚合計算，最終計算出AVG。

2.在線平滑擴容

在線數據擴容的重點在於“在線”兩字，也就是用戶不需要停止業務進行割接操作，直接就可以添加新的RDS節點到集羣中，實現無縫的自由擴展。RDRS則將整個擴容過程分爲幾個階段，包括全量遷移，增量同步，切換數據庫等幾個步驟。數據會提前進行搬遷，並進行增量並行同步一段時間，因此，我們可以在非常短的時間內（秒級別）完成數據庫的最終擴容切換工作，對業務沒有影響。

3.小表廣播

在一些大的業務表進行了切分後，總會存在一些表的數據量不大，更新量也不大的原始信息表。這些表往往會與我們的切分後大表進行join操作，這種操作物理上就會造成分佈式join查詢，效率從整體上會比較地下。針對這種分佈式join的場景，開發了OETL專用工具來進行小表廣播，將原信息表的所有數據（包括增量更新）全部自動的廣播到大表的機器上，這樣，就可以讓原來的分佈式查詢變成單機本地查詢了。

4.全局唯一ID

DRDS sequence功能的目標只是爲了保證數據的全局唯一，雖然基本上是按時間序列獲取的，但並不全局有序。

5.異構索引

解決分佈式場景下數據拆分維度和數據查詢使用維度不一致導致的低效問題。

當數據表被拆分爲多個分庫分表時，數據在分庫分表的分佈規則就固定了。但是通常數據的業務使用場景非常複雜，如果數據的查詢維度和數據拆分分佈的規則一直，單條SQL會在一個分庫分表上執行；如果數據的查詢使用維度和數據拆分分佈的規格不一致，單條SQL可能在多個分庫分表上執行，出現跨庫查詢，跨庫查詢會增加IO成本，查詢效率必然下降。

解決這個問題的思路還是分佈式數據庫的一貫原則，讓SQL執行在單庫上完成，實際採用的方式就是用“空間換效率”的方案，也就是將同一份數據表，冗餘存儲多份，按照不同的業務使用場景進行拆分，保持拆分維度和使用維度統一，而多份數據之間會實時數據複製以解決數據一致性問題，這就是“異構索引”方案。當然異構索引表不能無限制濫用，過多的異構索引表會影響同步效率，對源數據表造成同步壓力。

其他同款中間件

Altas, Vitess, Heisenberg, CDS, DDB， OneProxy等等。

Atlas

Qihoo 360.
Web平臺部基礎架構團隊開發維護的一個基於MySQL協議的數據中間層項目，它是在mysql-proxy 0.8.2版本上對其進行優化，增加了一些新的功能特性。
Atlas是一個位於應用程序與MySQL之間，它實現了MySQL的客戶端和服務端協議，作爲服務端與應用程序通訊，同時作爲客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節。
Altas不能實現分佈式分表，所有的字表必須在同一臺DB的同一個DataBase裏且所有的字表必須實現建好，Altas沒有自動建表的功能。

Heisenberg

Baidu.
其優點：分庫分表與應用脫離，分庫表如同使用單庫表一樣，減少db連接數壓力，熱重啓配置，可水平擴容，遵守MySQL原生協議，讀寫分離，無語言限制，mysqlclient, c, Java都可以使用Heisenberg服務器通過管理命令可以查看，如連接數，線程池，結點等，並可以調整採用velocity的分庫分表腳本進行自定義分庫表，相當的靈活。
（開源版已停止維護）

CDS

JD. Completed Database Sharding.
CDS是一款基於客戶端開發的分庫分表中間件產品，實現了JDBC標準API，支持分庫分表，讀寫分離和數據運維等諸多共，提供高性能，高併發和高可靠的海量數據路由存取服務，業務系統可近乎零成本進行介入，目前支持MySQL, Oracle和SQL Server.
(架構上和Cobar，MyCAT相似，直接採用jdbc對接，沒有實現類似MySQL協議，沒有NIO,AIO，SQL Parser模塊採用JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)

DDB

豬場. Distributed DataBase.
DDB經歷了三次服務模式的重大更迭：Driver模式->Proxy模式->雲模式。

Driver模式：基於JDBC驅動訪問，提供一個db.jar, 和TDDL類似，位於應用層和JDBC之間.
Proxy模式：在DDB中搭建了一組代理服務器來提供標準的MySQL服務，在代理服務器內部實現分庫分表的邏輯。應用通過標準數據庫驅動訪問DDB Proxy, Proxy內部通過MySQL×××將請求還原爲SQL, 並由DDB Driver執行得到結果。
私有云模式：基於網易私有云開發的一套平臺化管理工具Cloudadmin, 將DDB原先Master的功能打散，一部分分庫相關功能集成到proxy中，如分庫管理、表管理、用戶管理等，一部分中心化功能集成到Cloudadmin中，如報警監控，此外，Cloudadmin中提供了一鍵部署、自動和手動備份，版本管理等平臺化功能。

數據增量訂閱與消費

基於數據庫增量日誌解析，提供增量數據訂閱&消費，目前主要支持了mysql.
有關數據增量訂閱與消費的中間件回顧一下：

增量訂閱和消費模塊應當包括binlog日誌抓取，binlog日誌解析，事件分發過濾（EventSink），存儲（EventStore）等主要模塊。
如果需要確保HA可以採用Zookeeper保存各個子模塊的狀態，讓整個增量訂閱和消費模塊實現無狀態化，當然作爲consumer(客戶端)的狀態也可以保存在zk之中。
整體上通過一個Manager System進行集中管理，分配資源。

Canal

Canal架構圖：

說明：

server代表一個canal運行實例，對應於一個jvm
instance對應於一個數據隊列（1個server對應1..n個instance)

instance模塊：

eventParser (數據源接入，模擬slave協議和master進行交互，協議解析)
eventSink (Parser和Store鏈接器，進行數據過濾，加工，分發的工作)
eventStore (數據存儲)
metaManager (增量訂閱&消費信息管理器)

說明：一臺機器下部署一個canal，一個canal可以運行多個instance(通過配置destinations等), 一般情況下一個client連接一個instance（每個instance可以配置standby功能）, 可以多個client連接同一個instance，但是同一時刻只能有一個client消費instance的數據，這個通過zookeeper控制。

數據庫同步

Otter

背景：alibaba B2B因爲業務的特性，賣家主要集中在國內，買家主要集中在國外，所以衍生出了杭州和美國異地機房的需求，同時爲了提升用戶體驗，整個機房的架構爲雙A，兩邊均可寫，由此誕生了otter這樣一個產品。

otter第一版本可追溯到04~05年，此次外部開源的版本爲第4版，開發時間從2011年7月份一直持續到現在，目前阿里巴巴B2B內部的本地/異地機房的同步需求基本全上了otter4。

基於數據庫增量日誌解析，準實時同步到本地機房或異地機房的mysql/oracle數據庫，一個分佈式數據庫同步系統。

工作原理

原理描述：

基於Canal開源產品，獲取數據庫增量日誌數據。
典型管理系統架構，manager(Web管理)+node(工作節點)

manager運行時推送同步配置到node節點
node節點將同步狀態反饋到manager上

基於zookeeper，解決分佈式狀態調度的，允許多node節點之間協同工作。

Otter的作用

異構庫

mysql->mysql、oracle. (目前開原版只支持mysql增量，目標庫可以是mysql或者oracle,取決於canal的功能)

單機房同步（數據庫之間RTT(Round-Trip Time)<1ms）

數據庫版本升級
數據表遷移
異步二級索引

跨機房同步（比如阿里巴巴國際站就是杭州和美國機房的數據庫同步，RTT>200ms）

機房容災

雙向同步

避免迴環算法（通用的解決方案，支持大部分關係型數據庫）
數據一致性算法（保證雙A機房模式下，數據保證最終一直性）

文件同步

站點鏡像（進行數據複製的同時，複製關聯的圖片，比如複製產品數據，同事複製產品圖片）

單機房複製示意圖

說明：
- 數據On-Fly, 儘可能不落地，更快的進行數據同步。（開啓node load balance算法, 如果Node節點S+ETL落在不同的Node上，數據會有個網絡傳輸過程）
- node節點可以有failover/loadBalancer.

SETL

S: Select
爲解決數據來源的差異性，比如接入canal獲取增量數據，也可以接入其他系統獲取其他數據等。

E: Extract

T: Transform

L: Load

類似於數據倉庫的ETL模型，具體可爲數據join，數據轉化，數據加載。

跨機房複製示意圖

數據涉及網絡傳輸，S/E/T/L幾個階段會分散在2個或者更多Node節點上，多個Node之間通過zookeeper進行協同工作（一般是Select和Extract在一個機房的Node, Transform/Load落在另一個機房的Node）
node節點可以有failover/loadBalancer。(每個機房的Node節點，都可以是集羣，一臺或者多臺機器)

異地雙活數據架構基礎設施DRC

所謂DRC，就是Data Replication Center的縮寫，數據複製中心。這種複製是同步的，支持異構的，高可用的（有嚴格容災系統，實時性好），支持訂閱分發的。項目期初是爲了淘寶異地容災而成立的，用於數據庫之間主備同步，後來採用這套技術方案衍生出了DRC-TAIR, DRC-DUMP等項目。

所謂異地雙活主要關注兩件事，一個數據同步，一個數據分發。

到底怎樣的應用會需要異地的雙活？比較常見的場景有三個：

兩個地域或多個地域都有大量用戶的場景，比如在中國的用戶希望他們用杭州的RDS服務，在美國的用戶用美國的RDS服務，這就需要數據在異地同步。很多遊戲，金融，傳媒，電商業務都有這種需求。滿足這個需求的難點在於跨地域的網絡，比如網絡延時長，丟包多，而且數據在公網傳輸會有數據泄露風險。
數據來源較多，需要介入各種異構數據的場景。比如一個應用需要從ODPS, RDS, OTS， OceanBase, PostgreSQL這幾個服務介入數據，他們的數據結構和接口都不同，這種接入的成本會比較高。因此另一個可用的方法是數據寫入的時候就一份多謝爲不同數據結構
下游訂閱很多的情況，比如一份數據，備份系統、通知系統、大數據分析系統、索引系統等等都要來取，如果用上面一份數據多寫的方案是可以應對的，但這裏還有其他難點，就是數據一致性、可擴展性、跨網同步穩定性、以及同步的實時性。

DRC支持讀取集團MySQL, RDS, OceanBase, HBase, Oracle等多種不同的數據源的實時增量數據，支持寫入數據庫、MetaQ, ODPS等多種存儲媒介.

以前在一個城市做雙機房主備，兩個機房是數據對等的，寫入是隨機分佈，然後通過主備HA進行數據同步。這樣機房對等的思路會導致業務增長、數據增長只能通過兩個機房不停堆機器來解決。另一方面，如果整個城市斷電，那麼雙活就成了雙死。下一個思路是做跨城市，早期常用的做法是一個城市寫，另一個城市冷備，就是晚上做同步，但這就意味着白天如果發生了什麼事兒，這一天的數據就比較危險。另一個思路是兩個城市多寫，數據落兩邊，這樣的問題是應用調用次數頻繁的話，如果調用異地數據多來那麼一兩次，整個應用的延時就很長。這個思路再進一步發展，就是做單元內封閉以減少異地調用，這就涉及到業務上的改造。

順着這個思路，阿里的異地雙活重點做了幾件事。一個是熱插拔，可以做到在業務高峯時增加節點，高峯過了把增加的節點關閉。做到這個的一個關鍵是流量實時切換，DRC可以在20秒以內把一個單元（region）的流量遷移到另一個單元。另一個是數據實時恢復，就是通過一定的冗餘設計，一旦一個單元掛掉了，可以在另一個單元做全量恢復。

異地多活在數據方面的挑戰是非常大的。雙十一期間，交易會激增，所以交易鏈路做了單元化。交易鏈路的數據分爲三個維度：買家、賣家、商品。買家之間通常沒有太多交叉，天然的適應這種隔離，而且賣家對延遲的敏感度非常高，所以按照賣家維度切分，在單元內封閉，而賣家和商品都是在中心寫入。

數據方面的兩個核心要求：

一致性，要求賣家和商品一致，單元和中心一致，也就是數據同步不能丟數據，不能錯數據，還要保證事務。
實時性，需要做到秒級別的延遲。

雙單元的同步架構有兩種：
一種是讀寫分離的方式，中心寫，單元讀。單元需要的數據如果沒有從中心及時同步過來，或者同步錯了，那有問題這段時間的交易會全部收到影響。這裏的核心是，保證秒級延遲，同時保證一致性。（JD的多中心交易系統就採用了這種方式）

第二種同步架構是單元封閉的方式。中心和單元各有寫入，我們通過冗餘是的中心和單元隨時可以各自接管。（類似Otter）

這裏的關鍵是：

避免循環複製：通過在DB透傳打標事務的方式實現。
限流：峯值的壓力，我們單元化本來就選取了流量激增業務，兩邊都實時同步100%全量數據，峯值對每個系統的壓力有增無減。DRC的store和congo都可以根據TPS或者流量限流。限速算法的核心思想分爲批量採樣，獎懲時間，平滑變速。

Otter與DRC的區別：
- Otter是阿里B2B的產品，DRC是阿里技術保障團隊的產品
- Otter是針對MySQL的，DRC可以支持多種類型的數據源
- DRC從業務上進行了劃分，可以實現單元內封閉，Otter的實現不涉及業務，而是在純數據庫層打通的技術
- Otter是雙寫，DRC是中心寫、分中心讀，或者都部分寫，相互同步。
- Otter所處的網絡環境較DRC差，解決一致性問題也較複雜（基於trusted source的單向環回的補救，基於時間交集的補救），DRC有兩種實現方式，具體參考上面。

異地多活中DRC的核心能力就是在低延遲，一致性和高可用。

一致性：基於日誌流式抓取、回放庫表結構變更、基於事務的衝突檢測。
低延遲：最大延遲不超過1s, 消息協議優化，三級數據存儲，預讀優化IO, 多連接複用和傳輸壓縮，高效的併發複製算法。
高可用：主備切換，拓撲變化，心跳跟蹤，多維度容災。

JD多中心交易系統

JD. 多中心交易系統。

JD數據複製中間件考察和借鑑了開源社區的實現，例如Databus、Canal/Otter、OpenReplicator等，解析部分使用了Canal的DBSync。

多中心交易本質上是一個更大的分佈式系統，交易流程中依賴和產生的數據和服務有不同的特點，必然涉及到數據分區、路由、複製、讀寫一致性、延遲等分佈式領域的常見問題。

其中，數據一致性是電商網站需要面臨的首要問題，越是流量增大的時候越要保證數據更新的即時性和準確性。在多中心之間需要同步賣家數據和商品數據，如果同步的延時太長，買家、賣家都不可接受。比如，賣家改了價格或庫存，用戶不能過很久纔看到。同樣，數據正確性也是很大的挑戰，賣掉的商品能夠及時減少，退貨的商品能夠及時增加。這都時刻考驗着後端系統和數據庫平臺的健壯性。

除了數據一致性之外，如何保證路由規則的一致性也是關鍵性的問題。從技術角度來說，要保障單一用戶從登錄到訪問服務、到訪問數據庫，全鏈路的路由規則都是完全一致的。如果路由錯誤，看到的數據不正確，也會影響到最終用戶的體驗。

架構

系統包括一個主中心和多個分中心，主中心與分中心之間通過數據總線交換數據。數據流向中，主數據(商品數據、商家數據、用戶數據等)的流向從主中心通過數據總線實時同步到分中心，分中心只讀；而交易數據(訂單數據)的流向從分中心實時同步到主中心；在故障時，會從分中心轉移到主中心。

在這個系統中，有多處體現分流的概念。首先，買家訪問京東網站下單時，會被優先分流到附近的交易中心；其次，根據交易系統的特點，接單前（包括購物車、結算頁等），多中心交易按用戶維度分流，如下圖所示。用戶登錄時，查詢用戶與區域的映射關係表（類似你是哪個片區的），標識此用戶屬於哪個分中心，並保存標識到cookie中，然後將用戶路由到指定的分中心。用戶訪問其他系統，如購物車和結算頁時，從cookie中讀取標識，重定向到相應分中心頁面。

通過分流，將用戶分配到相應的分中心，一方面響應速度快，用戶體驗更好，不用跨地域訪問數據中心了；另一方面，每個中心服務一定數量的用戶，水平擴展性好，也能支撐更大的交易規模了。當然，多數據中心不能盲目幹活，還考慮到容災備份的問題。（支付寶光纖事件）

交易系統包括應用和數據部分，應用部分是無狀態的，就是說，這些工作是無差別的，一臺服務器出問題，我換一臺服務器來處理就是了，較容易實現多機房多活。但是數據不一樣，多中心交易本質上是一個更大的分佈式系統，必然涉及到數據分區、路由、複製、讀寫一致性、延遲等分佈式領域的常見問題。

另外，交易流程中依賴和產生的數據和服務有不同的特點。比如商品、促銷和價格、庫存的讀服務，我們可以將之稱爲基礎主數據，它們在用戶下單流程中是無法分區的，否則無法實現單機房內流量閉環，也就是說，不能因爲分區數據的不一致，導致同一用戶在單一流程中看到不同的數據（假如你加入購物車時是促銷20塊，結賬是25塊，你會不會表情扭曲？）而商品、促銷和價格的寫服務,是給採銷、第三方POP商家應用調用的，這種業務場景的可用性目標，主機房部署和冷備模式即可滿足，而且業務人員的操作流程會抵消寫複製延遲。

簡單來說，數據的問題表現在以下幾個方面：一、如何保證數據的即時性和準確性，多中心之間需要同步賣家數據和商品數據，如果同步的延時太長,買家、賣家都不可接受，由於是異地部署，最好延時能控制在1秒內。比如，賣家改了價格或庫存，用戶不能過很久纔看到。同樣，數據正確性也是很大的挑戰,因爲數據故障跟應用層故障不一樣，應用出故障了，可能隻影響用戶訪問；數據寫錯了無法恢復。2、如何保證路由規則的一致性，要保障這個用戶從進來到訪問服務，到訪問數據庫，全鏈路的路由規則都是完全一致的；如果路由錯誤，看到的數據不正確。

從同城雙機房的分佈轉變爲異地多機房的分佈，給數據同步帶來了新的挑戰，因此如何設計數據總線也是項目能否實現的關鍵因素。京東的多中心交易系統通過數據總線JingoBus進行快速數據交換，同步性能是mysql的3倍以上，而且可用性高，架構靈活。其中，全新的總線設計解決了多中心交易跨機房的數據庫複製和多數據源間的數據異構同步等難題，實現了高性能、低延時、健壯的數據同步機制。

如圖所示，數據總線主要分Relay、Snapshot和Replicator三部分構成，其中Relay從來源數據庫抽取事務日誌，並對Replicator提供日誌訂閱服務，角色上相當於Mysql Slave IO Thread。Snapshot從Relay訂閱所有事務日誌，寫入持久存儲作爲快照，同時向Replicator提供批量日誌訂閱服務，角色上相當於Mysql Slave Relay Log。Replicator：事務日誌的消費端，從Relay或Snapshot拉取事務日誌將事務日誌按配置的一致性應用到目標數據庫，角色上相當於Mysql Slave SQL Thread。(參考下面MySQL主備複製原理圖)

正常情況下，Replicator直接連接Relay，消費Relay內存隊列中的事務日誌。但有些情況下，因爲網絡抖動、目標庫的負載過高等因素，可能導致Replicator相對Relay落後很多。另外，當新的消費端加入同一數據源的訂閱者時，新消費端有冷啓動的問題。爲了避免重新從數據源做全量快照，Snapshot作爲Relay的一個特殊消費端，通過一種高吞吐的消費方式，從Relay源源不斷的消費在線事務日誌，通過對事務日誌的有效處理，最終保存了數據源的一份一致快照(Consistent Snapshot)，即包括了數據源庫表中每一行的最新狀態的快照，同時保留了一段比Relay buffer更舊的事務日誌(Log Store)。由此看來，數據總線作爲一個數據層的通用CDC組件，對於多中心交易項目以及異步複製場景提供了整體解決方案，奠定了項目的核心內容。

跨數據庫（數據源）遷移

yugong

去Oracle數據遷移同步工具。定位：數據庫遷移（目前主要支持Oracle->mysql/DRDS）

08年左右，阿里巴巴開始嘗試MySQL的相關研究，並開發了基於MySQL分庫分表技術的相關產品，Cobar/TDDL(目前爲阿里雲DRDS產品)，解決了單機Oracle無法滿足的擴展性問題，當時也掀起一股去IOE項目的浪潮，愚公這項目因此而誕生，其要解決的目標就是幫助用戶完成從Oracle數據遷移到MySQL上，完成去IOE的第一步.

概述

整個數據遷移過程，分爲兩個部分：

全量遷移
增量遷移

過程描述：

增量數據收集（創建Oracle表的增量物化視圖）
進行全量複製
進行增量複製（可並行進行數據校驗）
原庫停寫，切換到新庫

Oracle全量基於JDBC拉取數據，增量基於物化視圖來實現。

架構

說明：

一個JVM Container 對應多個instance，每個instance對應於一張表的遷移任務
instance分爲三部分

extractor (從數據源庫上提取數據，可分爲全量/增量實現)
translator （將源庫上的數據按照目標庫的需求進行自定義轉化）
applier（將數據更新到目標庫，可分爲全量/增量/對比的實現）

自定義數據轉換

如果要遷移的Oracle和mysql的表結構不同，比如表名，字段名有差異，字段類型不兼容，需要使用自定義數據轉換。如果完全相同則可以跳過。

整個數據流爲：DB->Extractor->DataTranslator->Applier->DB, 本程序預留DataTranslator接口（僅支持Java），允許外部用戶自定義數據處理邏輯。比如：

表名不同
字段名不同
字段類型不同
字段個數不同
運行過程join其他表的數據做計算等

運行模式介紹

1.MARK模式（MARK）

開啓增量日誌模式，如果是Oracle就是創建物化視圖（materialized view）。

2.CLEAR模式（CLEAR）

清理增量日誌的機率，如果是Oracle就是刪除物化視圖

3.全量模式（FULL)

全量模式，顧名思議即爲對源表進行一次全量操作，遍歷源表所有的數據後，插入目標表.

全量有兩種處理方式：

分頁處理：如果源表存在主鍵，只有一個主鍵字段，並且主鍵字段類型爲Number類型，默認會選擇該分頁處理模式. 優點：支持斷點續做，對源庫壓力相對較小。缺點：遷移速度慢
once處理：通過select * from訪問整個源表的某一個mvcc版本的數據，通過cursor.next遍歷整個結果集. 優點：遷移速度快，爲分頁處理的5倍左右。缺點：源庫壓力大，如果源庫併發修改量大，會導致數據庫MVCC版本過多，出現棧錯誤. 還有就是不支持斷點續做.

4.增量模式（INC）

全量模式，顧名思議即爲對源表增量變化的數據插入目標表，增量模式依賴記錄日誌功能.

目前增量模式的記錄日誌功能，是通過oracle的物化視圖功能。

5.自動模式(ALL)

自動模式，是對全量+增量模式的一種組合，自動化運行，減少操作成本.

自動模式的內部實現步驟：

開啓記錄日誌功能. (創建物化視圖)
運行全量同步模式. (全量完成後，自動進入下一步)
運行增量同步模式. (增量模式，沒有完成的概念，所以也就不會自動退出，需要業務判斷是否可以退出，可以看一下切換流程)

6.對比模式(CHECK)

對比模式，即爲對源庫和目標庫的數據進行一次全量對比，驗證一下遷移結果. 對比模式爲一種可選運行，做完全量/增量/自動模式後，可選擇性的運行對比模式，來確保本次遷移的正確性.

DataX

DataX是一個在異構的數據庫/文件系統之間高速交換數據的工具，實現了在任意的數據處理系統(RDBMS/Hdfs/Local filesystem）之間的數據交換。

目前成熟的數據導入導出工具比較多，但是一般都只能用於數據導入或者導出，並且只能支持一個或者幾個特定類型的數據庫。

這樣帶來的一個問題是，如果我們擁有很多不同類型的數據庫/文件系統(Mysql/Oracle/Rac/Hive/Other…)，並且經常需要在它們之間導入導出數據，那麼我們可能需要開發/維護/學習使用一批這樣的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以後每增加一種庫類型，我們需要的工具數目將線性增長。(當我們需要將mysql的數據導入oracle的時候，有沒有過想從jdbcdump和dbloader上各掰下來一半拼在一起到衝動？)這些工具有些使用文件中轉數據，有些使用管道，不同程度的爲數據中轉帶來額外開銷，效率差別很非常大。很多工具也無法滿足ETL任務中常見的需求，比如日期格式轉化，特性字符的轉化，編碼轉換。另外，有些時候，我們希望在一個很短的時間窗口內，將一份數據從一個數據庫同時導出到多個不同類型的數據庫。DataX正是爲了解決這些問題而生。

左圖：新增第n+1個數據源，是不是需要開發n個數據同步工具？
右圖：只需要針對新增的數據源開發一套Reader/Writer插件，即可實現任意數據的互導。

設計理念

爲了解決異構數據源同步問題，DataX將複雜的網狀的同步鏈路變成了星型數據鏈路，DataX作爲中間傳輸載體負責連接各種數據源。當需要接入一個新的數據源的時候，只需要將此數據源對接到DataX，便能跟已有的數據源做到無縫數據同步。

DataX在阿里巴巴集團內被廣泛使用，承擔了所有大數據的離線同步業務，並已持續穩定運行了6年之久。目前每天完成同步8w多道作業，每日傳輸數據量超過300TB。

框架設計

DataX本身作爲離線數據同步框架，採用Framework+plugin架構構建。將數據源讀取和寫入抽象稱爲Reader/Writer插件，納入到整個同步框架中。

Reader： Reader爲數據採集模塊，負責採集數據源的數據，將數據發送給Framework.
Writer：Writer爲數據寫入模塊，負責不斷向Framework取數據，並將數據寫入到目的端
Framework：Framework用於連接reader和writer,作爲兩者的數據傳輸通道，並處理緩存，流控，併發，數據轉換等核心技術問題。

DataX框架內部通過雙緩衝隊列、線程池封裝等技術，集中處理了高速數據交換遇到的問題，提供簡單的接口與插件交互，插件分爲Reader和Writer兩類，基於框架提供的插件接口，可以十分便捷的開發出需要的插件。比如想要從oracle導出數據到mysql，那麼需要做的就是開發出OracleReader和MysqlWriter插件，裝配到框架上即可。並且這樣的插件一般情況下在其他數據交換場合是可以通用的。

核心架構

DataX3.0 開源版本支持單機多線程模式完成同步作業運行，這裏按一個DataX作業生命週期的時序圖，從整體架構設計非常簡要說明DataX各個模塊相互關係。

核心模塊介紹：

DataX完成單個數據同步的作業，我們稱之爲Job，DataX接受到一個Job之後，將啓動一個進程來完成整個作業同步過程。DataX Job模塊是單個作業的中樞管理節點，承擔了數據清理、子任務切分(將單一作業計算轉化爲多個子Task)、TaskGroup管理等功能。
DataXJob啓動後，會根據不同的源端切分策略，將Job切分成多個小的Task(子任務)，以便於併發執行。Task便是DataX作業的最小單元，每一個Task都會負責一部分數據的同步工作。
切分多個Task之後，DataX Job會調用Scheduler模塊，根據配置的併發數據量，將拆分成的Task重新組合，組裝成TaskGroup(任務組)。每一個TaskGroup負責以一定的併發運行完畢分配好的所有Task，默認單個任務組的併發數量爲5。
每一個Task都由TaskGroup負責啓動，Task啓動後，會固定啓動Reader—>Channel—>Writer的線程來完成任務同步工作。
DataX作業運行起來之後， Job監控並等待多個TaskGroup模塊任務完成，等待所有TaskGroup任務完成後Job成功退出。否則，異常退出，進程退出值非0。

DataX調度流程：

舉例來說，用戶提交了一個DataX作業，並且配置了20個併發，目的是將一個100張分表的mysql數據同步到odps裏面。 DataX的調度決策思路是：
1. DataXJob根據分庫分表切分成了100個Task。
2. 根據20個併發，DataX計算共需要分配4個TaskGroup。
3. 4個TaskGroup平分切分好的100個Task，每一個TaskGroup負責以5個併發共計運行25個Task。

數據庫相關中間件介紹