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的一些新特性：
1、主庫宕機不影響讀主庫宕機，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 發布！

標籤：Go

上一篇：求RFC-4510的中文譯文資源

下一篇：解釋一下Delphi中的模塊