mysql中間件分享（Mysql-prxoy,Atlas,DBProxy,Amoeba,cobar,TDDL）

hello 各位小夥伴你們好，我是小棧君，這期咱們分享關於mysql中間件的研究，也就是數據層的讀寫分離和負載均衡，但願可以在實際的應用中可以幫助到各位小夥伴。

下期咱們將繼續分享go語言的系列講解，以及之後的生活中咱們也將會分享系列課程包括大數據、人工智能、區塊鏈等等，但願你們可以多多學習和分享給身邊的小夥伴，咱們一塊兒進步和成長。

mysql-proxy

MySQL Proxy就是這麼一箇中間層代理，簡單的說，MySQL Proxy就是一個鏈接池，負責將前臺應用的鏈接請求轉發給後臺的數據庫，而且經過使用lua腳本，能夠實現複雜的鏈接控制和過濾。

從而實現讀寫分離和負載平衡。對於應用來講，MySQL Proxy是徹底透明MySQL Proxy更強大的一項功能是實現「讀寫分離」，基本原理是讓主數據庫處理事務性查詢。

它的執行流程如圖所示：

讓從庫處理SELECT查詢。數據庫複製被用來把事務性查詢致使的變動同步到集羣中的從庫。

mysql-proxy是官方提供的mysql中間件產品能夠實現負載平衡，讀寫分離，failover等，但其不支持大數據量的分庫分表且性能較差。

官網:
https://downloads.mysql.com/archives/proxy/

下面介紹幾款能代替其的mysql開源中間件產品，Atlas，cobar，tddl，讓咱們看看它們各自有些什麼優勢和新特性吧。

Atlas
Atlas是由 Qihoo 360, Web平臺部基礎架構團隊開發維護的一個基於MySQL協議的數據中間層項目。

它是在mysql-proxy 0.8.2版本的基礎上，對其進行了優化，增長了一些新的功能特性。360內部使用Atlas運行的mysql業務，天天承載的讀寫請求數達幾十億條。

源碼:
Github：https://github.com/Qihoo360/Atlas

可是據最新的消息是由於Atlas已經可以知足大多數公司的業務需求，因此進行了中止更新。

Altas架構：

Atlas是一個位於應用程序與MySQL之間，它實現了MySQL的客戶端與服務端協議，做爲服務端與應用程序通信，同時做爲客戶端與MySQL通信。

它對應用程序屏蔽了DB的細節，同時爲了下降MySQL負擔，它還維護了鏈接池。

Altas的一些新特性：
一、主庫宕機不影響讀主庫宕機，Atlas自動將宕機的主庫摘除，寫操做會失敗，讀操做不受影響。從庫宕機，Atlas自動將宕機的從庫摘除，對應用沒有影響。在mysql官方的proxy中主庫宕機，從庫亦不可用。

2.經過管理接口，簡化管理工做，DB的上下線對應用徹底透明，同時能夠手動上下線。

3.本身實現讀寫分離，爲了解決讀寫分離存在寫完立刻就想讀而這時可能存在主從同步延遲的狀況，Altas中能夠在SQL語句前增長 /master/ 就能夠將讀請求強制發往主庫。主庫可設置多項，用逗號分隔，從庫可設置多項和權重，達到負載均衡。

4.本身實現分表，需帶有分表字段。並且支持SELECT、INSERT、UPDATE、DELETE、REPLACE語句。最後支持多個子表查詢結果的合併和排序。

這裏不得不吐槽Atlas的分表功能，不能實現分佈式分表，全部的子表必須在同一臺DB的同一個database裏且全部的子表必須事先建好，Atlas沒有自動建表的功能。

5.以前官方主要功能邏輯由使用lua腳本編寫，效率低，Atlas用C改寫，QPS（對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準）提升，latency(一個指令發出 到 抵達 耗用的時間)下降。

6.安全方面的提高：經過配置文件中的pwds參數進行鏈接Atlas的用戶的權限控制。經過client-ips參數對有權限鏈接Atlas的ip進行過濾。

日誌中記錄全部經過Altas處理的SQL語句，包括客戶端IP、實際執行該語句的DB、執行成功與否、執行所耗費的時間

7.平滑重啓經過配置文件中設置lvs-ips參數實現平滑重啓功能，不然重啓Altas的瞬間那些SQL請求都會失敗。

DBProxy

DBProxy是由美團點評公司技術工程部DBA團隊（北京）開發維護的一個基於MySQL協議的數據中間層。它在奇虎360公司開源的Atlas基礎上，修改了部分bug，而且添加了不少特性。

目前DBProxy在美團點評普遍應用，包括美團支付、酒店旅遊、外賣、團購等產品線，公司內部對DBProxy的開發全面轉到github上，開源和內部使用保持一致。目前只支持MySQL（Percona）5.5和5.6。
主要功能：

讀寫分離

從庫負載均衡

IP過濾

分表

DBA可平滑上下線DB

自動摘除宕機的DB

監控信息完備

SQL過濾

從庫流量配置

使用DBProxy以後，應用程序只須要在鏈接串中設置DBProxy的地址，不須要關注整個數據庫集羣的結點；

DBProxy內部實現負載均衡，讀寫分離；

Slave上下線的操做由DBA在自動化運營系統上點一下鼠標就可以完成。

這樣極大的減輕了DBA和應用開發人員的工做；而沒有DBProxy的狀況下，這些工做是由RD來實現的，引入DBProxy對於系統的可管理性和便利性都有很是大的幫助。

DBProxy是基於奇虎360開源的Altas進行改進，官方文檔上說明了改進的點有：

提供了豐富的監控信息，大量參數可配置化而且支持動態修改

對原有的諸如日誌等模塊進行了優化，性能提高明顯

開源版本即爲目前美團點評內部使用版本，並將一直對源碼及其文檔進 行維護

開源地址：
https://github.com/Meituan-Dianping/DBProxy

Amoeba

Amoeba是一個以MySQL爲底層數據存儲，並對應用提供MySQL協議接口的proxy。它集中地響應應用的請求，依據用戶事先設置的規則，將SQL請求發送到特定的數據庫上執行。

基於此能夠實現負載均衡、讀寫分離、高可用性等需求。與MySQL官方的MySQL Proxy相比，做者強調的是amoeba配置的方便（基於XML的配置文件，用SQLJEP語法書寫規則，比基於lua腳本的MySQL Proxy簡單）。

Amoeba至關於一個SQL請求的路由器，目的是爲負載均衡、讀寫分離、高可用性提供機制，而不是徹底實現它們。

用戶須要結合使用MySQL的 Replication等機制來實現副本同步等功能。amoeba對底層數據庫鏈接管理和路由實現也採用了可插撥的機制，第三方能夠開發更高級的策略類來替代做者的實現。

Amoeba優勢：

a). 數據切分後複雜數據源整合

b). 提供數據切分規則並下降數據切分規則給數據庫帶來的影響

c). 下降數據庫與客戶端鏈接

d). 讀寫分離路由

Amoeba缺點：

a)、目前還不支持事務

b)、暫時不支持存儲過程（近期會支持）

c)、不適合從amoeba導數據的場景或者對大數據量查詢的query並不合適（好比一次請求返回10w以上甚至更多數據的場合）

d)、暫時不支持分庫分表，amoeba目前只作到分數據庫實例，每一個被切分的節點須要保持庫表結構一致：

官方網站：
http://wiki.hexnova.com/display/amoeba/Home

遺憾的是年代久遠，網站資料更新時間位於2012年

alibaba.cobar

Cobar是阿里巴巴（B2B）部門開發的一種關係型數據的分佈式處理系統，它能夠在分佈式的環境下看上去像傳統數據庫同樣爲您提供海量數據服務。那麼具體說說咱們爲何要用它，或說cobar--能幹什麼？

cabar優勢總結：

數據和訪問從集中式改變爲分佈：

Cobar支持將一張表水平拆分紅多份分別放入不一樣的庫來實現表的水平拆分

Cobar也支持將不一樣的表放入不一樣的庫

多數狀況下，用戶會將以上兩種方式混合使用注意！：Cobar不支持將一張表，例如test表拆分紅test_1,test_2, test_3.....放在同一個庫中，必須將拆分後的表分別放入不一樣的庫來實現分佈式。

解決鏈接數過大的問題。

對業務代碼侵入性少。

提供數據節點的failover,HA：(1)Cobar的主備切換有兩種觸發方式，一種是用戶手動觸發，一種是Cobar的心跳語句檢測到異常後自動觸發。

那麼，小心跳檢測到主機異常，切換到備機，若是主機恢復了，須要用戶手動切回主機工做，Cobar不會在主機恢復時自動切換回主機，除非備機的心跳也返回異常。

Cobar只檢查MySQL主備異常，不關心主備之間的數據同步，所以用戶須要在使用Cobar以前在MySQL主備上配置雙向同步。

cobar缺點：開源版本中數據庫只支持mysql，而且不支持讀寫分離。

TDDL(核心層代碼沒有開源)

淘寶根據本身的業務特色開發了TDDL（Taobao Distributed Data Layer 外號:頭都大了）框架，主要解決了分庫分表對應用的透明化以及異構數據庫之間的數據複製，它是一個基於集中式配置的 jdbc datasource實現，具備主備，讀寫分離，動態數據庫配置等功能。

TDDL所處的位置（tddl通用數據訪問層，部署在客戶端的jar包，用於將用戶的SQL路由到指定的數據庫中）：

淘寶很早就對數據進行過度庫的處理， 上層系統鏈接多個數據庫，中間有一個叫作DBRoute的路由來對數據進行統一訪問。

DBRoute對數據進行多庫的操做、數據的整合，讓上層系統像操做一個數據庫同樣操做多個庫。可是隨着數據量的增加，對於庫表的分法有了更高的要求。
例如，你的商品數據到了百億級別的時候，任何一個庫都沒法存放了，因而分紅2個、4個、8個、16個、32個……直到1024個、2048個。

分紅這麼多，數據可以存放了，那怎麼查詢它？

這時候，數據查詢的中間件就要可以承擔這個重任了，它對上層來講，必須像查詢一個數據庫同樣來查詢數據，還要像查詢一個數據庫同樣快（每條查詢在幾毫秒內完成），TDDL就承擔了這樣一個工做。

主要優勢：

數據庫主備和動態切換

帶權重的讀寫分離

單線程讀重試

集中式數據源信息管理和動態變動

穩定jboss數據源

支持mysql和oracle數據庫

基於jdbc規範，很容易擴展支持實現jdbc規範的數據源

無server,client-jar形式存在，應用直連數據庫

讀寫次數,併發度流程控制，動態變動10.可分析的日誌打印,日誌流控，動態變動TDDL必需要依賴diamond配置中心（diamond是淘寶內部使用的一個管理持久配置的系統，目前淘寶內部絕大多數系統的配置，由diamond來進行統一管理，同時diamond也已開源）。

源碼：
https://github.com/alibaba/tb_tddl

TDDL複雜度相對較高。並且已經年久失修了

當前公佈的文檔較少，只開源動態數據源，分表分庫部分還未開源，還須要依賴diamond，不推薦使用。

今天的分享就到這裏就結束啦，若是你喜歡個人分享，麻煩你點擊再看，分享或留言，我是小棧君，咱們下期見，拜了個拜~

本文由博客一文多發平臺 OpenWrite 發佈！