數(shù)據(jù)庫中間件'>數(shù)據(jù)庫中間件這里主要介紹互聯(lián)網行業(yè)內有關數(shù)據(jù)庫的相關中間件。數(shù)據(jù)庫相關平臺主要解決以下三個方面的問題： 為海量前臺數(shù)據(jù)提供高性能、大容量、高可用性的訪問 為數(shù)據(jù)變更的消費提供準實時的保障 高效的異地數(shù)據(jù)同步應用層通過分表分庫中間件訪問數(shù)據(jù)庫，包括讀操作（Select）和寫操作（update, insert和delete等，DDL, DCL）。寫操作會在數(shù)據(jù)庫上產生變更記錄，MySQL的變更記錄叫binlog, Oracle的稱之為redolog, 增量數(shù)據(jù)訂閱與消費中間件解析這些變更，并以統(tǒng)一的格式保存起來，下層應用根據(jù)這些數(shù)據(jù)進行消費應用。當然，在數(shù)據(jù)庫與數(shù)據(jù)庫本身之間也會有數(shù)據(jù)庫遷移的操作，這種操作可以不需要增量數(shù)據(jù)訂閱與消費中間件的數(shù)據(jù)，而可以自行處理。 數(shù)據(jù)庫中間件有以下幾種： 分布式數(shù)據(jù)庫分表分庫 數(shù)據(jù)增量訂閱與消費 數(shù)據(jù)庫同步（全量、增量、跨機房、復制） 跨數(shù)據(jù)庫（數(shù)據(jù)源）遷移整個產品族圖如下：
分布式數(shù)據(jù)庫隨著互聯(lián)網產品在體量和規(guī)模上日益膨脹，無論是Oracle還是MySQL，都會第一時間面臨來自磁盤，CPU和內存等單機瓶頸，為此，產品方除了需要不斷購買成本難以控制的高規(guī)格服務器，還要面臨不斷迭代的在線數(shù)據(jù)遷移。在這種情況下，無論是海量的結構化數(shù)據(jù)還是快速成長的業(yè)務規(guī)模，都迫切需要一種水平擴展的方法將存儲成本分攤到成本可控的商用服務器上。同時，也希望通過線性擴容降低全量數(shù)據(jù)遷移對線上服務帶來的影響，分庫分表方案便應運而生。 分表分庫類的中間件主要有兩種形式向應用提供服務： 一種是以JDBC的jar包形式為Java應用提供直接依賴，Java應用通過提供的JDBC包實現(xiàn)透明訪問分布式數(shù)據(jù)庫集群中的各個分庫分表，典型代表網易的DDB和阿里的TDDL. 另一種是為應用部署獨立的服務來滿足應用分庫分表的需求，在這種方式下通過標準JDBC訪問Proxy，而Proxy則根據(jù)MySQL標準通信協(xié)議對客戶端請求解析，還原應用SQL請求，然后通過本地訪問數(shù)據(jù)庫集群，最后再將得到的結果根據(jù)MySQL標準通信協(xié)議編碼返回給客戶端。典型代表阿里的Cobar, Cobar變種MyCAT, 阿里的DRDS，網易的DDB proxy模式以及DDB的私有云模式。CobarCobar 是提供關系型數(shù)據(jù)庫（MySQL）分布式服務的中間件，它可以讓傳統(tǒng)的數(shù)據(jù)庫得到良好的線性擴展，并看上去還是一個數(shù)據(jù)庫，對應用保持透明。 Cobar以Proxy的形式位于前臺應用和實際數(shù)據(jù)庫之間，對前臺的開放的接口是MySQL通信協(xié)議。將前臺SQL語句變更并按照數(shù)據(jù)分布規(guī)則發(fā)到合適的后臺數(shù)據(jù)分庫，再合并返回結果，模擬單庫下的數(shù)據(jù)庫行為。
Cobar結構
HA在用戶配置了MySQL心跳的情況下，Cobar可以自動向后端連接的MySQL發(fā)生心跳，判斷MySQL運行狀況，一旦運行出現(xiàn)異常，Cobar可以自動切換到備機工作，但需要強調的是： Cobar的主備切換有兩種觸發(fā)方式，一種是用戶手動觸發(fā)，一種是Cobar的心跳語句檢測到異常后自動觸發(fā)。那么，當心跳檢測到主機異常，切換到備機，如果主機恢復了，需要用戶手動切回主機工作，Cobar不會在主機恢復時自動切換回主機，除非備機的心跳也返回異常。 Cobar只檢查MySQL主備異常，不關心主備之間的數(shù)據(jù)同步，因此用戶需要在使用Cobar之前在MySQL主備上配置雙向同步，詳情可以參閱MySQL參考手冊。Cobar解決的問題分布式：Cobar的分布式主要是通過將表放入不同的庫來實現(xiàn)。 Cobar支持將一張表水平拆分成多份分別放入不同的庫來實現(xiàn)表的水平拆分 Cobar也支持將不同的表放入不同的庫 多數(shù)情況下，用戶將以上兩種方式混合使用這里需要強調的是，Cobar不支持將一張表，例如test表拆分成test_1, test_2, test_3….放在同一個庫中，必須拆分后的表分別放入不同的庫來實現(xiàn)分布式。 Cobar的約束不支持跨庫情況下的join、分頁、排序、子查詢操作 SET語句執(zhí)行會被忽略，事務和字符集設置除外 分庫情況下，insert語句必須包括拆分字段列名 分庫情況下，update語句不能更新拆分字段的值 不支持SAVEPOINT操作 暫時只支持MySQL數(shù)據(jù)節(jié)點 使用JDBC時，不支持rewriteBatchedStatements=true參數(shù)設置（默認為false） 使用JDBC時，不支持useServerPrepStmts=true參數(shù)設置（默認為false) 使用JDBC時，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()方法設置參數(shù)MyCAT從定義和分類看，它是一個開源的分布式數(shù)據(jù)庫系統(tǒng)，是一個實現(xiàn)了MySQL協(xié)議的Server，前端用戶可以把它看做是一個數(shù)據(jù)庫代理，用MySQL客戶端工具和命令行訪問，而其后端可以用MySQL Native Protocol與多個MySQL服務器通信，也可以用JDBC協(xié)議與大多數(shù)主流數(shù)據(jù)庫服務器通信，其核心功能是分表分庫，即將一個大表水平分割為N個小表，存儲在后端MySQL服務器里或者其他數(shù)據(jù)庫里。 MyCAT發(fā)展到目前的版本，已經不是一個單純的MySQL代理了，它的后端可以支持MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流數(shù)據(jù)庫，也支持MongoDB這種新型NoSQL方式的存儲，未來還會支持更多類型的存儲。 MyCAT是一個強大的數(shù)據(jù)庫中間件，不僅僅可以用作讀寫分離，以及分表分庫、容災管理，而且可以用于多租戶應用開發(fā)、云平臺基礎設施，讓你的架構具備很強的適應性和靈活性，借助于即將發(fā)布的MyCAT只能優(yōu)化模塊，系統(tǒng)的數(shù)據(jù)訪問瓶頸和熱點一目了然，根據(jù)這些統(tǒng)計分析數(shù)據(jù)，你可以自動或手工調整后端存儲，將不同的表隱射到不同存儲引擎上，而整個應用的代碼一行也不用改變。 MyCAT是在Cobar基礎上發(fā)展的版本，兩個顯著提高： 后端由BIO改為NIO，并發(fā)量有大幅提高； 增加了對Order By, Group By, Limit等聚合功能（雖然Cobar也可以支持Order By, Group By, Limit語法，但是結果沒有進行聚合，只是簡單返回給前端，聚合功能還是需要業(yè)務系統(tǒng)自己完成）MyCAT架構
HAMyCAT作為一個代理層中間件，MyCAT系統(tǒng)的高可用設計到MyCAT本身的高可用以及后端MySQL的高可用. 在多數(shù)情況下，建議采用MySQL主從復制高可用性配置并交付給MyCAT來完成后端MySQL節(jié)點的主從自動切換。
MySQL側的HA MySQL節(jié)點開啟主從復制的配置方案，并將主節(jié)點配置為MyCAT的dataHost里的writeNode，從節(jié)點配置為readNode，同時MyCAT內部定期對一個dataHost里的所有writeHost與readHost節(jié)點發(fā)起心跳檢測。 正常情況下，MyCAT將第一個writeHost作為寫節(jié)點，所有的DML SQL會發(fā)送此節(jié)點。 若MyCAT開啟了讀寫分離，則查詢節(jié)點會根據(jù)讀寫分離的策略發(fā)往readHost(+writeHost)執(zhí)行。 如果第一個writeHost宕機，MyCAT會在默認的三次心跳檢測失敗后，自動切換到下一個可用的writeHost執(zhí)行DML SQL語句 當原來配置的MySQL寫節(jié)點宕機恢復后，作為從節(jié)點，跟隨新的主節(jié)點，重新配置主從同步。MyCAT自身的HA 官方建議是采用基于硬件的負載聚亨或者軟件方式的HAproxy等。 如果還擔心HAproxy的穩(wěn)定性和但節(jié)點問題，則可以用keepalived的VIP的浮動功能，加以強化。MyCAT功能和特性支持SQL 92標準 支持Mysql集群，可以作為Proxy使用 支持JDBC連接多數(shù)據(jù)庫 支持NoSQL數(shù)據(jù)庫 支持galera sfor mysql集群，percona-cluster或者mariadb cluster，提供高可用性分片集群 自動故障切換，高可用性 支持讀寫分離，支持MySQL雙主多從，以及一主多從的模式 支持全局表，數(shù)據(jù)自動分片到多個節(jié)點，用于高效表關聯(lián)查詢 支持一致性Hash分片，有效解決分片擴容難題 多平臺支持，部署和試試簡單 支持Catelet開發(fā)，類似數(shù)據(jù)庫存儲過程，用于跨分片復雜SQL的人工智能編碼實現(xiàn) 支持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大數(shù)據(jù)處理（暫未更細） MyCAT-Web:MyCAT監(jiān)控及web（新版開發(fā)中） MyCAT-Balance:MyCAT負載均衡（暫未更細）DRDS/TDDLalibaba. Distributed Relational Database Service. 阿里分布式數(shù)據(jù)庫DRDS的前身是淘寶分布式數(shù)據(jù)庫層TDDL，大概在2012年的時候，阿里開始嘗試將TDDL這套體系輸出到阿里云上，也有了一個新的名字：DRDS. TDDLTabao根據(jù)自己的業(yè)務特點開發(fā)了TDDL(Tabao Distributed Data Layer, 外號：頭都大了)。主要解決了分庫分表對應用的透明化以及異構數(shù)據(jù)庫之間的數(shù)據(jù)復制，它是一個基于集中式配置的jdbc datasourcce實現(xiàn)，具有主備，讀寫分離，動態(tài)數(shù)據(jù)庫配置等功能。 TDDL并非獨立的中間件，只能算作中間層，是以Jar包方式提供給應用調用。屬于JDBC Shard的思想。 TDDL處于業(yè)務層和JDBC層中間。
TDDL其實主要可以劃分為3層架構，分別是Matrix層，Group層和Atom層。Matrix層用于實現(xiàn)分庫分表邏輯，底層多個Group實例。而Group和Atom共同組成了動態(tài)數(shù)據(jù)源，Group層實現(xiàn)了數(shù)據(jù)庫的Master/Slave模式的寫分離邏輯，底層持有多個Atom實例。最后Atom層（持有數(shù)據(jù)源）實現(xiàn)數(shù)據(jù)庫ip, port, password, connectionProperties等信息的動態(tài)推送，以及持有院子的數(shù)據(jù)源分離的JBoss數(shù)據(jù)源。
RDRSDRDS/TDDL是阿里巴巴自主研發(fā)的分布式數(shù)據(jù)庫服務。DRDS脫胎于阿里巴巴開源的Cobar分布式數(shù)據(jù)庫引擎，吸收了Cobar核心的Cobar-Proxy源碼，實現(xiàn)了一套獨立的類似MySQL-Proxy協(xié)議的解析端，能夠對傳入的SQL進行解析和處理，對應用程序屏蔽各種復雜的底層DB拓撲結構，獲得單機數(shù)據(jù)庫一樣的使用體驗，同時借鑒了淘寶TDDL豐富的分布式數(shù)據(jù)庫實踐經驗，實現(xiàn)了對分布式Join支持，SUM/MAX/COUNT/AVG等聚合函數(shù)支持以及排序等函數(shù)支持，通過異構索引、小表廣播等解決分布式數(shù)據(jù)庫使用場景下衍生出的一系列問題，最終形成了完整的分布式數(shù)據(jù)庫方案。 DRDS在整個阿里系統(tǒng)中所處的位置：
對于很多應用而言，單機數(shù)據(jù)庫最終都會碰到單機性能上的天花板，在TPS/QPS/內存容量/磁盤容量等等一系列系統(tǒng)資源上會碰到各類限制。DRDS的主要目標就是幫您解決這方面的各類問題，他主要提供了兩個功能，讀寫分離和數(shù)據(jù)庫切汾喎?'http://www./kf/yidong/wp/' target='_blank' class='keylink'>WPC9zdHJvbmc+OjwvcD4NCrbB0LS31sDro6zE3Lm71MvQ0Mq1z9bSu8you/rG99C0yOujrLbgzKi7+sb3tsHIoaOs1eK21NPatsG24NC0ydm1xNOm08OjrMTcubvS1Lyrtc21xLPJsb694r72z7XNs7XExr++saGjIMr9vt2/4sfQt9bKx9K7uPa94r72z7XNs7TmtKLGv76xtcTX7tbVvKu94r72t72wuKOsyv2+3b/ix9C31rXEusvQxMu8z+vG5Mq1uty88rWlo6y+zcrHt9a2+NbO1q6ho72ryv2+3bfWyaK1vbbgzKi7+sb3o6yyorGj1qTH68fzxNy5u8a9vvm1xLfWt6K1vdXi0Km7+sb3yc+jrL7Nv8nS1NLUvKu1zbXEs8mxvsC0veK+9tK1zvG1xLj3wODQ1MTcxr++saGjtbHIu8fQt9bSssrH09C0+rzbtcSjrNfuw/fP1LXEtPq8277NysejrLfWsrzKvcr9vt2/4rvhttTSu9Cp1K3T0LWlu/rK/b7dtcSzob6wvfjQ0M/e1sajrNLyzqrV4tCpstnX96Os1Nq31rK8yr27t76zz8K1xNHTs9m78tCnwsq3x7Ojtc3Qp6Osvs3L48rHxNy5u8q1z9az9sC0o6zSsrvh0vLOqtDUxNzOyszitvjO3reoyrnTw6GjDQo8cD48aW1nIGFsdD0='' src='http://www./uploadfile/Collfiles/20161010/20161010095420220.png' title='\' /> 其他功能特性 1.分布式MySQL執(zhí)行引擎 主要目標是實現(xiàn)與單機數(shù)據(jù)庫SQL引擎的完全兼容，實現(xiàn)SQL的智能下推，能夠智能分析SQL，解析出那些SQL可以直接下發(fā)，那些SQL需要進行優(yōu)化改造，優(yōu)化成什么樣，以及路由到哪些實例節(jié)點上執(zhí)行，充分發(fā)揮數(shù)據(jù)庫實例的全部能力，減少網絡之間的數(shù)據(jù)傳輸量，最終對不同實例處理后的少量結果進行聚合計算返回給應用調用方。這就是分布式SQL引擎的智能下推功能。
支持市面上幾乎所有的語言（具有MySQL訪問能力的），兼容90%以上MySQL語法。
2.在線平滑擴容 在線數(shù)據(jù)擴容的重點在于“在線”兩字，也就是用戶不需要停止業(yè)務進行割接操作，直接就可以添加新的RDS節(jié)點到集群中，實現(xiàn)無縫的自由擴展。RDRS則將整個擴容過程分為幾個階段，包括全量遷移，增量同步，切換數(shù)據(jù)庫等幾個步驟。數(shù)據(jù)會提前進行搬遷，并進行增量并行同步一段時間，因此，我們可以在非常短的時間內（秒級別）完成數(shù)據(jù)庫的最終擴容切換工作，對業(yè)務沒有影響。 3.小表廣播 在一些大的業(yè)務表進行了切分后，總會存在一些表的數(shù)據(jù)量不大，更新量也不大的原始信息表。這些表往往會與我們的切分后大表進行join操作，這種操作物理上就會造成分布式join查詢，效率從整體上會比較地下。針對這種分布式join的場景，開發(fā)了OETL專用工具來進行小表廣播，將原信息表的所有數(shù)據(jù)（包括增量更新）全部自動的廣播到大表的機器上，這樣，就可以讓原來的分布式查詢變成單機本地查詢了。 4.全局唯一ID DRDS sequence功能的目標只是為了保證數(shù)據(jù)的全局唯一，雖然基本上是按時間序列獲取的，但并不全局有序。 5.異構索引 解決分布式場景下數(shù)據(jù)拆分維度和數(shù)據(jù)查詢使用維度不一致導致的低效問題。 當數(shù)據(jù)表被拆分為多個分庫分表時，數(shù)據(jù)在分庫分表的分布規(guī)則就固定了。但是通常數(shù)據(jù)的業(yè)務使用場景非常復雜，如果數(shù)據(jù)的查詢維度和數(shù)據(jù)拆分分布的規(guī)則一直，單條SQL會在一個分庫分表上執(zhí)行；如果數(shù)據(jù)的查詢使用維度和數(shù)據(jù)拆分分布的規(guī)格不一致，單條SQL可能在多個分庫分表上執(zhí)行，出現(xiàn)跨庫查詢，跨庫查詢會增加IO成本，查詢效率必然下降。 解決這個問題的思路還是分布式數(shù)據(jù)庫的一貫原則，讓SQL執(zhí)行在單庫上完成，實際采用的方式就是用“空間換效率”的方案，也就是將同一份數(shù)據(jù)表，冗余存儲多份，按照不同的業(yè)務使用場景進行拆分，保持拆分維度和使用維度統(tǒng)一，而多份數(shù)據(jù)之間會實時數(shù)據(jù)復制以解決數(shù)據(jù)一致性問題，這就是“異構索引”方案。當然異構索引表不能無限制濫用，過多的異構索引表會影響同步效率，對源數(shù)據(jù)表造成同步壓力。 其他同款中間件Altas, Vitess, Heisenberg, CDS, DDB， OneProxy等等。 Atlas Qihoo 360. Heisenberg Baidu. CDS JD. Completed Database Sharding. DDB 豬場. Distributed DataBase. 數(shù)據(jù)增量訂閱與消費基于數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱&消費，目前主要支持了mysql.
CanalCanal架構圖：
說明： server代表一個canal運行實例，對應于一個jvm instance對應于一個數(shù)據(jù)隊列 （1個server對應1..n個instance)instance模塊： eventParser (數(shù)據(jù)源接入，模擬slave協(xié)議和master進行交互，協(xié)議解析) eventSink (Parser和Store鏈接器，進行數(shù)據(jù)過濾，加工，分發(fā)的工作) eventStore (數(shù)據(jù)存儲) metaManager (增量訂閱&消費信息管理器)
數(shù)據(jù)庫同步Otter背景：alibaba B2B因為業(yè)務的特性，賣家主要集中在國內，買家主要集中在國外，所以衍生出了杭州和美國異地機房的需求，同時為了提升用戶體驗，整個機房的架構為雙A，兩邊均可寫，由此誕生了otter這樣一個產品。 otter第一版本可追溯到04~05年，此次外部開源的版本為第4版，開發(fā)時間從2011年7月份一直持續(xù)到現(xiàn)在，目前阿里巴巴B2B內部的本地/異地機房的同步需求基本全上了otter4。 基于數(shù)據(jù)庫增量日志解析，準實時同步到本地機房或異地機房的mysql/oracle數(shù)據(jù)庫，一個分布式數(shù)據(jù)庫同步系統(tǒng)。 工作原理
原理描述： 基于Canal開源產品，獲取數(shù)據(jù)庫增量日志數(shù)據(jù)。 典型管理系統(tǒng)架構，manager(Web管理)+node(工作節(jié)點)manager運行時推送同步配置到node節(jié)點 node節(jié)點將同步狀態(tài)反饋到manager上 基于zookeeper，解決分布式狀態(tài)調度的，允許多node節(jié)點之間協(xié)同工作。 Otter的作用異構庫mysql->mysql、oracle. (目前開原版只支持mysql增量，目標庫可以是mysql或者oracle,取決于canal的功能) 單機房同步（數(shù)據(jù)庫之間RTT(Round-Trip Time)<> 數(shù)據(jù)庫版本升級 數(shù)據(jù)表遷移 異步二級索引 跨機房同步（比如阿里巴巴國際站就是杭州和美國機房的數(shù)據(jù)庫同步，RTT>200ms） 機房容災 雙向同步 避免回環(huán)算法（通用的解決方案，支持大部分關系型數(shù)據(jù)庫） 數(shù)據(jù)一致性算法（保證雙A機房模式下，數(shù)據(jù)保證最終一直性） 文件同步 站點鏡像（進行數(shù)據(jù)復制的同時，復制關聯(lián)的圖片，比如復制產品數(shù)據(jù)，同事復制產品圖片） 單機房復制示意圖
說明： SETL S: Select E: Extract T: Transform L: Load 類似于數(shù)據(jù)倉庫的ETL模型，具體可為數(shù)據(jù)join，數(shù)據(jù)轉化，數(shù)據(jù)加載。 跨機房復制示意圖
數(shù)據(jù)涉及網絡傳輸，S/E/T/L幾個階段會分散在2個或者更多Node節(jié)點上，多個Node之間通過zookeeper進行協(xié)同工作（一般是Select和Extract在一個機房的Node, Transform/Load落在另一個機房的Node） More:Otter調度模型：batch處理+雙節(jié)點部署。 Otter數(shù)據(jù)入庫算法 Otter雙向回環(huán)控制 Otter數(shù)據(jù)一致性 Otter高可用性 Otter擴展性異地雙活數(shù)據(jù)架構基礎設施DRC所謂DRC，就是Data Replication Center的縮寫，數(shù)據(jù)復制中心。這種復制是同步的，支持異構的，高可用的（有嚴格容災系統(tǒng)，實時性好），支持訂閱分發(fā)的。項目期初是為了淘寶異地容災而成立的，用于數(shù)據(jù)庫之間主備同步，后來采用這套技術方案衍生出了DRC-TAIR, DRC-DUMP等項目。 所謂異地雙活主要關注兩件事，一個數(shù)據(jù)同步，一個數(shù)據(jù)分發(fā)。 到底怎樣的應用會需要異地的雙活？比較常見的場景有三個： 兩個地域或多個地域都有大量用戶的場景，比如在中國的用戶希望他們用杭州的RDS服務，在美國的用戶用美國的RDS服務，這就需要數(shù)據(jù)在異地同步。很多游戲，金融，傳媒，電商業(yè)務都有這種需求。滿足這個需求的難點在于跨地域的網絡，比如網絡延時長，丟包多，而且數(shù)據(jù)在公網傳輸會有數(shù)據(jù)泄露風險。 數(shù)據(jù)來源較多，需要介入各種異構數(shù)據(jù)的場景。比如一個應用需要從ODPS, RDS, OTS， OceanBase, PostgreSQL這幾個服務介入數(shù)據(jù)，他們的數(shù)據(jù)結構和接口都不同，這種接入的成本會比較高。因此另一個可用的方法是數(shù)據(jù)寫入的時候就一份多謝為不同數(shù)據(jù)結構 下游訂閱很多的情況，比如一份數(shù)據(jù)，備份系統(tǒng)、通知系統(tǒng)、大數(shù)據(jù)分析系統(tǒng)、索引系統(tǒng)等等都要來取，如果用上面一份數(shù)據(jù)多寫的方案是可以應對的，但這里還有其他難點，就是數(shù)據(jù)一致性、可擴展性、跨網同步穩(wěn)定性、以及同步的實時性。DRC支持讀取集團MySQL, RDS, OceanBase, HBase, Oracle等多種不同的數(shù)據(jù)源的實時增量數(shù)據(jù)，支持寫入數(shù)據(jù)庫、MetaQ, ODPS等多種存儲媒介.
以前在一個城市做雙機房主備，兩個機房是數(shù)據(jù)對等的，寫入是隨機分布，然后通過主備HA進行數(shù)據(jù)同步。這樣機房對等的思路會導致業(yè)務增長、數(shù)據(jù)增長只能通過兩個機房不停堆機器來解決。另一方面，如果整個城市斷電，那么雙活就成了雙死。下一個思路是做跨城市，早期常用的做法是一個城市寫，另一個城市冷備，就是晚上做同步，但這就意味著白天如果發(fā)生了什么事兒，這一天的數(shù)據(jù)就比較危險。另一個思路是兩個城市多寫，數(shù)據(jù)落兩邊，這樣的問題是應用調用次數(shù)頻繁的話，如果調用異地數(shù)據(jù)多來那么一兩次，整個應用的延時就很長。這個思路再進一步發(fā)展，就是做單元內封閉以減少異地調用，這就涉及到業(yè)務上的改造。 順著這個思路，阿里的異地雙活重點做了幾件事。一個是熱插拔，可以做到在業(yè)務高峰時增加節(jié)點，高峰過了把增加的節(jié)點關閉。做到這個的一個關鍵是流量實時切換 ，DRC可以在20秒以內把一個單元（region）的流量遷移到另一個單元。另一個是數(shù)據(jù)實時恢復，就是通過一定的冗余設計，一旦一個單元掛掉了，可以在另一個單元做全量恢復。
異地多活在數(shù)據(jù)方面的挑戰(zhàn)是非常大的。雙十一期間，交易會激增，所以交易鏈路做了單元化。交易鏈路的數(shù)據(jù)分為三個維度：買家、賣家、商品。買家之間通常沒有太多交叉，天然的適應這種隔離，而且賣家對延遲的敏感度非常高，所以按照賣家維度切分，在單元內封閉，而賣家和商品都是在中心寫入。 數(shù)據(jù)方面的兩個核心要求： 一致性，要求賣家和商品一致，單元和中心一致，也就是數(shù)據(jù)同步不能丟數(shù)據(jù)，不能錯數(shù)據(jù)，還要保證事務。 實時性，需要做到秒級別的延遲。雙單元的同步架構有兩種：
第二種同步架構是單元封閉的方式。中心和單元各有寫入，我們通過冗余是的中心和單元隨時可以各自接管。（類似Otter）
這里的關鍵是： 避免循環(huán)復制：通過在DB透傳打標事務的方式實現(xiàn)。 限流：峰值的壓力，我們單元化本來就選取了流量激增業(yè)務，兩邊都實時同步100%全量數(shù)據(jù)，峰值對每個系統(tǒng)的壓力有增無減。DRC的store和congo都可以根據(jù)TPS或者流量限流。限速算法的核心思想分為批量采樣，獎懲時間，平滑變速。
異地多活中DRC的核心能力就是在低延遲，一致性和高可用。
JD多中心交易系統(tǒng)JD. 多中心交易系統(tǒng)。
多中心交易本質上是一個更大的分布式系統(tǒng)，交易流程中依賴和產生的數(shù)據(jù)和服務有不同的特點，必然涉及到數(shù)據(jù)分區(qū)、路由、復制、讀寫一致性、延遲等分布式領域的常見問題。 其中，數(shù)據(jù)一致性是電商網站需要面臨的首要問題，越是流量增大的時候越要保證數(shù)據(jù)更新的即時性和準確性。在多中心之間需要同步賣家數(shù)據(jù)和商品數(shù)據(jù)，如果同步的延時太長，買家、賣家都不可接受。比如，賣家改了價格或庫存，用戶不能過很久才看到。同樣，數(shù)據(jù)正確性也是很大的挑戰(zhàn)，賣掉的商品能夠及時減少，退貨的商品能夠及時增加。這都時刻考驗著后端系統(tǒng)和數(shù)據(jù)庫平臺的健壯性。 除了數(shù)據(jù)一致性之外，如何保證路由規(guī)則的一致性也是關鍵性的問題。從技術角度來說，要保障單一用戶從登錄到訪問服務、到訪問數(shù)據(jù)庫，全鏈路的路由規(guī)則都是完全一致的。如果路由錯誤，看到的數(shù)據(jù)不正確，也會影響到最終用戶的體驗。 架構
系統(tǒng)包括一個主中心和多個分中心，主中心與分中心之間通過數(shù)據(jù)總線交換數(shù)據(jù)。數(shù)據(jù)流向中，主數(shù)據(jù)(商品數(shù)據(jù)、商家數(shù)據(jù)、用戶數(shù)據(jù)等)的流向從主中心通過數(shù)據(jù)總線實時同步到分中心，分中心只讀；而交易數(shù)據(jù)(訂單數(shù)據(jù))的流向從分中心實時同步到主中心；在故障時，會從分中心轉移到主中心。 在這個系統(tǒng)中，有多處體現(xiàn)分流的概念。首先，買家訪問京東網站下單時，會被優(yōu)先分流到附近的交易中心；其次，根據(jù)交易系統(tǒng)的特點，接單前（包括購物車、結算頁等），多中心交易按用戶維度分流，如下圖所示。用戶登錄時，查詢用戶與區(qū)域的映射關系表（類似你是哪個片區(qū)的），標識此用戶屬于哪個分中心，并保存標識到cookie中，然后將用戶路由到指定的分中心。用戶訪問其他系統(tǒng)，如購物車和結算頁時，從cookie中讀取標識，重定向到相應分中心頁面。 通過分流，將用戶分配到相應的分中心，一方面響應速度快，用戶體驗更好，不用跨地域訪問數(shù)據(jù)中心了；另一方面，每個中心服務一定數(shù)量的用戶，水平擴展性好，也能支撐更大的交易規(guī)模了。當然，多數(shù)據(jù)中心不能盲目干活，還考慮到容災備份的問題。（支付寶光纖事件） 交易系統(tǒng)包括應用和數(shù)據(jù)部分，應用部分是無狀態(tài)的，就是說，這些工作是無差別的，一臺服務器出問題，我換一臺服務器來處理就是了，較容易實現(xiàn)多機房多活。但是數(shù)據(jù)不一樣，多中心交易本質上是一個更大的分布式系統(tǒng)，必然涉及到數(shù)據(jù)分區(qū)、路由、復制、讀寫一致性、延遲等分布式領域的常見問題。 另外，交易流程中依賴和產生的數(shù)據(jù)和服務有不同的特點。比如商品、促銷和價格、庫存的讀服務，我們可以將之稱為基礎主數(shù)據(jù)，它們在用戶下單流程中是無法分區(qū)的，否則無法實現(xiàn)單機房內流量閉環(huán)，也就是說，不能因為分區(qū)數(shù)據(jù)的不一致，導致同一用戶在單一流程中看到不同的數(shù)據(jù)（假如你加入購物車時是促銷20塊，結賬是25塊，你會不會表情扭曲？）而商品、促銷和價格的寫服務,是給采銷、第三方POP商家應用調用的，這種業(yè)務場景的可用性目標，主機房部署和冷備模式即可滿足，而且業(yè)務人員的操作流程會抵消寫復制延遲。 簡單來說，數(shù)據(jù)的問題表現(xiàn)在以下幾個方面：一、 如何保證數(shù)據(jù)的即時性和準確性，多中心之間需要同步賣家數(shù)據(jù)和商品數(shù)據(jù)，如果同步的延時太長,買家、賣家都不可接受，由于是異地部署，最好延時能控制在1秒內。比如，賣家改了價格或庫存，用戶不能過很久才看到。同樣，數(shù)據(jù)正確性也是很大的挑戰(zhàn),因為數(shù)據(jù)故障跟應用層故障不一樣，應用出故障了，可能只影響用戶訪問；數(shù)據(jù)寫錯了無法恢復。2、如何保證路由規(guī)則的一致性，要保障這個用戶從進來到訪問服務，到訪問數(shù)據(jù)庫，全鏈路的路由規(guī)則都是完全一致的；如果路由錯誤，看到的數(shù)據(jù)不正確。 從同城雙機房的分布轉變?yōu)楫惖囟鄼C房的分布，給數(shù)據(jù)同步帶來了新的挑戰(zhàn)，因此如何設計數(shù)據(jù)總線也是項目能否實現(xiàn)的關鍵因素。京東的多中心交易系統(tǒng)通過數(shù)據(jù)總線JingoBus進行快速數(shù)據(jù)交換，同步性能是mysql的3倍以上，而且可用性高，架構靈活。其中，全新的總線設計解決了多中心交易跨機房的數(shù)據(jù)庫復制和多數(shù)據(jù)源間的數(shù)據(jù)異構同步等難題，實現(xiàn)了高性能、低延時、健壯的數(shù)據(jù)同步機制。
如圖所示，數(shù)據(jù)總線主要分Relay、Snapshot和Replicator三部分構成，其中Relay從來源數(shù)據(jù)庫抽取事務日志，并對Replicator提供日志訂閱服務，角色上相當于Mysql Slave IO Thread。Snapshot從Relay訂閱所有事務日志，寫入持久存儲作為快照，同時向Replicator提供批量日志訂閱服務，角色上相當于Mysql Slave Relay Log。Replicator：事務日志的消費端，從Relay或Snapshot拉取事務日志將事務日志按配置的一致性應用到目標數(shù)據(jù)庫，角色上相當于Mysql Slave SQL Thread。(參考下面MySQL主備復制原理圖)
正常情況下，Replicator直接連接Relay，消費Relay內存隊列中的事務日志。但有些情況下，因為網絡抖動、目標庫的負載過高等因素，可能導致Replicator相對Relay落后很多。另外，當新的消費端加入同一數(shù)據(jù)源的訂閱者時，新消費端有冷啟動的問題。為了避免重新從數(shù)據(jù)源做全量快照，Snapshot作為Relay的一個特殊消費端，通過一種高吞吐的消費方式，從Relay源源不斷的消費在線事務日志，通過對事務日志的有效處理，最終保存了數(shù)據(jù)源的一份一致快照(Consistent Snapshot)，即包括了數(shù)據(jù)源庫表中每一行的最新狀態(tài)的快照，同時保留了一段比Relay buffer更舊的事務日志(Log Store)。由此看來，數(shù)據(jù)總線作為一個數(shù)據(jù)層的通用CDC組件，對于多中心交易項目以及異步復制場景提供了整體解決方案，奠定了項目的核心內容。 跨數(shù)據(jù)庫（數(shù)據(jù)源）遷移yugong去Oracle數(shù)據(jù)遷移同步工具。定位：數(shù)據(jù)庫遷移（目前主要支持Oracle->mysql/DRDS）
概述整個數(shù)據(jù)遷移過程，分為兩個部分： 全量遷移 增量遷移
過程描述： 增量數(shù)據(jù)收集（創(chuàng)建Oracle表的增量物化視圖） 進行全量復制 進行增量復制（可并行進行數(shù)據(jù)校驗） 原庫停寫，切換到新庫Oracle全量基于JDBC拉取數(shù)據(jù)，增量基于物化視圖來實現(xiàn)。 架構
說明： 一個JVM Container 對應多個instance，每個instance對應于一張表的遷移任務 instance分為三部分extractor (從數(shù)據(jù)源庫上提取數(shù)據(jù)，可分為全量/增量實現(xiàn)) translator （將源庫上的數(shù)據(jù)按照目標庫的需求進行自定義轉化） applier（將數(shù)據(jù)更新到目標庫，可分為全量/增量/對比的實現(xiàn)） 自定義數(shù)據(jù)轉換如果要遷移的Oracle和mysql的表結構不同，比如表名，字段名有差異，字段類型不兼容，需要使用自定義數(shù)據(jù)轉換。如果完全相同則可以跳過。 整個數(shù)據(jù)流為：DB->Extractor->DataTranslator->Applier->DB, 本程序預留DataTranslator接口（僅支持Java），允許外部用戶自定義數(shù)據(jù)處理邏輯。比如： 表名不同 字段名不同 字段類型不同 字段個數(shù)不同 運行過程join其他表的數(shù)據(jù)做計算等運行模式介紹1.MARK模式（MARK） 開啟增量日志模式，如果是Oracle就是創(chuàng)建物化視圖（materialized view）。 2.CLEAR模式（CLEAR） 清理增量日志的幾率，如果是Oracle就是刪除物化視圖 3.全量模式（FULL) 全量模式，顧名思議即為對源表進行一次全量操作，遍歷源表所有的數(shù)據(jù)后，插入目標表. 全量有兩種處理方式： 分頁處理：如果源表存在主鍵，只有一個主鍵字段，并且主鍵字段類型為Number類型，默認會選擇該分頁處理模式. 優(yōu)點：支持斷點續(xù)做，對源庫壓力相對較小。 缺點：遷移速度慢 once處理：通過select * from訪問整個源表的某一個mvcc版本的數(shù)據(jù)，通過cursor.next遍歷整個結果集. 優(yōu)點：遷移速度快，為分頁處理的5倍左右。 缺點：源庫壓力大，如果源庫并發(fā)修改量大，會導致數(shù)據(jù)庫MVCC版本過多，出現(xiàn)棧錯誤. 還有就是不支持斷點續(xù)做.4.增量模式（INC） 全量模式，顧名思議即為對源表增量變化的數(shù)據(jù)插入目標表，增量模式依賴記錄日志功能. 目前增量模式的記錄日志功能，是通過oracle的物化視圖功能。 5.自動模式(ALL) 自動模式，是對全量+增量模式的一種組合，自動化運行，減少操作成本. 自動模式的內部實現(xiàn)步驟： 開啟記錄日志功能. (創(chuàng)建物化視圖) 運行全量同步模式. (全量完成后，自動進入下一步) 運行增量同步模式. (增量模式，沒有完成的概念，所以也就不會自動退出，需要業(yè)務判斷是否可以退出，可以看一下切換流程)6.對比模式(CHECK) 對比模式，即為對源庫和目標庫的數(shù)據(jù)進行一次全量對比，驗證一下遷移結果. 對比模式為一種可選運行，做完全量/增量/自動模式后，可選擇性的運行對比模式，來確保本次遷移的正確性. DataXDataX是一個在異構的數(shù)據(jù)庫/文件系統(tǒng)之間高速交換數(shù)據(jù)的工具，實現(xiàn)了在任意的數(shù)據(jù)處理系統(tǒng)(RDBMS/Hdfs/Local filesystem）之間的數(shù)據(jù)交換。 目前成熟的數(shù)據(jù)導入導出工具比較多，但是一般都只能用于數(shù)據(jù)導入或者導出，并且只能支持一個或者幾個特定類型的數(shù)據(jù)庫。 這樣帶來的一個問題是，如果我們擁有很多不同類型的數(shù)據(jù)庫/文件系統(tǒng)(Mysql/Oracle/Rac/Hive/Other…)，并且經常需要在它們之間導入導出數(shù)據(jù)，那么我們可能需要開發(fā)/維護/學習使用一批這樣的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以后每增加一種庫類型，我們需要的工具數(shù)目將線性增長。(當我們需要將mysql的數(shù)據(jù)導入oracle的時候，有沒有過想從jdbcdump和dbloader上各掰下來一半拼在一起到沖動？)這些工具有些使用文件中轉數(shù)據(jù)，有些使用管道，不同程度的為數(shù)據(jù)中轉帶來額外開銷，效率差別很非常大。很多工具也無法滿足ETL任務中常見的需求，比如日期格式轉化，特性字符的轉化，編碼轉換。另外，有些時候，我們希望在一個很短的時間窗口內，將一份數(shù)據(jù)從一個數(shù)據(jù)庫同時導出到多個不同類型的數(shù)據(jù)庫。DataX正是為了解決這些問題而生。
設計理念為了解決異構數(shù)據(jù)源同步問題，DataX將復雜的網狀的同步鏈路變成了星型數(shù)據(jù)鏈路，DataX作為中間傳輸載體負責連接各種數(shù)據(jù)源。當需要接入一個新的數(shù)據(jù)源的時候，只需要將此數(shù)據(jù)源對接到DataX，便能跟已有的數(shù)據(jù)源做到無縫數(shù)據(jù)同步。
框架設計
DataX本身作為離線數(shù)據(jù)同步框架，采用Framework+plugin架構構建。將數(shù)據(jù)源讀取和寫入抽象稱為Reader/Writer插件，納入到整個同步框架中。 Reader： Reader為數(shù)據(jù)采集模塊，負責采集數(shù)據(jù)源的數(shù)據(jù)，將數(shù)據(jù)發(fā)送給Framework. Writer：Writer為數(shù)據(jù)寫入模塊，負責不斷向Framework取數(shù)據(jù)，并將數(shù)據(jù)寫入到目的端 Framework：Framework用于連接reader和writer,作為兩者的數(shù)據(jù)傳輸通道，并處理緩存，流控，并發(fā)，數(shù)據(jù)轉換等核心技術問題。DataX框架內部通過雙緩沖隊列、線程池封裝等技術，集中處理了高速數(shù)據(jù)交換遇到的問題，提供簡單的接口與插件交互，插件分為Reader和Writer兩類，基于框架提供的插件接口，可以十分便捷的開發(fā)出需要的插件。比如想要從oracle導出數(shù)據(jù)到mysql，那么需要做的就是開發(fā)出OracleReader和MysqlWriter插件，裝配到框架上即可。并且這樣的插件一般情況下在其他數(shù)據(jù)交換場合是可以通用的。 核心架構DataX3.0 開源版本支持單機多線程模式完成同步作業(yè)運行，這里按一個DataX作業(yè)生命周期的時序圖，從整體架構設計非常簡要說明DataX各個模塊相互關系。
核心模塊介紹： DataX完成單個數(shù)據(jù)同步的作業(yè)，我們稱之為Job，DataX接受到一個Job之后，將啟動一個進程來完成整個作業(yè)同步過程。DataX Job模塊是單個作業(yè)的中樞管理節(jié)點，承擔了數(shù)據(jù)清理、子任務切分(將單一作業(yè)計算轉化為多個子Task)、TaskGroup管理等功能。 DataXJob啟動后，會根據(jù)不同的源端切分策略，將Job切分成多個小的Task(子任務)，以便于并發(fā)執(zhí)行。Task便是DataX作業(yè)的最小單元，每一個Task都會負責一部分數(shù)據(jù)的同步工作。 切分多個Task之后，DataX Job會調用Scheduler模塊，根據(jù)配置的并發(fā)數(shù)據(jù)量，將拆分成的Task重新組合，組裝成TaskGroup(任務組)。每一個TaskGroup負責以一定的并發(fā)運行完畢分配好的所有Task，默認單個任務組的并發(fā)數(shù)量為5。 每一個Task都由TaskGroup負責啟動，Task啟動后，會固定啟動Reader—>Channel—>Writer的線程來完成任務同步工作。 DataX作業(yè)運行起來之后， Job監(jiān)控并等待多個TaskGroup模塊任務完成，等待所有TaskGroup任務完成后Job成功退出。否則，異常退出，進程退出值非0。DataX調度流程： 舉例來說，用戶提交了一個DataX作業(yè)，并且配置了20個并發(fā)，目的是將一個100張分表的mysql數(shù)據(jù)同步到odps里面。 DataX的調度決策思路是： |
|
|
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_1.png "\")
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_2.png "\")
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_3.png "\")
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_4.png "\")
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_5.png "\")
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_6.png "\")
![](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_7.png "\")
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_8.png "\")
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_9.png "\")
![\](http://image101.360doc.com/DownloadImg/2016/11/0400/83706054_10.png "\")
![\](http://pubimage.360doc.com/wz/default.gif "\")
