數據庫相關中間件全家桶

時間 2019-12-02

原文原文鏈接

原文連接：http://blog.csdn.net/u013256816/article/details/52769297前端

數據庫中間件

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

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

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

數據庫中間件有如下幾種：mysql

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

整個產品族圖以下：git

最上層的是分佈式數據庫分表分庫中間件，負責和上層應用打交道，對應用可表現爲一個獨立的數據庫，而屏蔽底層複雜的系統細節。分佈式數據庫中間件除了基本的分表分庫功能，還能夠豐富一下，好比講讀寫分離或者水平擴容功能集成在一塊兒，或者好比讀寫分離自己也能夠做爲一個獨立的中間件。（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和內存等單機瓶頸，爲此，產品方除了須要不斷購買成本難以控制的高規格服務器，還要面臨不斷迭代的在線數據遷移。在這種狀況下，不管是海量的結構化數據仍是快速成長的業務規模，都迫切須要一種水平擴展的方法將存儲成本分攤到成本可控的商用服務器上。同時，也但願經過線性擴容下降全量數據遷移對線上服務帶來的影響，分庫分表方案便應運而生。github

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

一種是以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語句變動並按照數據分佈規則發到合適的後臺數據分庫，再合併返回結果，模擬單庫下的數據庫行爲。sql

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

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、如何保證數據的即時性和準確性，多中心之間須要同步賣家數據和商品數據，若是同步的延時太長,買家、賣家都不可接受，因爲是異地部署，最好延時能控制在1秒內。好比，賣家改了價格或庫存，用戶不能過好久纔看到。一樣，數據正確性也是很大的挑戰,由於數據故障跟應用層故障不同，應用出故障了，可能隻影響用戶訪問；數據寫錯了沒法恢復。二、如何保證路由規則的一致性，要保障這個用戶從進來到訪問服務，到訪問數據庫，全鏈路的路由規則都是徹底一致的；若是路由錯誤，看到的數據不正確。

從同城雙機房的分佈轉變爲異地多機房的分佈，給數據同步帶來了新的挑戰，所以如何設計數據總線也是項目可否實現的關鍵因素。京東的多中心交易系統經過數據總線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。