mysql資料庫中介軟體研究

標籤：

隨著互連網的發展，資料量的不斷增大。 單台執行個體已經遠遠無法滿足業務的需要。 對資料庫分庫分表的需求不斷的增加隨之而來的就是資料庫中介軟體的開發。 

一、 單台執行個體主要面臨下面幾個問題：

1.  資料量太大單台機器無法承載

2.  資料查詢效率太低，單表資料達到一定的量業務效能就無法滿足

3.  資料庫最佳化上的瓶頸

4. 資料安全的問題，大量資料放置在一台機器如果資料出問題回複周期會特別長，對業務影響太大。

隨之而來的就是需要分庫分表

但是分庫分表就四個字做起來可真沒有這麼簡單。 

 

二、 分庫分表面臨的問題

1.  事務支援，擴庫/擴表後事務就成分布式的了，問題難度顯然上升了一個層級 

2.  查詢結果合并，這個看起來不難，但是把order by/limit/查詢中不帶分表欄位等加上，要解決的問題還也不少 

3.  join，這個更難 

4.  分庫？分表？還是分庫分表？這個需要考慮並做一個決定 

5.  分完後能否合并？分容易，和很難 

6.  ....等等很多問題

 碰到這麼多問題總得解決， 這些問題可以慢慢的一個一個解決，資料庫中介軟體不需要對所有的功能都支援， 對於一個公司而來完全可以業務導向；

我業務需要哪些功能我提供那些功能就可以。 

 

三、 資料庫中介軟體開源實現 

 下面簡單說說當前市面上的資料庫中介軟體， 具體能不能用到自己的項目上需要自己去調研。 能不能落地也是需要走業務導向，目前我們使用cobar二次開發的（現在已經完全不同了）資料庫中介軟體已經在公司（jd）內部落地，而且可以很好的支撐海量資料的分庫分表需求。 

目前知道的開源實現有以下幾種：

Atlas，cobar，TDDL，mycat，heisenberg, Oceanus, vitess

 

　　這些解決方案中MySQL Fabric/TDDL兩個為非代理方式，直接提供語言層面的支援，優點是效能會很好，劣勢是支援的語言很受限制，TDDL支援支Java，MySQL Faric支援Java/PHP/Python，想實現其他語言支援，相當於再次實現一次，不過目前Java/PHP/Python非常流行，能夠覆蓋的使用者很多了，TDDL對於外部使用者來說，先用起來沒有那麼容易，和阿里平台緊密綁定，如果有時間配置Diamond的話，可以好好研究，這裡不進行深入探討

　　另外四個全部都是Proxy方式，以部分效能換來靈活性，這個就是仁者見仁智者見智的決定了，值得一提的是BAT中B也實現了一個 Heisenberg 的中介軟體，從部分代碼、配置以及檔案結構來看，這個是從Cobar來的，應該最佳化了部分特性，不進行贅述，有興趣可以自己研究 

MySQL Fabric 
　　這個是MySQL官方水平擴充方案，號稱管理目標為：farm of mysqld，其實我比較看好這個東西，原因是個人喜歡簡潔的東西，總感覺Proxy方式多了一層轉寄帶來了麻煩，除了效能外還有複雜性，營運起來也多了不少事情，畢竟這個進程down掉後可用性會受到影響，簡單才是美，希望MySQL Fabric能夠提供更多語言支援 

Cobar 
　　Cobar是阿里的中介軟體，以Proxy方式提供服務，在阿里內部大量使用，目前已經開源在 github 了，贊開源精神，據說在很多外部公司有一些成功使用的案例，配置比較容易，不需要依賴其他東西，有Java環境就OK，小試了一把，事務支援比較麻煩，需要通過set autocommit=0來實現，如果想要完美支援的話，還是需要修改JDBC或對應語言的MySQL library，分庫（Cobar中d.t分到兩個庫中：d1.t，d2.t）： 

　　Cobar支援分布式分表，但是不支援單庫分多表，前段（對接APP）和後端（對接MySQL）都實現了MySQL用戶端協議，比較友好，對於擴表結果集的合并也支援，寫其內部的SQL parse工程師功底應該比較深，顯示起事務會報錯，應該是“BEGIN”或者“Start transaction”不包含分表資訊的緣故，但是這個可以通過defer到後面一個包含分表資訊的SQL過來一起發到目標庫中執行或者通過分散式交易，比如2PC來支援 

Atlas 
　　雖然個人對數字公司沒啥好感，但是這個 Atlas 還是非常有特點的，它是基於MySQL-Proxy上二次開發的，主要支援兩個特性：分表和讀寫分離，但是分表的話只支援單庫多表，即事實上是不支援分布式分表的，所有分表都在同一個庫中，小試了一把，下面是分庫（四個分表t_0，t_1，t_2，t_3在同一個庫中）： 

atlas-frame 
　　Atlas擴充性限制在單一實例最大效能，但是好處是：事務支援的很好，因為不存在跨庫事務，有些事情反而變得簡單，讀寫分離這個東西其實沒有水平擴充那麼難，畢竟MySQL的備庫很好搭，不得不吐槽一下，通過atlas看到的不是一張完整的表，而是各個分表，只能通過分表的欄位定位和操作資料，否則會報錯，與Cobar對比後，Atlas這個產品其實簡潔也粗糙很多，但是的確有它特有的應用情境： 

atlas-cmd 
另外，Atlas配置稍微簡單一些，但是分表演算法支援上相對於Cobar顯得並不完善 

Vitess 
　　Vitess是 Youtube開源的資料庫擴充及高可用方案，已經用於生產環境，功能強大，但是構架複雜，部署及營運成本較高
　　Vitess在app與database之間存在vtgate及vttablet兩個server，vttablet實現了MySQL串連池及row cache，與MySQL執行個體是一對一關聯性，可以當成是MySQL前端，一般與MySQL部署在一起，所有落到MySQL的query都需要經過vttablet，vtgate是一個proxy，負責路由計算以及app及vttablet之間的資料轉寄，分表規則及配置資料存放在topology中（zookeeper實現），因此每個query執行需要走的路徑較長，雖然vttablet實現的串連池和row cache可以加速query執行速度，但是zookeeper訪問，app與vtgage、vtgate與vttablet之間兩次資料轉寄都要走網路，如果網路不夠穩定可以預見效能損失較大 

 

 

mysql資料庫中介軟體研究