這里主要介紹互聯(lián)網(wǎng)行業(yè)內(nèi)有關(guān)數(shù)據(jù)庫的相關(guān)中間件。數(shù)據(jù)庫相關(guān)平臺主要解決以下三個方面的問題：

創(chuàng)新互聯(lián)專注于樂昌企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站設(shè)計,商城系統(tǒng)網(wǎng)站開發(fā)。樂昌網(wǎng)站建設(shè)公司,為樂昌等地區(qū)提供建站服務(wù)。全流程定制制作，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

• 為海量前臺數(shù)據(jù)提供高性能、大容量、高可用性的訪問

• 為數(shù)據(jù)變更的消費提供準(zhǔn)實時的保障

• 高效的異地數(shù)據(jù)同步

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

數(shù)據(jù)庫中間件有以下幾種：

• 分布式數(shù)據(jù)庫分表分庫

• 數(shù)據(jù)增量訂閱與消費

• 數(shù)據(jù)庫同步（全量、增量、跨機房、復(fù)制）

• 跨數(shù)據(jù)庫（數(shù)據(jù)源）遷移

整個產(chǎn)品族圖如下：

• 最上層的是分布式數(shù)據(jù)庫分表分庫中間件，負(fù)責(zé)和上層應(yīng)用打交道，對應(yīng)用可表現(xiàn)為一個獨立的數(shù)據(jù)庫，而屏蔽底層復(fù)雜的系統(tǒng)細(xì)節(jié)。分布式數(shù)據(jù)庫中間件除了基本的分表分庫功能，還可以豐富一下，比如講讀寫分離或者水平擴容功能集成在一起，或者比如讀寫分離本身也可以作為一個獨立的中間件。（Cobar, MyCAT, TDDL, DRDS, DDB）

• 增量數(shù)據(jù)訂閱和消費，用戶對數(shù)據(jù)庫操作，比如DML, DCL, DDL等，這些操作會產(chǎn)生增量數(shù)據(jù)，下層應(yīng)用可以通過監(jiān)測這些增量數(shù)據(jù)進(jìn)行相應(yīng)的處理。典型代表Canal，根據(jù)MySQL的binlog實現(xiàn)。也有針對Oracle(redolog)的增量數(shù)據(jù)訂閱與消費的中間件。（Canal, Erosa）

• 數(shù)據(jù)庫同步中間件涉及數(shù)據(jù)庫之間的同步操作，可以實現(xiàn)跨（同）機房同步以及異地容災(zāi)備份、分流等功能。可以涉及多種數(shù)據(jù)庫，處理之后的數(shù)據(jù)也可以以多種形式存儲。（Otter, JingoBus, DRC）

• 數(shù)據(jù)庫與數(shù)據(jù)庫之間會有數(shù)據(jù)遷移（同步）的動作，同款數(shù)據(jù)同步原理比較簡單，比如MySQL主備同步，只要在數(shù)據(jù)庫層進(jìn)行相應(yīng)的配置既可，但是跨數(shù)據(jù)庫同步就比較復(fù)雜了，比如Oracle->MySQL. 數(shù)據(jù)遷移一般包括三個步驟：全量復(fù)制，將原數(shù)據(jù)庫的數(shù)據(jù)全量遷移到新數(shù)據(jù)庫，在這遷移的過程中也會有新的數(shù)據(jù)產(chǎn)生；增量同步，對新產(chǎn)生的數(shù)據(jù)進(jìn)行同步，并持續(xù)一段時間以保證數(shù)據(jù)同步；原庫停寫，切換新庫。將“跨數(shù)據(jù)庫”這個含義擴大一下——“跨數(shù)據(jù)源”，比如HDFS, HBase, FTP等都可以相互同步。（yugong, DataX）

分布式數(shù)據(jù)庫

隨著互聯(lián)網(wǎng)產(chǎn)品在體量和規(guī)模上日益膨脹，無論是Oracle還是MySQL，都會第一時間面臨來自磁盤，CPU和內(nèi)存等單機瓶頸，為此，產(chǎn)品方除了需要不斷購買成本難以控制的高規(guī)格服務(wù)器，還要面臨不斷迭代的在線數(shù)據(jù)遷移。在這種情況下，無論是海量的結(jié)構(gòu)化數(shù)據(jù)還是快速成長的業(yè)務(wù)規(guī)模，都迫切需要一種水平擴展的方法將存儲成本分?jǐn)偟匠杀究煽氐纳逃梅?wù)器上。同時，也希望通過線性擴容降低全量數(shù)據(jù)遷移對線上服務(wù)帶來的影響，分庫分表方案便應(yīng)運而生。

分表分庫類的中間件主要有兩種形式向應(yīng)用提供服務(wù)：

• 一種是以JDBC的jar包形式為Java應(yīng)用提供直接依賴，Java應(yīng)用通過提供的JDBC包實現(xiàn)透明訪問分布式數(shù)據(jù)庫集群中的各個分庫分表，典型代表網(wǎng)易的DDB和阿里的TDDL.

• 另一種是為應(yīng)用部署獨立的服務(wù)來滿足應(yīng)用分庫分表的需求，在這種方式下通過標(biāo)準(zhǔn)JDBC訪問Proxy，而Proxy則根據(jù)MySQL標(biāo)準(zhǔn)通信協(xié)議對客戶端請求解析，還原應(yīng)用SQL請求，然后通過本地訪問數(shù)據(jù)庫集群，最后再將得到的結(jié)果根據(jù)MySQL標(biāo)準(zhǔn)通信協(xié)議編碼返回給客戶端。典型代表阿里的Cobar, Cobar變種MyCAT, 阿里的DRDS，網(wǎng)易的DDB proxy模式以及DDB的私有云模式。

Cobar

Cobar 是提供關(guān)系型數(shù)據(jù)庫（MySQL）分布式服務(wù)的中間件，它可以讓傳統(tǒng)的數(shù)據(jù)庫得到良好的線性擴展，并看上去還是一個數(shù)據(jù)庫，對應(yīng)用保持透明。

Cobar以Proxy的形式位于前臺應(yīng)用和實際數(shù)據(jù)庫之間，對前臺的開放的接口是MySQL通信協(xié)議。將前臺SQL語句變更并按照數(shù)據(jù)分布規(guī)則發(fā)到合適的后臺數(shù)據(jù)分庫，再合并返回結(jié)果，模擬單庫下的數(shù)據(jù)庫行為。

Cobar屬于阿里B2B事業(yè)群，始于2008年，在阿里服役3年多，接管3000+個MySQL數(shù)據(jù)庫的schema,集群日處理在線SQL請求50億次以上。由于Cobar發(fā)起人的離職，Cobar停止維護。后續(xù)的類似中間件，比如MyCAT建立于Cobar之上，包括現(xiàn)在阿里服役的RDRS其中也復(fù)用了Cobar-Proxy的相關(guān)代碼。

Cobar結(jié)構(gòu)

• 與應(yīng)用之間通過MySQL protocol進(jìn)行交互，是一個proxy的結(jié)構(gòu)，對外暴露jdbc:mysql://CobarIP:port/schema。對應(yīng)用透明。

• 無需引入新的jar包，從訪問遷移到數(shù)據(jù)庫訪問Cobar可以復(fù)用原有的基于JDBC的DAO。

• Cobar前后端都實現(xiàn)了MySQL協(xié)議，當(dāng)接受到SQL請求時，會一次進(jìn)行解釋（SQL Parser）和路由（SQL Router）工作，然后使用SQL Executor去后端模塊獲取數(shù)據(jù)集（后端模塊還負(fù)責(zé)心跳檢查功能）；如果數(shù)據(jù)集來自多個數(shù)據(jù)源，Cobar則需要把數(shù)據(jù)集進(jìn)行組合（Result Merge），最后返回響應(yīng)。

• 數(shù)據(jù)庫連接復(fù)用。Cobar使用連接詞與后臺真是數(shù)據(jù)庫進(jìn)行交互。（實際應(yīng)用中，根據(jù)應(yīng)用的不同，使用proxy結(jié)構(gòu)后數(shù)據(jù)庫連接數(shù)能夠節(jié)約2-10倍不等。）

• Cobar事務(wù)，Cobar在單庫的情況下保持事務(wù)的強一致性，分庫的情況下保持事務(wù)的弱一致性，分庫事務(wù)采用2PC協(xié)議，包括執(zhí)行階段和提交階段。

Cobar的前端是NIO的，而后端跟MySQL交互是阻塞模式，其NIO代碼只給出了框架，還沒有來得及實現(xiàn)。 據(jù)稱未開源版的Cobar實現(xiàn)了后端的NIO。 

Cobar會出現(xiàn)假死，假死以后Cobar會頻繁進(jìn)行主從切換（如果配置了的話），自動切換本身也存在隱患。

可以計算：Cobar的TPS=5,000,000,000/(3000*24*60*60)=20。

與Cobar相關(guān)的還有一共Cobar-Client.

Cobar通過SQL語句轉(zhuǎn)發(fā)的方式實現(xiàn)數(shù)據(jù)訪問。用戶發(fā)來的SQL語句，Cobar解析其內(nèi)容，判斷該語句所涉及的數(shù)據(jù)分布在哪個分庫上，再將語句轉(zhuǎn)發(fā)給此分庫執(zhí)行。當(dāng)SQL語句中涉及的拆分字段有多值，如 IN, 或where條件中沒有出現(xiàn)拆分字段時，該語句將會轉(zhuǎn)發(fā)至后臺所有分庫執(zhí)行，再將執(zhí)行結(jié)果以MySQL協(xié)議包的形式送回應(yīng)用端。

通信模塊，負(fù)責(zé)從連續(xù)的網(wǎng)絡(luò)數(shù)據(jù)流中識別出一個個MySQL協(xié)議包，再解析協(xié)議包識別出SQL語句輸出給Parser模塊，同時，把Result Merge模塊輸入的執(zhí)行結(jié)果，編碼成MySQL的協(xié)議包。它以NIO方式實現(xiàn)，有很高的執(zhí)行效率。之后進(jìn)行優(yōu)化，引入了一個ByteBuffer池，將NIO的Buffer統(tǒng)一管理起來，減少了NIO數(shù)據(jù)交互時的垃圾回收。

Cobar前端使用的是優(yōu)化后的NIO通信模塊，為了讓該模塊在后端使用，Cobar去除了JDBC。與后端數(shù)據(jù)庫交互，Cobar直接面向協(xié)議，目前實現(xiàn)了基于MySQL協(xié)議的后端交互。

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

為了節(jié)省數(shù)據(jù)庫的機器數(shù)量，可以采用下圖中的方式部署：

HA

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

1. Cobar的主備切換有兩種觸發(fā)方式，一種是用戶手動觸發(fā)，一種是Cobar的心跳語句檢測到異常后自動觸發(fā)。那么，當(dāng)心跳檢測到主機異常，切換到備機，如果主機恢復(fù)了，需要用戶手動切回主機工作，Cobar不會在主機恢復(fù)時自動切換回主機，除非備機的心跳也返回異常。

2. Cobar只檢查MySQL主備異常，不關(guān)心主備之間的數(shù)據(jù)同步，因此用戶需要在使用Cobar之前在MySQL主備上配置雙向同步，詳情可以參閱MySQL參考手冊。

Cobar解決的問題

分布式：Cobar的分布式主要是通過將表放入不同的庫來實現(xiàn)。

1. Cobar支持將一張表水平拆分成多份分別放入不同的庫來實現(xiàn)表的水平拆分

2. Cobar也支持將不同的表放入不同的庫

3. 多數(shù)情況下，用戶將以上兩種方式混合使用

這里需要強調(diào)的是，Cobar不支持將一張表，例如test表拆分成test_1, test_2, test_3….放在同一個庫中，必須拆分后的表分別放入不同的庫來實現(xiàn)分布式。

Cobar的約束

1. 不支持跨庫情況下的join、分頁、排序、子查詢操作

2. SET語句執(zhí)行會被忽略，事務(wù)和字符集設(shè)置除外

3. 分庫情況下，insert語句必須包括拆分字段列名

4. 分庫情況下，update語句不能更新拆分字段的值

5. 不支持SAVEPOINT操作

6. 暫時只支持MySQL數(shù)據(jù)節(jié)點

7. 使用JDBC時，不支持rewriteBatchedStatements=true參數(shù)設(shè)置（默認(rèn)為false）

8. 使用JDBC時，不支持useServerPrepStmts=true參數(shù)設(shè)置（默認(rèn)為false)

9. 使用JDBC時，BLOB, BINARY, VARBINARY字段不能使用setBlob()或setBinaryStream()方法設(shè)置參數(shù)

MyCAT

從定義和分類看，它是一個開源的分布式數(shù)據(jù)庫系統(tǒng)，是一個實現(xiàn)了MySQL協(xié)議的Server，前端用戶可以把它看做是一個數(shù)據(jù)庫代理，用MySQL客戶端工具和命令行訪問，而其后端可以用MySQL Native Protocol與多個MySQL服務(wù)器通信，也可以用JDBC協(xié)議與大多數(shù)主流數(shù)據(jù)庫服務(wù)器通信，其核心功能是分表分庫，即將一個大表水平分割為N個小表，存儲在后端MySQL服務(wù)器里或者其他數(shù)據(jù)庫里。

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

MyCAT是一個強大的數(shù)據(jù)庫中間件，不僅僅可以用作讀寫分離，以及分表分庫、容災(zāi)管理，而且可以用于多租戶應(yīng)用開發(fā)、云平臺基礎(chǔ)設(shè)施，讓你的架構(gòu)具備很強的適應(yīng)性和靈活性，借助于即將發(fā)布的MyCAT只能優(yōu)化模塊，系統(tǒng)的數(shù)據(jù)訪問瓶頸和熱點一目了然，根據(jù)這些統(tǒng)計分析數(shù)據(jù)，你可以自動或手工調(diào)整后端存儲，將不同的表隱射到不同存儲引擎上，而整個應(yīng)用的代碼一行也不用改變。

MyCAT是在Cobar基礎(chǔ)上發(fā)展的版本，兩個顯著提高：

• 后端由BIO改為NIO，并發(fā)量有大幅提高；

• 增加了對Order By, Group By, Limit等聚合功能（雖然Cobar也可以支持Order By, Group By, Limit語法，但是結(jié)果沒有進(jìn)行聚合，只是簡單返回給前端，聚合功能還是需要業(yè)務(wù)系統(tǒng)自己完成）

MyCAT架構(gòu)

• 事務(wù)是弱XA

• MyCAT的原理中最重要的一個動詞是“攔截”，它攔截了用戶發(fā)來的SQL語句，首先對SQL語句做了一些特定的分析：如分片分析，路由分析、讀寫分離分析、緩存分析等，然后將此SQL發(fā)往后端的真實數(shù)據(jù)庫，并將返回的結(jié)果做適當(dāng)?shù)奶幚?，最終再返回給用戶。

• MyCAT對自身不支持的SQL語句提供了一種解決方案——在要執(zhí)行的SQL語句前添加額外的一段由注解SQL組織的代碼，這樣SQL就能正確執(zhí)行，這段代碼稱之為“注解”。注解的使用相當(dāng)于對MyCAT不支持的SQL語句做了一層透明代理轉(zhuǎn)發(fā)，直接交給目標(biāo)的數(shù)據(jù)節(jié)點進(jìn)行SQL語句執(zhí)行。

• MyCAT自身有類似其他數(shù)據(jù)庫的管理監(jiān)控方式，可以通過MySQL命令行，登錄管理端口（9066）執(zhí)行相應(yīng)的SQL進(jìn)行管理，也可以通過jdbc的方式進(jìn)行遠(yuǎn)程連接管理。

HA

MyCAT作為一個代理層中間件，MyCAT系統(tǒng)的高可用設(shè)計到MyCAT本身的高可用以及后端MySQL的高可用. 在多數(shù)情況下，建議采用MySQL主從復(fù)制高可用性配置并交付給MyCAT來完成后端MySQL節(jié)點的主從自動切換。

MySQL側(cè)的HA

• MySQL節(jié)點開啟主從復(fù)制的配置方案，并將主節(jié)點配置為MyCAT的dataHost里的writeNode，從節(jié)點配置為readNode，同時MyCAT內(nèi)部定期對一個dataHost里的所有writeHost與readHost節(jié)點發(fā)起心跳檢測。

• 正常情況下，MyCAT將第一個writeHost作為寫節(jié)點，所有的DML SQL會發(fā)送此節(jié)點。

• 若MyCAT開啟了讀寫分離，則查詢節(jié)點會根據(jù)讀寫分離的策略發(fā)往readHost(+writeHost)執(zhí)行。

• 如果第一個writeHost宕機，MyCAT會在默認(rèn)的三次心跳檢測失敗后，自動切換到下一個可用的writeHost執(zhí)行DML SQL語句

• 當(dāng)原來配置的MySQL寫節(jié)點宕機恢復(fù)后，作為從節(jié)點，跟隨新的主節(jié)點，重新配置主從同步。

MyCAT自身的HA

• 官方建議是采用基于硬件的負(fù)載聚亨或者軟件方式的HAproxy等。

• 如果還擔(dān)心HAproxy的穩(wěn)定性和但節(jié)點問題，則可以用keepalived的VIP的浮動功能，加以強化。

MyCAT功能和特性

• 支持SQL 92標(biāo)準(zhǔn)

• 支持Mysql集群，可以作為Proxy使用

• 支持JDBC連接多數(shù)據(jù)庫

• 支持NoSQL數(shù)據(jù)庫

• 支持galera sfor mysql集群，percona-cluster或者mariadb cluster，提供高可用性分片集群

• 自動故障切換，高可用性

• 支持讀寫分離，支持MySQL雙主多從，以及一主多從的模式

• 支持全局表，數(shù)據(jù)自動分片到多個節(jié)點，用于高效表關(guān)聯(lián)查詢

• 支持一致性Hash分片，有效解決分片擴容難題

• 多平臺支持，部署和試試簡單

• 支持Catelet開發(fā)，類似數(shù)據(jù)庫存儲過程，用于跨分片復(fù)雜SQL的人工智能編碼實現(xiàn)

• 支持NIO與AIO兩種網(wǎng)絡(luò)通信機制，windows下建議AIO,Linux下目前建議NIO

• 支持MySQL存儲過程調(diào)用

• 以插件的方式支持SQL攔截和改寫

• 支持自增長逐漸、支持Oracle的Sequence機制

• 支持Mysql, MongoDB，Oracle, SQL Server, Hive, DB2, PostgreSQL等。

MyCAT目前的項目

• MyCAT-Server:MyCAT核心服務(wù)

• MyCAT-Spider:MyCAT爬蟲技術(shù)

• MyCAT-ConfigCenter:MyCAT配置中心

• MyCAT-BigSQL:MyCAT大數(shù)據(jù)處理（暫未更細(xì)）

• MyCAT-Web:MyCAT監(jiān)控及web（新版開發(fā)中）

• MyCAT-Balance:MyCAT負(fù)載均衡（暫未更細(xì)）

DRDS/TDDL

alibaba. Distributed Relational Database Service.

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

TDDL

Tabao根據(jù)自己的業(yè)務(wù)特點開發(fā)了TDDL(Tabao Distributed Data Layer, 外號：頭都大了)。主要解決了分庫分表對應(yīng)用的透明化以及異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)復(fù)制，它是一個基于集中式配置的jdbc datasourcce實現(xiàn)，具有主備，讀寫分離，動態(tài)數(shù)據(jù)庫配置等功能。

TDDL并非獨立的中間件，只能算作中間層，是以Jar包方式提供給應(yīng)用調(diào)用。屬于JDBC Shard的思想。

TDDL處于業(yè)務(wù)層和JDBC層中間。

TDDL其實主要可以劃分為3層架構(gòu)，分別是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ù)源。

TDDL社區(qū)處于停滯狀態(tài)，網(wǎng)上可查資源也較少。

RDRS

DRDS/TDDL是阿里巴巴自主研發(fā)的分布式數(shù)據(jù)庫服務(wù)。DRDS脫胎于阿里巴巴開源的Cobar分布式數(shù)據(jù)庫引擎，吸收了Cobar核心的Cobar-Proxy源碼，實現(xiàn)了一套獨立的類似MySQL-Proxy協(xié)議的解析端，能夠?qū)魅氲腟QL進(jìn)行解析和處理，對應(yīng)用程序屏蔽各種復(fù)雜的底層DB拓?fù)浣Y(jié)構(gòu)，獲得單機數(shù)據(jù)庫一樣的使用體驗，同時借鑒了淘寶TDDL豐富的分布式數(shù)據(jù)庫實踐經(jīng)驗，實現(xiàn)了對分布式Join支持，SUM/MAX/COUNT/AVG等聚合函數(shù)支持以及排序等函數(shù)支持，通過異構(gòu)索引、小表廣播等解決分布式數(shù)據(jù)庫使用場景下衍生出的一系列問題，最終形成了完整的分布式數(shù)據(jù)庫方案。

DRDS在整個阿里系統(tǒng)中所處的位置：

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

• 讀寫分離，能夠運行實現(xiàn)一臺機器寫入，多臺機器讀取，這對于讀多寫少的應(yīng)用，能夠以極低的成本解決系統(tǒng)的瓶頸。

• 數(shù)據(jù)庫切分是一個解決系統(tǒng)存儲瓶頸的最終極解決方案，數(shù)據(jù)庫切分的核心思想其實很簡單，就是分而治之。將數(shù)據(jù)分散到多臺機器，并保證請求能夠平均的分發(fā)到這些機器上，就可以以極低的成本來解決業(yè)務(wù)的各類性能瓶頸。當(dāng)然切分也是有代價的，最明顯的代價就是，分布式數(shù)據(jù)庫會對一些原有單機數(shù)據(jù)的場景進(jìn)行限制，因為這些操作，在分布式環(huán)境下的延遲或效率非常低效，就算是能夠?qū)崿F(xiàn)出來，也會因為性能問題而無法使用。

其他功能特性

1.分布式MySQL執(zhí)行引擎

主要目標(biāo)是實現(xiàn)與單機數(shù)據(jù)庫SQL引擎的完全兼容，實現(xiàn)SQL的智能下推，能夠智能分析SQL，解析出那些SQL可以直接下發(fā)，那些SQL需要進(jìn)行優(yōu)化改造，優(yōu)化成什么樣，以及路由到哪些實例節(jié)點上執(zhí)行，充分發(fā)揮數(shù)據(jù)庫實例的全部能力，減少網(wǎng)絡(luò)之間的數(shù)據(jù)傳輸量，最終對不同實例處理后的少量結(jié)果進(jìn)行聚合計算返回給應(yīng)用調(diào)用方。這就是分布式SQL引擎的智能下推功能。 
分布式引擎的職責(zé)包含SQL解析，優(yōu)化，執(zhí)行和合并四個流程。

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

案例分析： 

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

2.在線平滑擴容

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

3.小表廣播

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

4.全局唯一ID

DRDS sequence功能的目標(biāo)只是為了保證數(shù)據(jù)的全局唯一，雖然基本上是按時間序列獲取的，但并不全局有序。

5.異構(gòu)索引

解決分布式場景下數(shù)據(jù)拆分維度和數(shù)據(jù)查詢使用維度不一致導(dǎo)致的低效問題。

當(dāng)數(shù)據(jù)表被拆分為多個分庫分表時，數(shù)據(jù)在分庫分表的分布規(guī)則就固定了。但是通常數(shù)據(jù)的業(yè)務(wù)使用場景非常復(fù)雜，如果數(shù)據(jù)的查詢維度和數(shù)據(jù)拆分分布的規(guī)則一直，單條SQL會在一個分庫分表上執(zhí)行；如果數(shù)據(jù)的查詢使用維度和數(shù)據(jù)拆分分布的規(guī)格不一致，單條SQL可能在多個分庫分表上執(zhí)行，出現(xiàn)跨庫查詢，跨庫查詢會增加IO成本，查詢效率必然下降。

解決這個問題的思路還是分布式數(shù)據(jù)庫的一貫原則，讓SQL執(zhí)行在單庫上完成，實際采用的方式就是用“空間換效率”的方案，也就是將同一份數(shù)據(jù)表，冗余存儲多份，按照不同的業(yè)務(wù)使用場景進(jìn)行拆分，保持拆分維度和使用維度統(tǒng)一，而多份數(shù)據(jù)之間會實時數(shù)據(jù)復(fù)制以解決數(shù)據(jù)一致性問題，這就是“異構(gòu)索引”方案。當(dāng)然異構(gòu)索引表不能無限制濫用，過多的異構(gòu)索引表會影響同步效率，對源數(shù)據(jù)表造成同步壓力。

其他同款中間件

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

Atlas

Qihoo 360. 
Web平臺部基礎(chǔ)架構(gòu)團隊開發(fā)維護的一個基于MySQL協(xié)議的數(shù)據(jù)中間層項目，它是在mysql-proxy 0.8.2版本上對其進(jìn)行優(yōu)化，增加了一些新的功能特性。 
Atlas是一個位于應(yīng)用程序與MySQL之間，它實現(xiàn)了MySQL的客戶端和服務(wù)端協(xié)議，作為服務(wù)端與應(yīng)用程序通訊，同時作為客戶端與MySQL通訊。它對應(yīng)用程序屏蔽了DB的細(xì)節(jié)。 
Altas不能實現(xiàn)分布式分表，所有的字表必須在同一臺DB的同一個DataBase里且所有的字表必須實現(xiàn)建好，Altas沒有自動建表的功能。

Heisenberg

Baidu. 
其優(yōu)點：分庫分表與應(yīng)用脫離，分庫表如同使用單庫表一樣，減少db連接數(shù)壓力，熱重啟配置，可水平擴容，遵守MySQL原生協(xié)議，讀寫分離，無語言限制，mysqlclient, c, Java都可以使用Heisenberg服務(wù)器通過管理命令可以查看，如連接數(shù)，線程池，結(jié)點等，并可以調(diào)整采用velocity的分庫分表腳本進(jìn)行自定義分庫表，相當(dāng)?shù)撵`活。 
（開源版已停止維護）

CDS

JD. Completed Database Sharding. 
CDS是一款基于客戶端開發(fā)的分庫分表中間件產(chǎn)品，實現(xiàn)了JDBC標(biāo)準(zhǔn)API，支持分庫分表，讀寫分離和數(shù)據(jù)運維等諸多共，提供高性能，高并發(fā)和高可靠的海量數(shù)據(jù)路由存取服務(wù)，業(yè)務(wù)系統(tǒng)可近乎零成本進(jìn)行介入，目前支持MySQL, Oracle和SQL Server. 
(架構(gòu)上和Cobar，MyCAT相似，直接采用jdbc對接，沒有實現(xiàn)類似MySQL協(xié)議，沒有NIO,AIO，SQL Parser模塊采用JSqlParser, Sql解析器有：druid>JSqlParser>fdbparser.)

DDB

豬場. Distributed DataBase. 
DDB經(jīng)歷了三次服務(wù)模式的重大更迭：Driver模式->Proxy模式->云模式。

• Driver模式：基于JDBC驅(qū)動訪問，提供一個db.jar, 和TDDL類似， 位于應(yīng)用層和JDBC之間.

• Proxy模式：在DDB中搭建了一組代理服務(wù)器來提供標(biāo)準(zhǔn)的MySQL服務(wù)，在代理服務(wù)器內(nèi)部實現(xiàn)分庫分表的邏輯。應(yīng)用通過標(biāo)準(zhǔn)數(shù)據(jù)庫驅(qū)動訪問DDB Proxy, Proxy內(nèi)部通過MySQL解碼器將請求還原為SQL, 并由DDB Driver執(zhí)行得到結(jié)果。

• 私有云模式：基于網(wǎng)易私有云開發(fā)的一套平臺化管理工具Cloudadmin, 將DDB原先Master的功能打散，一部分分庫相關(guān)功能集成到proxy中，如分庫管理、表管理、用戶管理等，一部分中心化功能集成到Cloudadmin中，如報警監(jiān)控，此外，Cloudadmin中提供了一鍵部署、自動和手動備份，版本管理等平臺化功能。

數(shù)據(jù)增量訂閱與消費

基于數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱&消費，目前主要支持了mysql. 
有關(guān)數(shù)據(jù)增量訂閱與消費的中間件回顧一下：

• 增量訂閱和消費模塊應(yīng)當(dāng)包括binlog日志抓取，binlog日志解析，事件分發(fā)過濾（EventSink），存儲（EventStore）等主要模塊。

• 如果需要確保HA可以采用Zookeeper保存各個子模塊的狀態(tài)，讓整個增量訂閱和消費模塊實現(xiàn)無狀態(tài)化，當(dāng)然作為consumer(客戶端)的狀態(tài)也可以保存在zk之中。

• 整體上通過一個Manager System進(jìn)行集中管理，分配資源。

Canal

Canal架構(gòu)圖：

說明：

• server代表一個canal運行實例，對應(yīng)于一個jvm

• instance對應(yīng)于一個數(shù)據(jù)隊列 （1個server對應(yīng)1..n個instance)

instance模塊：

• eventParser (數(shù)據(jù)源接入，模擬slave協(xié)議和master進(jìn)行交互，協(xié)議解析)

• eventSink (Parser和Store鏈接器，進(jìn)行數(shù)據(jù)過濾，加工，分發(fā)的工作)

• eventStore (數(shù)據(jù)存儲)

• metaManager (增量訂閱&消費信息管理器)

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

數(shù)據(jù)庫同步

Otter

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

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

基于數(shù)據(jù)庫增量日志解析，準(zhǔn)實時同步到本地機房或異地機房的mysql/oracle數(shù)據(jù)庫，一個分布式數(shù)據(jù)庫同步系統(tǒng)。

工作原理

原理描述：

1. 基于Canal開源產(chǎn)品，獲取數(shù)據(jù)庫增量日志數(shù)據(jù)。

2. 典型管理系統(tǒng)架構(gòu)，manager(Web管理)+node(工作節(jié)點) 

• manager運行時推送同步配置到node節(jié)點

• node節(jié)點將同步狀態(tài)反饋到manager上

3. 基于zookeeper，解決分布式狀態(tài)調(diào)度的，允許多node節(jié)點之間協(xié)同工作。

Otter的作用

1. 異構(gòu)庫 

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

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

• 數(shù)據(jù)庫版本升級

• 數(shù)據(jù)表遷移

• 異步二級索引

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

• 機房容災(zāi)

4. 雙向同步 

• 避免回環(huán)算法（通用的解決方案，支持大部分關(guān)系型數(shù)據(jù)庫）

• 數(shù)據(jù)一致性算法（保證雙A機房模式下，數(shù)據(jù)保證最終一直性）

5. 文件同步 

• 站點鏡像（進(jìn)行數(shù)據(jù)復(fù)制的同時，復(fù)制關(guān)聯(lián)的圖片，比如復(fù)制產(chǎn)品數(shù)據(jù)，同事復(fù)制產(chǎn)品圖片。

單機房復(fù)制示意圖

說明： 
- 數(shù)據(jù)On-Fly, 盡可能不落地，更快的進(jìn)行數(shù)據(jù)同步。（開啟node load balance算法, 如果Node節(jié)點S+ETL落在不同的Node上，數(shù)據(jù)會有個網(wǎng)絡(luò)傳輸過程） 
- node節(jié)點可以有failover/loadBalancer.

SETL

S: Select 
為解決數(shù)據(jù)來源的差異性，比如接入canal獲取增量數(shù)據(jù)，也可以接入其他系統(tǒng)獲取其他數(shù)據(jù)等。

E: Extract

T: Transform

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之間通過zookeeper進(jìn)行協(xié)同工作（一般是Select和Extract在一個機房的Node, Transform/Load落在另一個機房的Node） 
node節(jié)點可以有failover/loadBalancer。(每個機房的Node節(jié)點，都可以是集群，一臺或者多臺機器)

More:

• Otter調(diào)度模型：batch處理+雙節(jié)點部署。

• Otter數(shù)據(jù)入庫算法

• Otter雙向回環(huán)控制

• Otter數(shù)據(jù)一致性

• Otter高可用性

• Otter擴展性

異地雙活數(shù)據(jù)架構(gòu)基礎(chǔ)設(shè)施DRC

所謂DRC，就是Data Replication Center的縮寫，數(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)用會需要異地的雙活？比較常見的場景有三個：

1. 兩個地域或多個地域都有大量用戶的場景，比如在中國的用戶希望他們用杭州的RDS服務(wù)，在美國的用戶用美國的RDS服務(wù)，這就需要數(shù)據(jù)在異地同步。很多游戲，金融，傳媒，電商業(yè)務(wù)都有這種需求。滿足這個需求的難點在于跨地域的網(wǎng)絡(luò)，比如網(wǎng)絡(luò)延時長，丟包多，而且數(shù)據(jù)在公網(wǎng)傳輸會有數(shù)據(jù)泄露風(fēng)險。

2. 數(shù)據(jù)來源較多，需要介入各種異構(gòu)數(shù)據(jù)的場景。比如一個應(yīng)用需要從ODPS, RDS, OTS， OceanBase, PostgreSQL這幾個服務(wù)介入數(shù)據(jù)，他們的數(shù)據(jù)結(jié)構(gòu)和接口都不同，這種接入的成本會比較高。因此另一個可用的方法是數(shù)據(jù)寫入的時候就一份多謝為不同數(shù)據(jù)結(jié)構(gòu)

3. 下游訂閱很多的情況，比如一份數(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, OceanBase, Hbase, Oracle等多種不同的數(shù)據(jù)源的實時增量數(shù)據(jù)，支持寫入數(shù)據(jù)庫、MetaQ, ODPS等多種存儲媒介.

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

順著這個思路，阿里的異地雙活重點做了幾件事。一個是熱插拔，可以做到在業(yè)務(wù)高峰時增加節(jié)點，高峰過了把增加的節(jié)點關(guān)閉。做到這個的一個關(guān)鍵是流量實時切換 ，DRC可以在20秒以內(nèi)把一個單元（region）的流量遷移到另一個單元。另一個是數(shù)據(jù)實時恢復(fù)，就是通過一定的冗余設(shè)計，一旦一個單元掛掉了，可以在另一個單元做全量恢復(fù)。

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

數(shù)據(jù)方面的兩個核心要求：

1. 一致性，要求賣家和商品一致，單元和中心一致，也就是數(shù)據(jù)同步不能丟數(shù)據(jù)，不能錯數(shù)據(jù)，還要保證事務(wù)。

2. 實時性，需要做到秒級別的延遲。

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

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

這里的關(guān)鍵是：

• 避免循環(huán)復(fù)制：通過在DB透傳打標(biāo)事務(wù)的方式實現(xiàn)。

• 限流：峰值的壓力，我們單元化本來就選取了流量激增業(yè)務(wù)，兩邊都實時同步100%全量數(shù)據(jù)，峰值對每個系統(tǒng)的壓力有增無減。DRC的store和congo都可以根據(jù)TPS或者流量限流。限速算法的核心思想分為批量采樣，獎懲時間，平滑變速。

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

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

• 一致性：基于日志流式抓取、回放庫表結(jié)構(gòu)變更、基于事務(wù)的沖突檢測。

• 低延遲：大延遲不超過1s, 消息協(xié)議優(yōu)化，三級數(shù)據(jù)存儲，預(yù)讀優(yōu)化IO, 多連接復(fù)用和傳輸壓縮，高效的并發(fā)復(fù)制算法。

• 高可用：主備切換，拓?fù)渥兓?，心跳跟蹤，多維度容災(zāi)。

JD多中心交易系統(tǒng)

JD數(shù)據(jù)復(fù)制中間件考察和借鑒了開源社區(qū)的實現(xiàn)，例如Databus、Canal/Otter、OpenReplicator等，解析部分使用了Canal的DBSync。

多中心交易本質(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)識到cookie中，然后將用戶路由到指定的分中心。用戶訪問其他系統(tǒng)，如購物車和結(jié)算頁時，從cookie中讀取標(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ī)則的一致性，要保障這個用戶從進(jìn)來到訪問服務(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ù)總線JingoBus進(jìn)行快速數(shù)據(jù)交換，同步性能是mysql的3倍以上，而且可用性高，架構(gòu)靈活。其中，全新的總線設(shè)計解決了多中心交易跨機房的數(shù)據(jù)庫復(fù)制和多數(shù)據(jù)源間的數(shù)據(jù)異構(gòu)同步等難題，實現(xiàn)了高性能、低延時、健壯的數(shù)據(jù)同步機制。

如圖所示，數(shù)據(jù)總線主要分Relay、Snapshot和Replicator三部分構(gòu)成，其中Relay從來源數(shù)據(jù)庫抽取事務(wù)日志，并對Replicator提供日志訂閱服務(wù)，角色上相當(dāng)于Mysql Slave IO Thread。Snapshot從Relay訂閱所有事務(wù)日志，寫入持久存儲作為快照，同時向Replicator提供批量日志訂閱服務(wù)，角色上相當(dāng)于Mysql Slave Relay Log。Replicator：事務(wù)日志的消費端，從Relay或Snapshot拉取事務(wù)日志將事務(wù)日志按配置的一致性應(yīng)用到目標(biāo)數(shù)據(jù)庫，角色上相當(dāng)于Mysql Slave SQL Thread。(參考下面MySQL主備復(fù)制原理圖)

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

跨數(shù)據(jù)庫（數(shù)據(jù)源）遷移

yugong

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

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

概述

整個數(shù)據(jù)遷移過程，分為兩個部分：

1. 全量遷移

2. 增量遷移

過程描述：

1. 增量數(shù)據(jù)收集（創(chuàng)建Oracle表的增量物化視圖）

2. 進(jìn)行全量復(fù)制

3. 進(jìn)行增量復(fù)制（可并行進(jìn)行數(shù)據(jù)校驗）

4. 原庫停寫，切換到新庫

Oracle全量基于JDBC拉取數(shù)據(jù)，增量基于物化視圖來實現(xiàn)。

架構(gòu)

說明：

1. 一個JVM Container 對應(yīng)多個instance，每個instance對應(yīng)于一張表的遷移任務(wù)

2. instance分為三部分 

• extractor (從數(shù)據(jù)源庫上提取數(shù)據(jù)，可分為全量/增量實現(xiàn))

• translator （將源庫上的數(shù)據(jù)按照目標(biāo)庫的需求進(jìn)行自定義轉(zhuǎn)化）

• applier（將數(shù)據(jù)更新到目標(biāo)庫，可分為全量/增量/對比的實現(xiàn)）

自定義數(shù)據(jù)轉(zhuǎn)換

如果要遷移的Oracle和mysql的表結(jié)構(gòu)不同，比如表名，字段名有差異，字段類型不兼容，需要使用自定義數(shù)據(jù)轉(zhuǎn)換。如果完全相同則可以跳過。

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

1. 表名不同

2. 字段名不同

3. 字段類型不同

4. 字段個數(shù)不同

5. 運行過程join其他表的數(shù)據(jù)做計算等

運行模式介紹

1.MARK模式（MARK）

開啟增量日志模式，如果是Oracle就是創(chuàng)建物化視圖（materialized view）。

2.CLEAR模式（CLEAR）

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

3.全量模式（FULL)

全量模式，顧名思議即為對源表進(jìn)行一次全量操作，遍歷源表所有的數(shù)據(jù)后，插入目標(biāo)表.

全量有兩種處理方式：

1. 分頁處理：如果源表存在主鍵，只有一個主鍵字段，并且主鍵字段類型為Number類型，默認(rèn)會選擇該分頁處理模式. 優(yōu)點：支持?jǐn)帱c續(xù)做，對源庫壓力相對較小。 缺點：遷移速度慢

2. once處理：通過select * from訪問整個源表的某一個mvcc版本的數(shù)據(jù)，通過cursor.next遍歷整個結(jié)果集. 優(yōu)點：遷移速度快，為分頁處理的5倍左右。 缺點：源庫壓力大，如果源庫并發(fā)修改量大，會導(dǎo)致數(shù)據(jù)庫MVCC版本過多，出現(xiàn)棧錯誤. 還有就是不支持?jǐn)帱c續(xù)做.

4.增量模式（INC）

全量模式，顧名思議即為對源表增量變化的數(shù)據(jù)插入目標(biāo)表，增量模式依賴記錄日志功能.

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

5.自動模式(ALL)

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

自動模式的內(nèi)部實現(xiàn)步驟：

1. 開啟記錄日志功能. (創(chuàng)建物化視圖)

2. 運行全量同步模式. (全量完成后，自動進(jìn)入下一步)

3. 運行增量同步模式. (增量模式，沒有完成的概念，所以也就不會自動退出，需要業(yè)務(wù)判斷是否可以退出，可以看一下切換流程)

6.對比模式(CHECK)

對比模式，即為對源庫和目標(biāo)庫的數(shù)據(jù)進(jìn)行一次全量對比，驗證一下遷移結(jié)果. 對比模式為一種可選運行，做完全量/增量/自動模式后，可選擇性的運行對比模式，來確保本次遷移的正確性.

DataX

DataX是一個在異構(gòu)的數(shù)據(jù)庫/文件系統(tǒng)之間高速交換數(shù)據(jù)的工具，實現(xiàn)了在任意的數(shù)據(jù)處理系統(tǒng)(RDBMS/Hdfs/Local filesystem）之間的數(shù)據(jù)交換。

目前成熟的數(shù)據(jù)導(dǎo)入導(dǎo)出工具比較多，但是一般都只能用于數(shù)據(jù)導(dǎo)入或者導(dǎo)出，并且只能支持一個或者幾個特定類型的數(shù)據(jù)庫。

這樣帶來的一個問題是，如果我們擁有很多不同類型的數(shù)據(jù)庫/文件系統(tǒng)(Mysql/Oracle/Rac/Hive/Other…)，并且經(jīng)常需要在它們之間導(dǎo)入導(dǎo)出數(shù)據(jù)，那么我們可能需要開發(fā)/維護/學(xué)習(xí)使用一批這樣的工具(jdbcdump/dbloader/multithread/getmerge+sqlloader/mysqldumper…)。而且以后每增加一種庫類型，我們需要的工具數(shù)目將線性增長。(當(dāng)我們需要將mysql的數(shù)據(jù)導(dǎo)入oracle的時候，有沒有過想從jdbcdump和dbloader上各掰下來一半拼在一起到?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正是為了解決這些問題而生。

• 左圖：新增第n+1個數(shù)據(jù)源，是不是需要開發(fā)n個數(shù)據(jù)同步工具？

• 右圖：只需要針對新增的數(shù)據(jù)源開發(fā)一套Reader/Writer插件，即可實現(xiàn)任意數(shù)據(jù)的互導(dǎo)。

設(shè)計理念

為了解決異構(gòu)數(shù)據(jù)源同步問題，DataX將復(fù)雜的網(wǎng)狀的同步鏈路變成了星型數(shù)據(jù)鏈路，DataX作為中間傳輸載體負(fù)責(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ù)同步框架，采用Framework+plugin架構(gòu)構(gòu)建。將數(shù)據(jù)源讀取和寫入抽象稱為Reader/Writer插件，納入到整個同步框架中。

• Reader： Reader為數(shù)據(jù)采集模塊，負(fù)責(zé)采集數(shù)據(jù)源的數(shù)據(jù)，將數(shù)據(jù)發(fā)送給Framework.

• Writer：Writer為數(shù)據(jù)寫入模塊，負(fù)責(zé)不斷向Framework取數(shù)據(jù)，并將數(shù)據(jù)寫入到目的端

• Framework：Framework用于連接reader和writer,作為兩者的數(shù)據(jù)傳輸通道，并處理緩存，流控，并發(fā)，數(shù)據(jù)轉(zhuǎn)換等核心技術(shù)問題。

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

核心架構(gòu)

DataX3.0 開源版本支持單機多線程模式完成同步作業(yè)運行，這里按一個DataX作業(yè)生命周期的時序圖，從整體架構(gòu)設(shè)計非常簡要說明DataX各個模塊相互關(guān)系。

核心模塊介紹：

1. DataX完成單個數(shù)據(jù)同步的作業(yè)，我們稱之為Job，DataX接受到一個Job之后，將啟動一個進(jìn)程來完成整個作業(yè)同步過程。DataX Job模塊是單個作業(yè)的中樞管理節(jié)點，承擔(dān)了數(shù)據(jù)清理、子任務(wù)切分(將單一作業(yè)計算轉(zhuǎn)化為多個子Task)、TaskGroup管理等功能。

2. DataXJob啟動后，會根據(jù)不同的源端切分策略，將Job切分成多個小的Task(子任務(wù))，以便于并發(fā)執(zhí)行。Task便是DataX作業(yè)的最小單元，每一個Task都會負(fù)責(zé)一部分?jǐn)?shù)據(jù)的同步工作。

3. 切分多個Task之后，DataX Job會調(diào)用Scheduler模塊，根據(jù)配置的并發(fā)數(shù)據(jù)量，將拆分成的Task重新組合，組裝成TaskGroup(任務(wù)組)。每一個TaskGroup負(fù)責(zé)以一定的并發(fā)運行完畢分配好的所有Task，默認(rèn)單個任務(wù)組的并發(fā)數(shù)量為5。

4. 每一個Task都由TaskGroup負(fù)責(zé)啟動，Task啟動后，會固定啟動Reader—>Channel—>Writer的線程來完成任務(wù)同步工作。

5. DataX作業(yè)運行起來之后， Job監(jiān)控并等待多個TaskGroup模塊任務(wù)完成，等待所有TaskGroup任務(wù)完成后Job成功退出。否則，異常退出，進(jìn)程退出值非0。

DataX調(diào)度流程：

舉例來說，用戶提交了一個DataX作業(yè)，并且配置了20個并發(fā)，目的是將一個100張分表的mysql數(shù)據(jù)同步到odps里面。 DataX的調(diào)度決策思路是： 
1. DataXJob根據(jù)分庫分表切分成了100個Task。 
2. 根據(jù)20個并發(fā)，DataX計算共需要分配4個TaskGroup。 
3. 4個TaskGroup平分切分好的100個Task，每一個TaskGroup負(fù)責(zé)以5個并發(fā)共計運行25個Task。

【本文轉(zhuǎn)載自 Golang語言社區(qū) ，原文鏈接：https://mp.weixin.qq.com/s?src=11×tamp=1534989045&ver=1077&signature=ToJO30*XGVmdovXyPH*VxtSZ1-luOF39RVYMhRawyBaEzImS5l9ypwOPovM3wRIfmjfKaqafI7bDrhL57krSP6E9fd2eQAJUHmSG2Yu9YhwRe-*0XuBcM6O8JeuNAeV9&new=1】

網(wǎng)頁標(biāo)題：互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)庫相關(guān)中間件介紹與實踐！-創(chuàng)新互聯(lián)
文章URL：http://weahome.cn/article/jspis.html