JDBC技術預研選型依據【轉】

http://songwie.com/articlelist/44 html

mycat分佈式mysql中間件(mysql中間件研究)

發表回覆前端


mysql中間件研究(

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




mysql-proxy是官方提供的mysql中間件產品能夠實現負載平衡,讀寫分離,failover等,但其不支持大數據量的分庫分表且性能較差。下面介紹幾款能代替其的mysql開源中間件產品,Atlas,cobar,tddl,讓咱們看看它們各自有些什麼優勢和新特性吧。java

Atlasnode

Atlas是由 Qihoo 360, Web平臺部基礎架構團隊開發維護的一個基於MySQL協議的數據中間層項目。它是在mysql-proxy 0.8.2版本的基礎上,對其進行了優化,增長了一些新的功能特性。360內部使用Atlas運行的mysql業務,天天承載的讀寫請求數達幾十億條。
Altas架構:
Atlas是一個位於應用程序與MySQL之間,它實現了MySQL的客戶端與服務端協議,做爲服務端與應用程序通信,同時做爲客戶端與MySQL通信。它對應用程序屏蔽了DB的細節,同時爲了下降MySQL負擔,它還維護了鏈接池。

mysql

如下是一個能夠參考的總體架構,LVS前端作負載均衡,兩個Altas作HA,防止單點故障。
git

Altas的一些新特性:
1.主庫宕機不影響讀
主庫宕機,Atlas自動將宕機的主庫摘除,寫操做會失敗,讀操做不受影響。從庫宕機,Atlas自動將宕機的從庫摘除,對應用沒有影響。在mysql官方的proxy中主庫宕機,從庫亦不可用。
2.經過管理接口,簡化管理工做,DB的上下線對應用徹底透明,同時能夠手動上下線。
圖1是手動添加一臺從庫的示例。
圖1
github

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

4.本身實現分表(圖3)
(1)需帶有分表字段。
(2)支持SELECT、INSERT、UPDATE、DELETE、REPLACE語句。
(3)支持多個子表查詢結果的合併和排序。
圖3 

這裏不得不吐槽Atlas的分表功能,不能實現分佈式分表,全部的子表必須在同一臺DB的同一個database裏且全部的子表必須事先建好,Atlas沒有自動建表的功能。
5.以前官方主要功能邏輯由使用lua腳本編寫,效率低,Atlas用C改寫,QPS提升,latency下降。
6.安全方面的提高
(1)經過配置文件中的pwds參數進行鏈接Atlas的用戶的權限控制。
(2)經過client-ips參數對有權限鏈接Atlas的ip進行過濾。
(3)日誌中記錄全部經過Altas處理的SQL語句,包括客戶端IP、實際執行該語句的DB、執行成功與否、執行所耗費的時間 ,以下面例子(圖4)。
圖4

7.平滑重啓
經過配置文件中設置lvs-ips參數實現平滑重啓功能,不然重啓Altas的瞬間那些SQL請求都會失敗。該參數前面掛接的lvs的物理網卡的ip,注意不是虛ip。平滑重啓的條件是至少有兩臺配置相同的Atlas且掛在lvs以後。
source:https://github.com/Qihoo360/Atlasweb

alibaba.cobarsql

Cobar是阿里巴巴(B2B)部門開發的一種關係型數據的分佈式處理系統,它能夠在分佈式的環境下看上去像傳統數據庫同樣爲您提供海量數據服務。那麼具體說說咱們爲何要用它,或說cobar--能幹什麼?如下是咱們業務運行中會存在的一些問題:
1.隨着業務的進行數據庫的數據量和訪問量的劇增,須要對數據進行水平拆分來下降單庫的壓力,並且須要高效且相對透明的來屏蔽掉水平拆分的細節。
2.爲提升訪問的可用性,數據源須要備份。
3.數據源可用性的檢測和failover。
4.前臺的高併發形成後臺數據庫鏈接數過多,下降了性能,怎麼解決。 
針對以上問題就有了cobar施展本身的空間了,cobar中間件以proxy的形式位於前臺應用和實際數據庫之間,對前臺的開放的接口是mysql通訊協議。將前臺SQL語句變動並按照數據分佈規則轉發到合適的後臺數據分庫,再合併返回結果,模擬單庫下的數據庫行爲。 

Cobar應用舉例
應用架構:

應用介紹:
1.經過Cobar提供一個名爲test的數據庫,其中包含t1,t2兩張表。後臺有3個MySQL實例(ip:port)爲其提供服務,分別爲:A,B,C。
2.指望t1表的數據放置在實例A中,t2表的數據水平拆成四份並在實例B和C中各自放兩份。t2表的數據要具有HA功能,即B或者C實例其中一個出現故障,不影響使用且可提供完整的數據服務。
cabar優勢總結:
1.數據和訪問從集中式改變爲分佈:
(1)Cobar支持將一張表水平拆分紅多份分別放入不一樣的庫來實現表的水平拆分
(2)Cobar也支持將不一樣的表放入不一樣的庫
(3) 多數狀況下,用戶會將以上兩種方式混合使用
注意!:Cobar不支持將一張表,例如test表拆分紅test_1,test_2, test_3.....放在同一個庫中,必須將拆分後的表分別放入不一樣的庫來實現分佈式。
2.解決鏈接數過大的問題。
3.對業務代碼侵入性少。
4.提供數據節點的failover,HA:
(1)Cobar的主備切換有兩種觸發方式,一種是用戶手動觸發,一種是Cobar的心跳語句檢測到異常後自動觸發。那麼,小心跳檢測到主機異常,切換到備機,若是主機恢復了,須要用戶手動切回主機工做,Cobar不會在主機恢復時自動切換回主機,除非備機的心跳也返回異常。
(2)Cobar只檢查MySQL主備異常,不關心主備之間的數據同步,所以用戶須要在使用Cobar以前在MySQL主備上配置雙向同步。
cobar缺點:
開源版本中數據庫只支持mysql,而且不支持讀寫分離。
source:http://code.alibabatech.com/wiki/display/cobar/Home數據庫

TDDL

淘寶根據本身的業務特色開發了TDDL(Taobao Distributed Data Layer 外號:頭都大了 ©_Ob)框架,主要解決了分庫分表對應用的透明化以及異構數據庫之間的數據複製,它是一個基於集中式配置的 jdbc datasource實現,具備主備,讀寫分離,動態數據庫配置等功能。
TDDL所處的位置(tddl通用數據訪問層,部署在客戶端的jar包,用於將用戶的SQL路由到指定的數據庫中):

淘寶很早就對數據進行過度庫的處理, 上層系統鏈接多個數據庫,中間有一個叫作DBRoute的路由來對數據進行統一訪問。DBRoute對數據進行多庫的操做、數據的整合,讓上層系統像操做一個數據庫同樣操做多個庫。可是隨着數據量的增加,對於庫表的分法有了更高的要求,例如,你的商品數據到了百億級別的時候,任何一個庫都沒法存放了,因而分紅2個、4個、8個、16個、32個……直到1024個、2048個。好,分紅這麼多,數據可以存放了,那怎麼查詢它?這時候,數據查詢的中間件就要可以承擔這個重任了,它對上層來講,必須像查詢一個數據庫同樣來查詢數據,還要像查詢一個數據庫同樣快(每條查詢在幾毫秒內完成),TDDL就承擔了這樣一個工做。在外面有些系統也用DAL(數據訪問層) 這個概念來命名這個中間件。
下圖展現了一個簡單的分庫分表數據查詢策略:

主要優勢:
1.數據庫主備和動態切換
2.帶權重的讀寫分離
3.單線程讀重試
4.集中式數據源信息管理和動態變動
5.剝離的穩定jboss數據源
6.支持mysql和oracle數據庫
7.基於jdbc規範,很容易擴展支持實現jdbc規範的數據源
8.無server,client-jar形式存在,應用直連數據庫
9.讀寫次數,併發度流程控制,動態變動
10.可分析的日誌打印,日誌流控,動態變動
TDDL必需要依賴diamond配置中心(diamond是淘寶內部使用的一個管理持久配置的系統,目前淘寶內部絕大多數系統的配置,由diamond來進行統一管理,同時diamond也已開源)。
TDDL動態數據源使用示例說明:http://rdc.taobao.com/team/jm/archives/1645
diamond簡介和快速使用:http://jm.taobao.org/tag/diamond%E4%B8%93%E9%A2%98/
TDDL源碼:https://github.com/alibaba/tb_tddl 
TDDL複雜度相對較高。當前公佈的文檔較少,只開源動態數據源,分表分庫部分還未開源,還須要依賴diamond,不推薦使用。
終其全部,咱們研究中間件的目的是使數據庫實現性能的提升。具體使用哪一種還要通過深刻的研究,嚴謹的測試纔可決定。


MyCAT

http://www.org.cn/

https://github.com/myCATApache


什麼是MyCAT?簡單的說,MyCAT就是: 一個完全開源的,面向企業應用開發的「大數據庫集羣」 支持事務、ACID、能夠替代Mysql的增強版數據庫 ? 一個能夠視爲「Mysql」集羣的企業級數據庫,用來替代昂貴的Oracle集羣 ? 一個融合內存緩存技術、Nosql技術、HDFS大數據的新型SQL Server ? 結合傳統數據庫和新型分佈式數據倉庫的新一代企業級數據庫產品 ? 一個新穎的數據庫中間件產品。

目標

低成本的將現有的單機數據庫和應用平滑遷移到「雲」端,解決數據存儲和業務規模迅速增加狀況下的數據瓶頸問題。

關鍵特性

1. 支持 SQL 92標準 支持Mysql集羣,能夠做爲Proxy使用 支持JDBC鏈接ORACLE、DB二、SQL Server,將其模擬爲MySQL Server使用 支持galera for mysql集羣,percona-cluster或者mariadb cluster,提供高可用性數據分片集羣,自動故障切換,高可用性 。

2. 支持讀寫分離。

3. 支持Mysql雙主多從,以及一主多從的模式 。

4. 支持全局表。

5. 支持數據自動分片到多個節點,用於高效表關聯查詢 。

6. 垮褲join,支持獨有的基於E-R 關係的分片策略,實現了高效的表關聯查詢多平臺支持,部署和實施簡單。

優點

基於阿里開源的Cobar產品而研發,Cobar的穩定性、可靠性、優秀的架構和性能,以及衆多成熟的使用案例使得MyCAT一開始就擁有一個很好的起點,站在巨人的肩膀上,咱們能看到更遠。普遍吸收業界優秀的開源項目和創新思路,將其融入到MyCAT的基因中,使得MyCAT在不少方面都領先於目前其餘一些同類的開源項目,甚至超越某些商業產品。MyCAT背後有一隻強大的技術團隊,其參與者都是5年以上資深軟件工程師、架構師、DBA等,優秀的技術團隊保證了MyCAT的產品質量。 MyCAT並不依託於任何一個商業公司,所以不像某些開源項目,將一些重要的特性封閉在其商業產品中,使得開源項目成了一個擺設,目前在持續維護更新。

長期規劃

在支持Mysql的基礎上,後端增長更多的開源數據庫和商業數據庫的支持,包括原生支持PosteSQL、FireBird等開源數據庫,以及經過JDBC等方式間接支持其餘非開源的數據庫如Oracle、DB二、SQL Server等實現更爲智能的自我調節特性,如自動統計分析SQL,自動建立和調整索引,根據數據表的讀寫頻率,自動優化緩存和備份策略等實現更全面的監控管理功能與HDFS集成,提供SQL命令,將數據庫裝入HDFS中並可以快速分析集成優秀的開源報表工具,使之具有必定的數據分析的能力。




heisenberg


強大好用的mysql分庫分表中間件,來自百度

其優勢: 分庫分表與應用脫離,分庫表如同使用單庫表同樣 減小db 鏈接數壓力 熱重啓配置 可水平擴容 遵照Mysql原生協議 讀寫分離 無語言限制,mysqlclient,c,java等均可以使用 Heisenberg服務器經過管理命令能夠查看,如鏈接數,線程池,結點等,並能夠調整 採用velocity的分庫分表腳本進行自定義分庫表,至關的靈活

qq羣:150720285 郵箱:brucest0078@gmail.com

https://github.com/songwie/heisenberg




—分庫分表與應用脫離,分庫表如同使用單庫表同樣

—減小db 鏈接數壓力

—熱重啓配置

—可水平擴容

—遵照Mysql原生協議

—無語言限制,mysqlclient,c,java等均可以使用

—Heisenberg服務器經過管理命令能夠查看,如鏈接數,線程池,結點等,並能夠調整

Oceanus:

Oceanus致力於打造一個功能簡單、可依賴、易於上手、易於擴展、易於集成的解決方案,甚至是平臺化系統。擁抱開源,提供各種插件機制集成其餘開源項目,新手能夠在幾分鐘內上手編程,分庫分表邏輯再也不與業務緊密耦合,擴容有標準模式,減小意外錯誤的發生。

Oceanus內部名詞定義

  • datanode:數據源節點。爲一個數據源命名,配置連接屬性、報警實現

  • namenode:數據源的簇。爲一組數據源命名,指定這組數據源的負載方式、訪問模式、權重

  • table:映射表。匹配解析sql中的table名稱,命中table標籤的name屬性值後,會執行約定的路由邏輯

  • bean:實體。由其餘標籤引用,實體類必須有無參的構造函數

  • tracker:監控埋點。涉及到計算和IO的功能點都有監控點,自定義一個埋點實現類,當功能耗時超出預期時會執行其中的回調函數,便於監控和優化系統

爲何說Oceanus是很是易用的

Oceanus在設計時很是注重使用者的評價,配置結構近乎於和使用者交流約定業務規則,便於不一樣的人看同一套配置,互相理解流程。當配置文件編寫 完成後,編碼就變得更加簡單,只調用Oceanus客戶端的幾個方法就能夠實現數據庫操做,再也不關心HA、報警、負載均衡、性能監控等問題。良好的用戶視 覺減小了分庫分表在業務場景中的耦合度,對於編碼者就像只對一個table操做,Oceanus負責進行sql解析、路由、sql重寫。

如提交:    select * from user; 改寫成:    select * from user0;            select * from user1;            select * from user2;            select * from user3;

分發給不一樣的庫(或者同庫)執行,用戶視覺如圖:github

開源集成

「接地氣,擁抱開源」 是Oceanus的設計原則之一,能夠很好的集成到mybatis和hibernate中,只要引用其中的插件,編寫Oceanus配置文件,而後改寫各 自的DataSource實現或ConnectionProvider便可作到集成。這樣既用到了熟悉的ORM,又藉助Oceanus實現了分庫分表等功 能。

待開發

不得不說Oceanus在設計上很是靈活,使得每個細小的功能點都有極高的切入價值,好比Cache機制、全局的ID生成規則、資源可視化監控等等,把其中某一個點作得足夠好,都會爲總體產品帶來質的提高,簡化實際生產環境中的配套系統研發維護成本。



vitess:

谷歌開發的數據庫中間件,集羣基於ZooKeeper管理,經過RPC方式進行數據處理,整體分爲,server,command line,gui監控 3部分。


https://github.com/youtube/vitess


Vitess is a set of servers and tools meant to facilitate scaling of MySQL databases for the web. It's been developed since 2011, and is currently used as a fundamental component of YouTube's MySQL infrastructure, serving thousands of QPS (per server). If you want to find out whether Vitess is a good fit for your project, please read our helicopter overview.



Vitess consists of a number servers, command line utilities, and a consistent metadata store. Taken together, they allow you to serve more database traffic, and add features like sharding, which normally you would have to implement in your application.

vttablet is a server that sits in front of a MySQL database, making it more robust and available in the face of high traffic. Among other things, it adds a connection pool, has a row based cache, and it rewrites SQL queries to be safer and nicer to the underlying database.

vtgate is a very light proxy that routes database traffic from your app to the right vttablet, basing on the sharding scheme, latency required, and health of the vttablets. This allows the client to be very simple, as all it needs to be concerned about is finding the closest vtgate.

The topology is a metadata store that contains information about running servers, the sharding scheme, and replication graph. It is backed by a consistent data store, like Apache ZooKeeper. The topology backends are plugin based, allowing you to write your own if ZooKeeper doesn't fit your needs. You can explore the topology through vtctld, a webserver (not shown in the diagram).

vtctl is a command line utility that allows a human or a script to easily interact with the system.

All components communicate using a lightweight RPC system based on BSON. The RPC system is plugin based, so you can easily write your own backend (at Google we use a Protocol Buffers based protocol). We provide a client implementation for three languages: Python, Go, and Java. Writing a client for your language should not be difficult, as it's a matter of implementing only a few API calls (please send us a pull request if you do!).




OneProxy

 OneProxy是由原支付寶首席架構師樓方鑫開發,目前由樓方鑫創立的杭州平民軟件公司(@平民架構)提供技術支持。它保留了MySQL-Proxy 0.8.4官方版本上其協議處理和軟件框架,而後對軟件作了大量優化,極大加強了系統的併發能力。目前已有多家公司在生成環境中使用,其中包括了支付、電商等行業。

 

     OneProxy的主要功能有:

1. 垂直分庫

2. 水平分表

3. Proxy集羣【暫無文檔】

4. 讀高可用

5. 讀寫分離(master不參與讀)

6. 讀寫分離(master參與讀)

7. 寫高可用

8. 讀寫隨機

9. SQL檢查

10. SQL統計【暫無文檔】

11. 任務隊列監控【暫無文檔】

12. 鏈接池管理【暫無文檔】

 
最新博文在http://www.cnblogs.com/youge-OneSQL/articles/4208583.html

重要概念

     Server Group

     在OneProxy中,一組主從複製的MySQL集羣被稱爲Server Group。如圖. A所示,有Server Group A和Server Group B。

     A

                                                            圖. A

     在OneProxy中,垂直分庫和水平分表的實現思路都是創建在Server Group的概念上。爲了更好地說明,咱們假設如下場景。

     A)Server Group A中有三張表table X, table Y, table Z,其中應用對table X操做很是頻繁,佔用大量I/O帶寬,嚴重影響了應用對tableY, tableZ的操做效率。

              B

                                                                      圖. B

     解決方案1.0:把table X移到另外一組數據庫,即Server Group B中(如圖C所示),而後經過修改OneProxy的配置來改變table X的路由規則,無須改動應用。

C

 

                                                                      圖. C

     B)在使用瞭解決方案1.0後,系統的I/O壓力獲得緩解。因爲後期業務愈來愈多,Server Group B的寫入壓力愈來愈大,響應時間變慢。

     解決方案2.0 : 把Server Group B中的table X水平拆分,將X_00, X_01留在Server Group B中,把X_02,X_03留在Server Group C中,如圖D所示

D

相關文章
相關標籤/搜索