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

• 2019 年 10 月 14 日
• 筆記

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 發布！