分布式資料庫中介軟體對比總結

目前資料庫中介軟體有很多，基本這些中介軟體在下都有了解和使用，各種中介軟體優缺點及使用場景也都有些心的。所以總結乙個關於中介軟體比較的系列，希望可以對大家有幫助。

傳統的架構模式就是應用連線資料庫直接對資料進行訪問，這種架構特點就是簡單方便。

但是隨著目前資料量不斷的增大我們就遇到了問題:

當面臨以上問題時，我們會想到的第一種解決方式就是向上擴充套件(scale up) 簡單來說就是不斷增加硬體效能。這種方式只能暫時解決問題，當業務量不斷增長時還是解決不了問題。特別是**，facebook，youtube這種業務成線性，甚至指數級上公升的情況

此時我們不得不依賴於第二種方式：水平擴充套件。直接增加機器，把資料庫放到不同伺服器上，在應用到資料庫之間加乙個proxy進行路由，這樣就可以解決上面的問題了。

很多人都會把中介軟體認為是讀寫分離，其實讀寫分離只是中介軟體可以提供的一種功能，最主要的功能還是在於他可以分庫分表，下面是乙個讀寫分離的示意圖：

上面的圖可以看出，紅線代表寫請求，綠線代表讀請求。這就是乙個簡單的讀寫分離，下面我們在看看分庫分表中介軟體。

上面這幅圖就可以看出中介軟體作用，比如下面的這個sql：

select * from table_name where id = 1;

按照中介軟體分庫分表演算法，此sql將傳送到db1節點，由db1這個mysql負責解析和獲取id=1的資料，並通過中介軟體返回給客戶端。而在讀寫分離結構中並沒有這些分庫分表規則，他只能在眾多讀節點中load balance隨機進行分發，它要求各個節點都要存放乙份完整的資料。

目前市面上中介軟體種類很多種先看下各種中介軟體背景:

阿里巴巴b2b開發的關係型分布式系統，管理將近3000個mysql例項。在阿里經受住了考驗，後面由於作者的走開的原因cobar沒有人維護了，阿里也開發了tddl替代cobar。

mycat:

社群愛好者在阿里cobar基礎上進行二次開發，解決了cobar當時存在的一些問題，並且加入了許多新的功能在其中。目前mycat社群活躍度很高，目前已經有一些公司在使用mycat。總體來說支援度比較高，也會一直維護下去，

oneproxy:

資料庫界大牛，前支付寶資料庫團隊領導樓總開發，基於mysql官方的proxy思想利用c進行開發的，oneproxy是一款商業收費的中介軟體，樓總捨去了一些功能點，專注在效能和穩定性上。有朋友測試過說在高併發下很穩定。

vitess:

這個中介軟體是youtube生產在使用的，但是架構很複雜。與以往中介軟體不同，使用vitess應用改動比較大要使用他提供語言的api介面，我們可以借鑑他其中的一些設計思想。

kingshard:

kingshard是前360atlas中介軟體開發團隊的陳菲利用業務時間用go語言開發的，目前參與開發的人員有3個左右，目前來看還不是成熟可以使用的產品，需要在不斷完善。

atlas:

360團隊基於mysql proxy 把lua用c改寫。原有版本是支援分表，目前已經放出了分庫分表版本。在網上看到一些朋友經常說在高並發下會經常掛掉，如果大家要使用需要提前做好測試。

maxscale與mysql route:

這兩個中介軟體都算是官方的吧，maxscale是mariadb (mysql原作者維護的乙個版本)研發的，目前版本不支援分庫分表。

mysql route是現在mysql 官方oracle公司發布出來的乙個中介軟體。

這兩個中介軟體後面也會跟進測試下，看下效果如何。

這裡主要是簡單介紹了下各種中介軟體由來和特點，後面文章會陸續介紹各個中介軟體更詳細的特性，優缺點，效能測試結果