mysql的中間件比較

mysql分佈式數據庫中間件對比

目前數據庫中間件有很多,基本這些中間件在下都有了解和使用,各種中間件優缺點及使用場景也都有些心的。所以總結一個關於中間件比較的系列,希望可以對大家有幫助。

1. 什麼是中間件

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

但是隨着目前數據量不斷的增大我們就遇到了問題:

  • 單個表數據量太大
  • 單個庫數據量太大
  • 單臺數據量服務器壓力很大
  • 讀寫速度遇到瓶頸

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

此時我們不得不依賴於第二種方式: 水平擴展 。 直接增加機器,把數據庫放到不同服務器上,在應用到數據庫之間加一個proxy進行路由,這樣就可以解決上面的問題了。

2. 中間件與讀寫分離

很多人都會把中間件認爲是讀寫分離,其實讀寫分離只是中間件可以提供的一種功能,最主要的功能還是在於他可以 分庫分表 ,下面是一個讀寫分離的示意圖:

分佈式數據庫中間件對比總結

上面的圖可以看出,紅線代表寫請求,綠線代表讀請求。這就是一個簡單的讀寫分離,下面我們在看看分庫分表中間件。

分佈式數據庫中間件對比總結

上面這幅圖就可以看出中間件作用,比如下面的這個SQL:

  1.  

按照中間件分庫分表算法,此SQL將發送到DB1節點,由DB1這個MySQL負責解析和獲取id=1的數據,並通過中間件返回給客戶端。而在讀寫分離結構中並沒有這些分庫分表規則, 他只能在衆多讀節點中load balance隨機進行分發,它要求各個節點都要存放一份完整的數據。

3.各類中間件比較

目前市面上中間件種類很多種 先看下各種中間件背景:

分佈式數據庫中間件對比總結

Cobar:

阿里巴巴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公司發佈出來的一箇中間件。

這兩個中間件後面也會跟進測試下,看下效果如何。

4. 結語

這裏主要是簡單介紹了下各種中間件由來和特點,後面文章會陸續介紹各個中間件更詳細的特性,優缺點,性能測試結果。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章