mysql-proxy是官方提供的mysql中間件產(chǎn)品可以實現(xiàn)負載平衡,讀寫分離,failover等,但其不支持大數(shù)據(jù)量的分庫分表且性能較差。下面介紹幾款能代替其的mysql開源中間件產(chǎn)品,Atlas,cobar,tddl,讓我們看看它們各自有些什么優(yōu)點和新特性吧。
Atlas
Atlas是由 Qihoo 360, Web平臺部基礎(chǔ)架構(gòu)團隊開發(fā)維護的一個基于MySQL協(xié)議的數(shù)據(jù)中間層項目。它是在mysql-proxy 0.8.2版本的基礎(chǔ)上,對其進行了優(yōu)化,增加了一些新的功能特性。360內(nèi)部使用Atlas運行的mysql業(yè)務(wù),每天承載的讀寫請求數(shù)達幾十億條。
Altas架構(gòu):
Atlas是一個位于應(yīng)用程序與MySQL之間,它實現(xiàn)了MySQL的客戶端與服務(wù)端協(xié)議,作為服務(wù)端與應(yīng)用程序通訊,同時作為客戶端與MySQL通訊。它對應(yīng)用程序屏蔽了DB的細節(jié),同時為了降低MySQL負擔,它還維護了連接池。
以下是一個可以參考的整體架構(gòu),LVS前端做負載均衡,兩個Altas做HA,防止單點故障。
Altas的一些新特性:
1.主庫宕機不影響讀
主庫宕機,Atlas自動將宕機的主庫摘除,寫操作會失敗,讀操作不受影響。從庫宕機,Atlas自動將宕機的從庫摘除,對應(yīng)用沒有影響。在mysql官方的proxy中主庫宕機,從庫亦不可用。
2.通過管理接口,簡化管理工作,DB的上下線對應(yīng)用完全透明,同時可以手動上下線。
圖1是手動添加一臺從庫的示例。
3.自己實現(xiàn)讀寫分離
(1)為了解決讀寫分離存在寫完馬上就想讀而這時可能存在主從同步延遲的情況,Altas中可以在SQL語句前增加/master/ 就可以將讀請求強制發(fā)往主庫。
(2)如圖2中,主庫可設(shè)置多項,用逗號分隔,從庫可設(shè)置多項和權(quán)重,達到負載均衡。
圖2
4.自己實現(xiàn)分表(圖3)
(1)需帶有分表字段。
(2)支持SELECT、INSERT、UPDATE、DELETE、REPLACE語句。
(3)支持多個子表查詢結(jié)果的合并和排序。
圖3
這里不得不吐槽Atlas的分表功能,不能實現(xiàn)分布式分表,所有的子表必須在同一臺DB的同一個database里且所有的子表必須事先建好,Atlas沒有自動建表的功能。
5.之前官方主要功能邏輯由使用lua腳本編寫,效率低,Atlas用C改寫,QPS提高,latency降低。
6.安全方面的提升
(1)通過配置文件中的pwds參數(shù)進行連接Atlas的用戶的權(quán)限控制。
(2)通過client-ips參數(shù)對有權(quán)限連接Atlas的ip進行過濾。
(3)日志中記錄所有通過Altas處理的SQL語句,包括客戶端IP、實際執(zhí)行該語句的DB、執(zhí)行成功與否、執(zhí)行所耗費的時間 ,如下面例子(圖4)。
圖4
7.平滑重啟
通過配置文件中設(shè)置lvs-ips參數(shù)實現(xiàn)平滑重啟功能,否則重啟Altas的瞬間那些SQL請求都會失敗。該參數(shù)前面掛接的lvs的物理網(wǎng)卡的ip,注意不是虛ip。平滑重啟的條件是至少有兩臺配置相同的Atlas且掛在lvs之后。
source:https://github.com/Qihoo360/Atlas
alibaba.cobar
Cobar是阿里巴巴(B2B)部門開發(fā)的一種關(guān)系型數(shù)據(jù)的分布式處理系統(tǒng),它可以在分布式的環(huán)境下看上去像傳統(tǒng)數(shù)據(jù)庫一樣為您提供海量數(shù)據(jù)服務(wù)。那么具體說說我們?yōu)槭裁匆盟蛘fcobar--能干什么?以下是我們業(yè)務(wù)運行中會存在的一些問題:
1.隨著業(yè)務(wù)的進行數(shù)據(jù)庫的數(shù)據(jù)量和訪問量的劇增,需要對數(shù)據(jù)進行水平拆分來降低單庫的壓力,而且需要高效且相對透明的來屏蔽掉水平拆分的細節(jié)。
2.為提高訪問的可用性,數(shù)據(jù)源需要備份。
3.數(shù)據(jù)源可用性的檢測和failover。
4.前臺的高并發(fā)造成后臺數(shù)據(jù)庫連接數(shù)過多,降低了性能,怎么解決。
針對以上問題就有了cobar施展自己的空間了,cobar中間件以proxy的形式位于前臺應(yīng)用和實際數(shù)據(jù)庫之間,對前臺的開放的接口是mysql通信協(xié)議。將前臺SQL語句變更并按照數(shù)據(jù)分布規(guī)則轉(zhuǎn)發(fā)到合適的后臺數(shù)據(jù)分庫,再合并返回結(jié)果,模擬單庫下的數(shù)據(jù)庫行為。
Cobar應(yīng)用舉例
應(yīng)用架構(gòu):
應(yīng)用介紹:
1.通過Cobar提供一個名為test的數(shù)據(jù)庫,其中包含t1,t2兩張表。后臺有3個MySQL實例(ip:port)為其提供服務(wù),分別為:A,B,C。
2.期望t1表的數(shù)據(jù)放置在實例A中,t2表的數(shù)據(jù)水平拆成四份并在實例B和C中各自放兩份。t2表的數(shù)據(jù)要具備HA功能,即B或者C實例其中一個出現(xiàn)故障,不影響使用且可提供完整的數(shù)據(jù)服務(wù)。
cabar優(yōu)點總結(jié):
1.數(shù)據(jù)和訪問從集中式改變?yōu)榉植迹?br>
(1)Cobar支持將一張表水平拆分成多份分別放入不同的庫來實現(xiàn)表的水平拆分
(2)Cobar也支持將不同的表放入不同的庫
(3) 多數(shù)情況下,用戶會將以上兩種方式混合使用
注意!:Cobar不支持將一張表,例如test表拆分成test_1,test_2, test_3.....放在同一個庫中,必須將拆分后的表分別放入不同的庫來實現(xiàn)分布式。
2.解決連接數(shù)過大的問題。
3.對業(yè)務(wù)代碼侵入性少。
4.提供數(shù)據(jù)節(jié)點的failover,HA:
(1)Cobar的主備切換有兩種觸發(fā)方式,一種是用戶手動觸發(fā),一種是Cobar的心跳語句檢測到異常后自動觸發(fā)。那么,當心跳檢測到主機異常,切換到備機,如果主機恢復(fù)了,需要用戶手動切回主機工作,Cobar不會在主機恢復(fù)時自動切換回主機,除非備機的心跳也返回異常。
(2)Cobar只檢查MySQL主備異常,不關(guān)心主備之間的數(shù)據(jù)同步,因此用戶需要在使用Cobar之前在MySQL主備上配置雙向同步。
cobar缺點:
開源版本中數(shù)據(jù)庫只支持mysql,并且不支持讀寫分離。
source:http://code.alibabatech.com/wiki/display/cobar/Home
TDDL
淘寶根據(jù)自己的業(yè)務(wù)特點開發(fā)了TDDL(Taobao Distributed Data Layer 外號:頭都大了 ?_Ob)框架,主要解決了分庫分表對應(yīng)用的透明化以及異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)復(fù)制,它是一個基于集中式配置的 jdbc datasource實現(xiàn),具有主備,讀寫分離,動態(tài)數(shù)據(jù)庫配置等功能。
淘寶很早就對數(shù)據(jù)進行過分庫的處理, 上層系統(tǒng)連接多個數(shù)據(jù)庫,中間有一個叫做DBRoute的路由來對數(shù)據(jù)進行統(tǒng)一訪問。DBRoute對數(shù)據(jù)進行多庫的操作、數(shù)據(jù)的整合,讓上層系統(tǒng)像操作一個數(shù)據(jù)庫一樣操作多個庫。但是隨著數(shù)據(jù)量的增長,對于庫表的分法有了更高的要求,例如,你的商品數(shù)據(jù)到了百億級別的時候,任何一個庫都無法存放了,于是分成2個、4個、8個、16個、32個……直到1024個、2048個。好,分成這么多,數(shù)據(jù)能夠存放了,那怎么查詢它?這時候,數(shù)據(jù)查詢的中間件就要能夠承擔這個重任了,它對上層來說,必須像查詢一個數(shù)據(jù)庫一樣來查詢數(shù)據(jù),還要像查詢一個數(shù)據(jù)庫一樣快(每條查詢在幾毫秒內(nèi)完成),TDDL就承擔了這樣一個工作。在外面有些系統(tǒng)也用DAL(數(shù)據(jù)訪問層) 這個概念來命名這個中間件。
下圖展示了一個簡單的分庫分表數(shù)據(jù)查詢策略:
主要優(yōu)點:
1.數(shù)據(jù)庫主備和動態(tài)切換
2.帶權(quán)重的讀寫分離
3.單線程讀重試
4.集中式數(shù)據(jù)源信息管理和動態(tài)變更
5.剝離的穩(wěn)定jboss數(shù)據(jù)源
6.支持mysql和oracle數(shù)據(jù)庫
7.基于jdbc規(guī)范,很容易擴展支持實現(xiàn)jdbc規(guī)范的數(shù)據(jù)源
8.無server,client-jar形式存在,應(yīng)用直連數(shù)據(jù)庫
9.讀寫次數(shù),并發(fā)度流程控制,動態(tài)變更
10.可分析的日志打印,日志流控,動態(tài)變更
TDDL必須要依賴diamond配置中心(diamond是淘寶內(nèi)部使用的一個管理持久配置的系統(tǒng),目前淘寶內(nèi)部絕大多數(shù)系統(tǒng)的配置,由diamond來進行統(tǒng)一管理,同時diamond也已開源)。
TDDL動態(tài)數(shù)據(jù)源使用示例說明: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復(fù)雜度相對較高。當前公布的文檔較少,只開源動態(tài)數(shù)據(jù)源,分表分庫部分還未開源,還需要依賴diamond,不推薦使用。
終其所有,我們研究中間件的目的是使數(shù)據(jù)庫實現(xiàn)性能的提高。具體使用哪種還要經(jīng)過深入的研究,嚴謹?shù)臏y試才可決定。
MyCAT
https://github.com/myCATApache
什么是MyCAT?簡單的說,MyCAT就是: 一個徹底開源的,面向企業(yè)應(yīng)用開發(fā)的“大數(shù)據(jù)庫集群” 支持事務(wù)、ACID、可以替代Mysql的加強版數(shù)據(jù)庫 ? 一個可以視為“Mysql”集群的企業(yè)級數(shù)據(jù)庫,用來替代昂貴的Oracle集群 ? 一個融合內(nèi)存緩存技術(shù)、Nosql技術(shù)、HDFS大數(shù)據(jù)的新型SQL Server ? 結(jié)合傳統(tǒng)數(shù)據(jù)庫和新型分布式數(shù)據(jù)倉庫的新一代企業(yè)級數(shù)據(jù)庫產(chǎn)品 ? 一個新穎的數(shù)據(jù)庫中間件產(chǎn)品。
目標
低成本的將現(xiàn)有的單機數(shù)據(jù)庫和應(yīng)用平滑遷移到“云”端,解決數(shù)據(jù)存儲和業(yè)務(wù)規(guī)模迅速增長情況下的數(shù)據(jù)瓶頸問題。
關(guān)鍵特性
支持 SQL 92標準 支持Mysql集群,可以作為Proxy使用 支持JDBC連接ORACLE、DB2、SQL Server,將其模擬為MySQL Server使用 支持galera for mysql集群,percona-cluster或者mariadb cluster,提供高可用性數(shù)據(jù)分片集群,自動故障切換,高可用性 。
支持讀寫分離。
支持Mysql雙主多從,以及一主多從的模式 。
支持全局表。
支持數(shù)據(jù)自動分片到多個節(jié)點,用于高效表關(guān)聯(lián)查詢 。
垮褲join,支持獨有的基于E-R 關(guān)系的分片策略,實現(xiàn)了高效的表關(guān)聯(lián)查詢多平臺支持,部署和實施簡單。
優(yōu)勢
基于阿里開源的Cobar產(chǎn)品而研發(fā),Cobar的穩(wěn)定性、可靠性、優(yōu)秀的架構(gòu)和性能,以及眾多成熟的使用案例使得MyCAT一開始就擁有一個很好的起點,站在巨人的肩膀上,我們能看到更遠。廣泛吸取業(yè)界優(yōu)秀的開源項目和創(chuàng)新思路,將其融入到MyCAT的基因中,使得MyCAT在很多方面都領(lǐng)先于目前其他一些同類的開源項目,甚至超越某些商業(yè)產(chǎn)品。MyCAT背后有一只強大的技術(shù)團隊,其參與者都是5年以上資深軟件工程師、架構(gòu)師、DBA等,優(yōu)秀的技術(shù)團隊保證了MyCAT的產(chǎn)品質(zhì)量。 MyCAT并不依托于任何一個商業(yè)公司,因此不像某些開源項目,將一些重要的特性封閉在其商業(yè)產(chǎn)品中,使得開源項目成了一個擺設(shè),目前在持續(xù)維護更新。
長期規(guī)劃
在支持Mysql的基礎(chǔ)上,后端增加更多的開源數(shù)據(jù)庫和商業(yè)數(shù)據(jù)庫的支持,包括原生支持PosteSQL、FireBird等開源數(shù)據(jù)庫,以及通過JDBC等方式間接支持其他非開源的數(shù)據(jù)庫如Oracle、DB2、SQL Server等實現(xiàn)更為智能的自我調(diào)節(jié)特性,如自動統(tǒng)計分析SQL,自動創(chuàng)建和調(diào)整索引,根據(jù)數(shù)據(jù)表的讀寫頻率,自動優(yōu)化緩存和備份策略等實現(xiàn)更全面的監(jiān)控管理功能與HDFS集成,提供SQL命令,將數(shù)據(jù)庫裝入HDFS中并能夠快速分析集成優(yōu)秀的開源報表工具,使之具備一定的數(shù)據(jù)分析的能力。
heisenberg
強大好用的mysql分庫分表中間件,來自百度
其優(yōu)點: 分庫分表與應(yīng)用脫離,分庫表如同使用單庫表一樣 減少db 連接數(shù)壓力 熱重啟配置 可水平擴容 遵守Mysql原生協(xié)議 讀寫分離 無語言限制,mysqlclient,c,java等都可以使用 Heisenberg服務(wù)器通過管理命令可以查看,如連接數(shù),線程池,結(jié)點等,并可以調(diào)整 采用velocity的分庫分表腳本進行自定義分庫表,相當?shù)撵`活
qq群:150720285 郵箱:brucest0078@gmail.com
https://github.com/songwie/heisenberg
分庫分表與應(yīng)用脫離,分庫表如同使用單庫表一樣
減少db 連接數(shù)壓力
熱重啟配置
可水平擴容
遵守Mysql原生協(xié)議
無語言限制,mysqlclient,c,java等都可以使用
Heisenberg服務(wù)器通過管理命令可以查看,如連接數(shù),線程池,結(jié)點等,并可以調(diào)整
Oceanus:
Oceanus致力于打造一個功能簡單、可依賴、易于上手、易于擴展、易于集成的解決方案,甚至是平臺化系統(tǒng)。擁抱開源,提供各類插件機制集成其他開源項目,新手可以在幾分鐘內(nèi)上手編程,分庫分表邏輯不再與業(yè)務(wù)緊密耦合,擴容有標準模式,減少意外錯誤的發(fā)生。
Oceanus****內(nèi)部名詞定義
- datanode:數(shù)據(jù)源節(jié)點。為一個數(shù)據(jù)源命名,配置鏈接屬性、報警實現(xiàn)
- namenode:數(shù)據(jù)源的簇。為一組數(shù)據(jù)源命名,指定這組數(shù)據(jù)源的負載方式、訪問模式、權(quán)重
- table:映射表。匹配解析sql中的table名稱,命中table標簽的name屬性值后,會執(zhí)行約定的路由邏輯
- bean:實體。由其他標簽引用,實體類必須有無參的構(gòu)造函數(shù)
- tracker:監(jiān)控埋點。涉及到計算和IO的功能點都有監(jiān)控點,自定義一個埋點實現(xiàn)類,當功能耗時超出預(yù)期時會執(zhí)行其中的回調(diào)函數(shù),便于監(jiān)控和優(yōu)化系統(tǒng)
為什么說****Oceanus****是非常易用的
Oceanus在設(shè)計時非常注重使用者的評價,配置結(jié)構(gòu)近乎于和使用者交流約定業(yè)務(wù)規(guī)則,便于不同的人看同一套配置,互相理解流程。當配置文件編寫 完成后,編碼就變得更加簡單,只調(diào)用Oceanus客戶端的幾個方法就可以實現(xiàn)數(shù)據(jù)庫操作,不再關(guān)心HA、報警、負載均衡、性能監(jiān)控等問題。良好的用戶視 覺減少了分庫分表在業(yè)務(wù)場景中的耦合度,對于編碼者就像只對一個table操作,Oceanus負責進行sql解析、路由、sql重寫。
如提交: select * from user; 改寫成: select * from user0; select * from user1; select * from user2; select * from user3;
分發(fā)給不同的庫(或者同庫)執(zhí)行,用戶視覺如圖:開源集成
“接地氣,擁抱開源” 是Oceanus的設(shè)計原則之一,可以很好的集成到mybatis和hibernate中,只要引用其中的插件,編寫Oceanus配置文件,然后改寫各 自的DataSource實現(xiàn)或ConnectionProvider即可做到集成。這樣既用到了熟悉的ORM,又借助Oceanus實現(xiàn)了分庫分表等功 能。
待開發(fā)
不得不說Oceanus在設(shè)計上非常靈活,使得每一個細小的功能點都有極高的切入價值,比如Cache機制、全局的ID生成規(guī)則、資源可視化監(jiān)控等等,把其中某一個點做得足夠好,都會為整體產(chǎn)品帶來質(zhì)的提升,簡化實際生產(chǎn)環(huán)境中的配套系統(tǒng)研發(fā)維護成本。
vitess:
谷歌開發(fā)的數(shù)據(jù)庫中間件,集群基于ZooKeeper管理,通過RPC方式進行數(shù)據(jù)處理,總體分為,server,command line,gui監(jiān)控 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是由原支付寶首席架構(gòu)師樓方鑫開發(fā),目前由樓方鑫創(chuàng)立的杭州平民軟件公司(@平民架構(gòu))提供技術(shù)支持。它保留了MySQL-Proxy 0.8.4官方版本上其協(xié)議處理和軟件框架,然后對軟件做了大量優(yōu)化,極大增強了系統(tǒng)的并發(fā)能力。目前已有多家公司在生成環(huán)境中使用,其中包括了支付、電商等行業(yè)。
OneProxy的主要功能有:
垂直分庫
水平分表
3. Proxy集群【暫無文檔】
讀高可用
讀寫分離(master不參與讀)
讀寫分離(master參與讀)
寫高可用
讀寫隨機
9. SQL檢查
10. SQL統(tǒng)計【暫無文檔】
任務(wù)隊列監(jiān)控【暫無文檔】
連接池管理【暫無文檔】
最新博文在http://www.cnblogs.com/youge-OneSQL/articles/4208583.html
重要概念
Server Group
在OneProxy中,一組主從復(fù)制的MySQL集群被稱為Server Group。如圖. A所示,有Server Group A和Server Group B。
圖. A
在OneProxy中,垂直分庫和水平分表的實現(xiàn)思路都是建立在Server Group的概念上。為了更好地說明,我們假設(shè)以下場景。
A)Server Group A中有三張表table X, table Y, table Z,其中應(yīng)用對table X操作非常頻繁,占用大量I/O帶寬,嚴重影響了應(yīng)用對tableY, tableZ的操作效率。
圖. B
解決方案1.0:把table X移到另一組數(shù)據(jù)庫,即Server Group B中(如圖C所示),然后通過修改OneProxy的配置來改變table X的路由規(guī)則,無須改動應(yīng)用。
圖. C
B)在使用了解決方案1.0后,系統(tǒng)的I/O壓力得到緩解。由于后期業(yè)務(wù)越來越多,Server Group B的寫入壓力越來越大,響應(yīng)時間變慢。
解決方案2.0 : 把Server Group B中的table X水平拆分,將X_00, X_01留在Server Group B中,把X_02,X_03留在Server Group C中,如圖D所示
轉(zhuǎn)載:https://mp.csdn.net/postedit
</article>