轉自: http://songwie.com/articlelist/44
MySQL-PRoxy是官方提供的mysql中間件產品可以實現負載平衡，讀寫分離，failover等，但其不支持大數據量的分庫分表且性能較差。下面介紹幾款能代替其的mysql開源中間件產品，Atlas，cobar，tddl，讓我們看看它們各自有些什么優點和新特性吧。
Atlas
Atlas是由 Qihoo 360, Web平臺部基礎架構團隊開發維護的一個基于MySQL協議的數據中間層項目。它是在mysql-proxy 0.8.2版本的基礎上，對其進行了優化，增加了一些新的功能特性。360內部使用Atlas運行的mysql業務，每天承載的讀寫請求數達幾十億條。
Altas架構：Atlas是一個位于應用程序與MySQL之間，它實現了MySQL的客戶端與服務端協議，作為服務端與應用程序通訊，同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連接池。
以下是一個可以參考的整體架構，LVS前端做負載均衡，兩個Altas做HA,防止單點故障。
Altas的一些新特性：1.主庫宕機不影響讀主庫宕機，Atlas自動將宕機的主庫摘除，寫操作會失敗，讀操作不受影響。從庫宕機，Atlas自動將宕機的從庫摘除，對應用沒有影響。在mysql官方的proxy中主庫宕機，從庫亦不可用。2.通過管理接口，簡化管理工作，DB的上下線對應用完全透明，同時可以手動上下線。圖1是手動添加一臺從庫的示例。圖1
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/Atlas
alibaba.cobar
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/1645diamond簡介和快速使用：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、DB2、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、DB2、SQL Server等實現更為智能的自我調節特性，如自動統計分析SQL，自動創建和調整索引，根據數據表的讀寫頻率，自動優化緩存和備份策略等實現更全面的監控管理功能與HDFS集成，提供SQL命令，將數據庫裝入HDFS中并能夠快速分析集成優秀的開源報表工具，使之具備一定的數據分析的能力。
強大好用的mysql分庫分表中間件,來自百度
其優點： 分庫分表與應用脫離，分庫表如同使用單庫表一樣 減少db 連接數壓力 熱重啟配置 可水平擴容 遵守Mysql原生協議 讀寫分離 無語言限制，mysqlclient,c,java等都可以使用 Heisenberg服務器通過管理命令可以查看，如連接數，線程池，結點等，并可以調整 采用velocity的分庫分表腳本進行自定義分庫表，相當的靈活
QQ群：150720285 郵箱:brucest0078@Gmail.com
https://github.com/songwie/heisenberg
—Heisenberg服務器通過管理命令可以查看，如連接數，線程池，結點等，并可以調整
Oceanus致力于打造一個功能簡單、可依賴、易于上手、易于擴展、易于集成的解決方案，甚至是平臺化系統。擁抱開源，提供各類插件機制集成其他開源項目，新手可以在幾分鐘內上手編程，分庫分表邏輯不再與業務緊密耦合，擴容有標準模式，減少意外錯誤的發生。
datanode：數據源節點。為一個數據源命名，配置鏈接屬性、報警實現
namenode：數據源的簇。為一組數據源命名，指定這組數據源的負載方式、訪問模式、權重
table：映射表。匹配解析sql中的table名稱，命中table標簽的name屬性值后，會執行約定的路由邏輯
bean：實體。由其他標簽引用，實體類必須有無參的構造函數
tracker：監控埋點。涉及到計算和IO的功能點都有監控點，自定義一個埋點實現類，當功能耗時超出預期時會執行其中的回調函數，便于監控和優化系統
Oceanus在設計時非常注重使用者的評價，配置結構近乎于和使用者交流約定業務規則，便于不同的人看同一套配置，互相理解流程。當配置文件編寫 完成后，編碼就變得更加簡單，只調用Oceanus客戶端的幾個方法就可以實現數據庫操作，不再關心HA、報警、負載均衡、性能監控等問題。良好的用戶視 覺減少了分庫分表在業務場景中的耦合度，對于編碼者就像只對一個table操作，Oceanus負責進行sql解析、路由、sql重寫。
如提交： select * from user； 改寫成： select * from user0; select * from user1; select * from user2; select * from user3;分發給不同的庫(或者同庫)執行，用戶視覺如圖：
“接地氣，擁抱開源” 是Oceanus的設計原則之一，可以很好的集成到mybatis和hibernate中，只要引用其中的插件，編寫Oceanus配置文件，然后改寫各 自的DataSource實現或ConnectionProvider即可做到集成。這樣既用到了熟悉的ORM，又借助Oceanus實現了分庫分表等功 能。
不得不說Oceanus在設計上非常靈活，使得每一個細小的功能點都有極高的切入價值，比如Cache機制、全局的ID生成規則、資源可視化監控等等，把其中某一個點做得足夠好，都會為整體產品帶來質的提升，簡化實際生產環境中的配套系統研發維護成本。
谷歌開發的數據庫中間件，集群基于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!).
新聞熱點
疑難解答
