mysql-proxy是官方提供的mysql中間件產(chǎn)品可以實(shí)現(xiàn)負(fù)載平衡，讀寫分離，failover等，但其不支持大數(shù)據(jù)量的分庫(kù)分表且性能較差。下面介紹幾款能代替其的mysql開源中間件產(chǎn)品，Atlas，cobar，tddl，讓我們看看它們各自有些什么優(yōu)點(diǎn)和新特性吧。

Atlas

Atlas是由 Qihoo 360, Web平臺(tái)部基礎(chǔ)架構(gòu)團(tuán)隊(duì)開發(fā)維護(hù)的一個(gè)基于MySQL協(xié)議的數(shù)據(jù)中間層項(xiàng)目。它是在mysql-proxy 0.8.2版本的基礎(chǔ)上，對(duì)其進(jìn)行了優(yōu)化，增加了一些新的功能特性。360內(nèi)部使用Atlas運(yùn)行的mysql業(yè)務(wù)，每天承載的讀寫請(qǐng)求數(shù)達(dá)幾十億條。
Altas架構(gòu)：
Atlas是一個(gè)位于應(yīng)用程序與MySQL之間，它實(shí)現(xiàn)了MySQL的客戶端與服務(wù)端協(xié)議，作為服務(wù)端與應(yīng)用程序通訊，同時(shí)作為客戶端與MySQL通訊。它對(duì)應(yīng)用程序屏蔽了DB的細(xì)節(jié)，同時(shí)為了降低MySQL負(fù)擔(dān)，它還維護(hù)了連接池。

以下是一個(gè)可以參考的整體架構(gòu)，LVS前端做負(fù)載均衡，兩個(gè)Altas做HA,防止單點(diǎn)故障。

Altas的一些新特性：
1.主庫(kù)宕機(jī)不影響讀
主庫(kù)宕機(jī)，Atlas自動(dòng)將宕機(jī)的主庫(kù)摘除，寫操作會(huì)失敗，讀操作不受影響。從庫(kù)宕機(jī)，Atlas自動(dòng)將宕機(jī)的從庫(kù)摘除，對(duì)應(yīng)用沒有影響。在mysql官方的proxy中主庫(kù)宕機(jī)，從庫(kù)亦不可用。
2.通過管理接口，簡(jiǎn)化管理工作，DB的上下線對(duì)應(yīng)用完全透明，同時(shí)可以手動(dòng)上下線。
圖1是手動(dòng)添加一臺(tái)從庫(kù)的示例。
圖1

3.自己實(shí)現(xiàn)讀寫分離
（1）為了解決讀寫分離存在寫完馬上就想讀而這時(shí)可能存在主從同步延遲的情況，Altas中可以在SQL語句前增加 /*master*/ 就可以將讀請(qǐng)求強(qiáng)制發(fā)往主庫(kù)。
（2）如圖2中，主庫(kù)可設(shè)置多項(xiàng)，用逗號(hào)分隔，從庫(kù)可設(shè)置多項(xiàng)和權(quán)重，達(dá)到負(fù)載均衡。
圖2

4.自己實(shí)現(xiàn)分表（圖3）
（1）需帶有分表字段。
（2）支持SELECT、INSERT、UPDATE、DELETE、REPLACE語句。
（3）支持多個(gè)子表查詢結(jié)果的合并和排序。
圖3

這里不得不吐槽Atlas的分表功能，不能實(shí)現(xiàn)分布式分表，所有的子表必須在同一臺(tái)DB的同一個(gè)database里且所有的子表必須事先建好，Atlas沒有自動(dòng)建表的功能。
5.之前官方主要功能邏輯由使用lua腳本編寫，效率低，Atlas用C改寫，QPS提高，latency降低。
6.安全方面的提升
（1）通過配置文件中的pwds參數(shù)進(jìn)行連接Atlas的用戶的權(quán)限控制。
（2）通過client-ips參數(shù)對(duì)有權(quán)限連接Atlas的ip進(jìn)行過濾。
（3）日志中記錄所有通過Altas處理的SQL語句，包括客戶端IP、實(shí)際執(zhí)行該語句的DB、執(zhí)行成功與否、執(zhí)行所耗費(fèi)的時(shí)間 ，如下面例子（圖4）。
圖4

7.平滑重啟
通過配置文件中設(shè)置lvs-ips參數(shù)實(shí)現(xiàn)平滑重啟功能，否則重啟Altas的瞬間那些SQL請(qǐng)求都會(huì)失敗。該參數(shù)前面掛接的lvs的物理網(wǎng)卡的ip，注意不是虛ip。平滑重啟的條件是至少有兩臺(tái)配置相同的Atlas且掛在lvs之后。
source：https://github.com/Qihoo360/Atlas

alibaba.cobar

Cobar是阿里巴巴（B2B）部門開發(fā)的一種關(guān)系型數(shù)據(jù)的分布式處理系統(tǒng)，它可以在分布式的環(huán)境下看上去像傳統(tǒng)數(shù)據(jù)庫(kù)一樣為您提供海量數(shù)據(jù)服務(wù)。那么具體說說我們?yōu)槭裁匆盟?，或說cobar--能干什么？以下是我們業(yè)務(wù)運(yùn)行中會(huì)存在的一些問題：
1.隨著業(yè)務(wù)的進(jìn)行數(shù)據(jù)庫(kù)的數(shù)據(jù)量和訪問量的劇增，需要對(duì)數(shù)據(jù)進(jìn)行水平拆分來降低單庫(kù)的壓力，而且需要高效且相對(duì)透明的來屏蔽掉水平拆分的細(xì)節(jié)。
2.為提高訪問的可用性，數(shù)據(jù)源需要備份。
3.數(shù)據(jù)源可用性的檢測(cè)和failover。
4.前臺(tái)的高并發(fā)造成后臺(tái)數(shù)據(jù)庫(kù)連接數(shù)過多，降低了性能，怎么解決。
針對(duì)以上問題就有了cobar施展自己的空間了，cobar中間件以proxy的形式位于前臺(tái)應(yīng)用和實(shí)際數(shù)據(jù)庫(kù)之間，對(duì)前臺(tái)的開放的接口是mysql通信協(xié)議。將前臺(tái)SQL語句變更并按照數(shù)據(jù)分布規(guī)則轉(zhuǎn)發(fā)到合適的后臺(tái)數(shù)據(jù)分庫(kù)，再合并返回結(jié)果，模擬單庫(kù)下的數(shù)據(jù)庫(kù)行為。

Cobar應(yīng)用舉例
應(yīng)用架構(gòu)：

應(yīng)用介紹：
1.通過Cobar提供一個(gè)名為test的數(shù)據(jù)庫(kù)，其中包含t1,t2兩張表。后臺(tái)有3個(gè)MySQL實(shí)例(ip:port)為其提供服務(wù)，分別為：A,B,C。
2.期望t1表的數(shù)據(jù)放置在實(shí)例A中，t2表的數(shù)據(jù)水平拆成四份并在實(shí)例B和C中各自放兩份。t2表的數(shù)據(jù)要具備HA功能，即B或者C實(shí)例其中一個(gè)出現(xiàn)故障，不影響使用且可提供完整的數(shù)據(jù)服務(wù)。
cabar優(yōu)點(diǎn)總結(jié)：
1.數(shù)據(jù)和訪問從集中式改變?yōu)榉植迹?br>（1）Cobar支持將一張表水平拆分成多份分別放入不同的庫(kù)來實(shí)現(xiàn)表的水平拆分
（2）Cobar也支持將不同的表放入不同的庫(kù)
（3） 多數(shù)情況下，用戶會(huì)將以上兩種方式混合使用
注意?。篊obar不支持將一張表，例如test表拆分成test_1,test_2, test_3.....放在同一個(gè)庫(kù)中，必須將拆分后的表分別放入不同的庫(kù)來實(shí)現(xiàn)分布式。
2.解決連接數(shù)過大的問題。
3.對(duì)業(yè)務(wù)代碼侵入性少。
4.提供數(shù)據(jù)節(jié)點(diǎn)的failover,HA：
(1)Cobar的主備切換有兩種觸發(fā)方式，一種是用戶手動(dòng)觸發(fā)，一種是Cobar的心跳語句檢測(cè)到異常后自動(dòng)觸發(fā)。那么，當(dāng)心跳檢測(cè)到主機(jī)異常，切換到備機(jī)，如果主機(jī)恢復(fù)了，需要用戶手動(dòng)切回主機(jī)工作，Cobar不會(huì)在主機(jī)恢復(fù)時(shí)自動(dòng)切換回主機(jī)，除非備機(jī)的心跳也返回異常。
(2)Cobar只檢查MySQL主備異常，不關(guān)心主備之間的數(shù)據(jù)同步，因此用戶需要在使用Cobar之前在MySQL主備上配置雙向同步。
cobar缺點(diǎn)：
開源版本中數(shù)據(jù)庫(kù)只支持mysql，并且不支持讀寫分離。
source：http://code./wiki/display/cobar/Home

TDDL

淘寶根據(jù)自己的業(yè)務(wù)特點(diǎn)開發(fā)了TDDL（Taobao Distributed Data Layer 外號(hào):頭都大了 ?_Ob）框架，主要解決了分庫(kù)分表對(duì)應(yīng)用的透明化以及異構(gòu)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)復(fù)制，它是一個(gè)基于集中式配置的 jdbc datasource實(shí)現(xiàn)，具有主備，讀寫分離，動(dòng)態(tài)數(shù)據(jù)庫(kù)配置等功能。
TDDL所處的位置（tddl通用數(shù)據(jù)訪問層，部署在客戶端的jar包，用于將用戶的SQL路由到指定的數(shù)據(jù)庫(kù)中）：

淘寶很早就對(duì)數(shù)據(jù)進(jìn)行過分庫(kù)的處理， 上層系統(tǒng)連接多個(gè)數(shù)據(jù)庫(kù)，中間有一個(gè)叫做DBRoute的路由來對(duì)數(shù)據(jù)進(jìn)行統(tǒng)一訪問。DBRoute對(duì)數(shù)據(jù)進(jìn)行多庫(kù)的操作、數(shù)據(jù)的整合，讓上層系統(tǒng)像操作一個(gè)數(shù)據(jù)庫(kù)一樣操作多個(gè)庫(kù)。但是隨著數(shù)據(jù)量的增長(zhǎng)，對(duì)于庫(kù)表的分法有了更高的要求，例如，你的商品數(shù)據(jù)到了百億級(jí)別的時(shí)候，任何一個(gè)庫(kù)都無法存放了，于是分成2個(gè)、4個(gè)、8個(gè)、16個(gè)、32個(gè)……直到1024個(gè)、2048個(gè)。好，分成這么多，數(shù)據(jù)能夠存放了，那怎么查詢它？這時(shí)候，數(shù)據(jù)查詢的中間件就要能夠承擔(dān)這個(gè)重任了，它對(duì)上層來說，必須像查詢一個(gè)數(shù)據(jù)庫(kù)一樣來查詢數(shù)據(jù)，還要像查詢一個(gè)數(shù)據(jù)庫(kù)一樣快（每條查詢?cè)趲缀撩雰?nèi)完成），TDDL就承擔(dān)了這樣一個(gè)工作。在外面有些系統(tǒng)也用DAL（數(shù)據(jù)訪問層） 這個(gè)概念來命名這個(gè)中間件。
下圖展示了一個(gè)簡(jiǎn)單的分庫(kù)分表數(shù)據(jù)查詢策略：

主要優(yōu)點(diǎn)：
1.數(shù)據(jù)庫(kù)主備和動(dòng)態(tài)切換
2.帶權(quán)重的讀寫分離
3.單線程讀重試
4.集中式數(shù)據(jù)源信息管理和動(dòng)態(tài)變更
5.剝離的穩(wěn)定jboss數(shù)據(jù)源
6.支持mysql和oracle數(shù)據(jù)庫(kù)
7.基于jdbc規(guī)范，很容易擴(kuò)展支持實(shí)現(xiàn)jdbc規(guī)范的數(shù)據(jù)源
8.無server,client-jar形式存在，應(yīng)用直連數(shù)據(jù)庫(kù)
9.讀寫次數(shù),并發(fā)度流程控制，動(dòng)態(tài)變更
10.可分析的日志打印,日志流控，動(dòng)態(tài)變更
TDDL必須要依賴diamond配置中心（diamond是淘寶內(nèi)部使用的一個(gè)管理持久配置的系統(tǒng)，目前淘寶內(nèi)部絕大多數(shù)系統(tǒng)的配置，由diamond來進(jìn)行統(tǒng)一管理，同時(shí)diamond也已開源）。
TDDL動(dòng)態(tài)數(shù)據(jù)源使用示例說明：http://rdc.taobao.com/team/jm/archives/1645
diamond簡(jiǎn)介和快速使用：http://jm./tag/diamond%E4%B8%93%E9%A2%98/
TDDL源碼：https://github.com/alibaba/tb_tddl
TDDL復(fù)雜度相對(duì)較高。當(dāng)前公布的文檔較少，只開源動(dòng)態(tài)數(shù)據(jù)源，分表分庫(kù)部分還未開源，還需要依賴diamond，不推薦使用。
終其所有，我們研究中間件的目的是使數(shù)據(jù)庫(kù)實(shí)現(xiàn)性能的提高。具體使用哪種還要經(jīng)過深入的研究，嚴(yán)謹(jǐn)?shù)臏y(cè)試才可決定。