mysql-proxy是官方提供的mysql中介軟體產品可以實現負載平衡，讀寫分離，failover等，但其不支援大資料量的分庫分表且效能較差。下面介紹幾款能代替其的mysql開源中介軟體產品，Atlas，cobar，tddl，讓我們看看它們各自有些什麼優點和新特性吧。

Atlas

Atlas是由 Qihoo 360, Web平臺部基礎架構團隊開發維護的一個基於MySQL協議的資料中間層專案。它是在mysql-proxy 0.8.2版本的基礎上，對其進行了優化，增加了一些新的功能特性。360內部使用Atlas執行的mysql業務，每天承載的讀寫請求數達幾十億條。
Altas架構：
Atlas是一個位於應用程式與MySQL之間，它實現了MySQL的客戶端與服務端協議，作為服務端與應用程式通訊，同時作為客戶端與MySQL通訊。它對應用程式遮蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連線池。

以下是一個可以參考的整體架構，LVS前端做負載均衡，兩個Altas做HA,防止單點故障。

Altas的一些新特性：
1.主庫宕機不影響讀
主庫宕機，Atlas自動將宕機的主庫摘除，寫操作會失敗，讀操作不受影響。從庫宕機，Atlas自動將宕機的從庫摘除，對應用沒有影響。在mysql官方的proxy中主庫宕機，從庫亦不可用。
2.通過管理介面，簡化管理工作，DB的上下線對應用完全透明，同時可以手動上下線。
圖1是手動新增一臺從庫的示例。
圖1

3.自己實現讀寫分離
（1）為了解決讀寫分離存在寫完馬上就想讀而這時可能存在主從同步延遲的情況，Altas中可以在SQL語句前增加 /*master*/ 就可以將讀請求強制發往主庫。
（2）如圖2中，主庫可設定多項，用逗號分隔，從庫可設定多項和權重，達到負載均衡。
圖2

4.自己實現分表（圖3）
（1）需帶有分表字段。
（2）支援SELECT、INSERT、UPDATE、DELETE、REPLACE語句。
（3）支援多個子表查詢結果的合併和排序。
圖3 

這裡不得不吐槽Atlas的分表功能，不能實現分散式分表，所有的子表必須在同一臺DB的同一個database裡且所有的子表必須事先建好，Atlas沒有自動建表的功能。
5.之前官方主要功能邏輯由使用lua指令碼編寫，效率低，Atlas用C改寫，QPS提高，latency降低。
6.安全方面的提升
（1）通過配置檔案中的pwds引數進行連線Atlas的使用者的許可權控制。
（2）通過client-ips引數對有許可權連線Atlas的ip進行過濾。
（3）日誌中記錄所有通過Altas處理的SQL語句，包括客戶端IP、實際執行該語句的DB、執行成功與否、執行所耗費的時間 ，如下面例子（圖4）。
圖4

7.平滑重啟
通過配置檔案中設定lvs-ips引數實現平滑重啟功能，否則重啟Altas的瞬間那些SQL請求都會失敗。該引數前面掛接的lvs的物理網絡卡的ip，注意不是虛ip。平滑重啟的條件是至少有兩臺配置相同的Atlas且掛在lvs之後。
source：https://github.com/Qihoo360/Atlas

alibaba.cobar

Cobar是阿里巴巴（B2B）部門開發的一種關係型資料的分散式處理系統，它可以在分散式的環境下看上去像傳統資料庫一樣為您提供海量資料服務。那麼具體說說我們為什麼要用它，或說cobar--能幹什麼？以下是我們業務執行中會存在的一些問題：
1.隨著業務的進行資料庫的資料量和訪問量的劇增，需要對資料進行水平拆分來降低單庫的壓力，而且需要高效且相對透明的來遮蔽掉水平拆分的細節。
2.為提高訪問的可用性，資料來源需要備份。
3.資料來源可用性的檢測和failover。
4.前臺的高併發造成後臺資料庫連線數過多，降低了效能，怎麼解決。 
針對以上問題就有了cobar施展自己的空間了，cobar中介軟體以proxy的形式位於前臺應用和實際資料庫之間，對前臺的開放的介面是mysql通訊協議。將前臺SQL語句變更並按照資料分佈規則轉發到合適的後臺資料分庫，再合併返回結果，模擬單庫下的資料庫行為。 

Cobar應用舉例
應用架構：

應用介紹：
1.通過Cobar提供一個名為test的資料庫，其中包含t1,t2兩張表。後臺有3個MySQL例項(ip:port)為其提供服務，分別為：A,B,C。
2.期望t1表的資料放置在例項A中，t2表的資料水平拆成四份並在例項B和C中各自放兩份。t2表的資料要具備HA功能，即B或者C例項其中一個出現故障，不影響使用且可提供完整的資料服務。
cabar優點總結：
1.資料和訪問從集中式改變為分佈：
（1）Cobar支援將一張表水平拆分成多份分別放入不同的庫來實現表的水平拆分
（2）Cobar也支援將不同的表放入不同的庫
（3） 多數情況下，使用者會將以上兩種方式混合使用
注意！：Cobar不支援將一張表，例如test表拆分成test_1,test_2, test_3.....放在同一個庫中，必須將拆分後的表分別放入不同的庫來實現分散式。
2.解決連線數過大的問題。
3.對業務程式碼侵入性少。
4.提供資料節點的failover,HA：
(1)Cobar的主備切換有兩種觸發方式，一種是使用者手動觸發，一種是Cobar的心跳語句檢測到異常後自動觸發。那麼，當心跳檢測到主機異常，切換到備機，如果主機恢復了，需要使用者手動切回主機工作，Cobar不會在主機恢復時自動切換回主機，除非備機的心跳也返回異常。
(2)Cobar只檢查MySQL主備異常，不關心主備之間的資料同步，因此使用者需要在使用Cobar之前在MySQL主備上配置雙向同步。
cobar缺點：
開源版本中資料庫只支援mysql，並且不支援讀寫分離。
source：http://code.alibabatech.com/wiki/display/cobar/Home

TDDL

淘寶根據自己的業務特點開發了TDDL（Taobao Distributed Data Layer 外號:頭都大了 ©_Ob）框架，主要解決了分庫分表對應用的透明化以及異構資料庫之間的資料複製，它是一個基於集中式配置的 jdbc datasource實現，具有主備，讀寫分離，動態資料庫配置等功能。
TDDL所處的位置（tddl通用資料訪問層，部署在客戶端的jar包，用於將使用者的SQL路由到指定的資料庫中）：

淘寶很早就對資料進行過分庫的處理， 上層系統連線多個數據庫，中間有一個叫做DBRoute的路由來對資料進行統一訪問。DBRoute對資料進行多庫的操作、資料的整合，讓上層系統像操作一個數據庫一樣操作多個庫。但是隨著資料量的增長，對於庫表的分法有了更高的要求，例如，你的商品資料到了百億級別的時候，任何一個庫都無法存放了，於是分成2個、4個、8個、16個、32個……直到1024個、2048個。好，分成這麼多，資料能夠存放了，那怎麼查詢它？這時候，資料查詢的中介軟體就要能夠承擔這個重任了，它對上層來說，必須像查詢一個數據庫一樣來查詢資料，還要像查詢一個數據庫一樣快（每條查詢在幾毫秒內完成），TDDL就承擔了這樣一個工作。在外面有些系統也用DAL（資料訪問層） 這個概念來命名這個中介軟體。
下圖展示了一個簡單的分庫分表資料查詢策略：

主要優點：
1.資料庫主備和動態切換
2.帶權重的讀寫分離
3.單執行緒讀重試
4.集中式資料來源資訊管理和動態變更
5.剝離的穩定jboss資料來源
6.支援mysql和oracle資料庫
7.基於jdbc規範，很容易擴充套件支援實現jdbc規範的資料來源
8.無server,client-jar形式存在，應用直連資料庫
9.讀寫次數,併發度流程控制，動態變更
10.可分析的日誌列印,日誌流控，動態變更
TDDL必須要依賴diamond配置中心（diamond是淘寶內部使用的一個管理持久配置的系統，目前淘寶內部絕大多數系統的配置，由diamond來進行統一管理，同時diamond也已開源）。
TDDL動態資料來源使用示例說明：http://rdc.taobao.com/team/jm/archives/1645
diamond簡介和快速使用：http://jm.taobao.org/tag/diamond%E4%B8%93%E9%A2%98/
TDDL原始碼：https://github.com/alibaba/tb_tddl 
TDDL複雜度相對較高。當前公佈的文件較少，只開源動態資料來源，分表分庫部分還未開源，還需要依賴diamond，不推薦使用。
終其所有，我們研究中介軟體的目的是使資料庫實現效能的提高。具體使用哪種還要經過深入的研究，嚴謹的