- 前言
網絡應用持續擴張的過程中，爲了處理海量數據往往首先遇到的挑戰就是數據存儲的擴展
數據存儲的擴展一般以切分來實現，切分的技術實現又可分爲垂直切分和水平切分：
以表(或Schema)爲切分粒度的是垂直切分
以表內行爲切分粒度的是水平切分
初期擴展使用垂直切分就可以基本解決問題，垂直切分也相對簡單，但隨着數據行成量級的持續增長，針對這張表的各層面操作性能都會顯著降低，此時就不得不進行水平切分了，水平切分就要複雜很多
爲了應對此類挑戰，就產生了一類新的數據庫 NoSQL (Not Only SQL) ，此類的代表有 MongoDB、Redis、Memcached、Elasticsearch ，這類數據庫可以輕鬆應對數據庫的擴展(不論是水平還是垂直切分都非常高效)，在海量數據的情況下，也能有着極佳的讀寫性能，NoSQL的根本優勢就在於大數據時代易於進行大規模分佈式擴展
但是由於NoSQL固有的分佈式架構，目前對事務的支持非常弱，存儲也是弱結構的，join等複雜操作能力很差，應用場景比較侷限
數據庫弱了，就意味着，如果要實現一樣的特性，應用層面的設計得更復雜才能彌補，這也無形地引入了架構風險
爲了使用到關係模型的一些特性(交易或支付的場景，前幾年非常火熱的去IOE)，還是繞不過關係型數據庫，但是關係型數據庫先天就對分佈式支持很弱
簡單點可以這麼理解：
事務性就是序列化，高併發就是分佈式，序列化與並行相背離，所以事務性和分佈式很難和諧共處
在事務性和高併發中得有取捨，所以市面上又出現了很多用來進行協調的中間件
- MyCat關鍵特性
支持SQL92標準
遵守Mysql原生協議，跨語言，跨平臺，跨數據庫的通用中間件代理。
基於心跳的自動故障切換，支持讀寫分離，支持MySQL主從，以及galera cluster集羣。
支持Galera for MySQL集羣，Percona Cluster或者MariaDB cluster
基於Nio實現，有效管理線程，高併發問題。
支持數據的多片自動路由與聚合，支持sum,count,max等常用的聚合函數,支持跨庫分頁。
支持單庫內部任意join，支持跨庫2表join，甚至基於caltlet的多表join。
支持通過全局表，ER關係的分片策略，實現了高效的多表join查詢。
支持多租戶方案。
支持分佈式事務（弱xa）。
支持全局序列號，解決分佈式下的主鍵生成問題。
分片規則豐富，插件化開發，易於擴展。
強大的web，命令行監控。
支持前端作爲mysq通用代理，後端JDBC方式支持Oracle、DB2、SQL Server 、 mongodb 、巨杉。
支持密碼加密
支持服務降級
支持IP白名單
支持SQL黑名單、sql注入攻擊攔截
支持分表（1.6）
集羣基於ZooKeeper管理，在線升級，擴容，智能優化，大數據處理（2.0開發版）。
- 什麼是MyCat
一個徹底開源的，面向企業應用開發的大數據庫集羣
支持事務、ACID、可以替代MySQL的加強版數據庫
一個可以視爲MySQL集羣的企業級數據庫，用來替代昂貴的Oracle集羣
一個融合內存緩存技術、NoSQL技術、HDFS大數據的新型SQL Server
結合傳統數據庫和新型分佈式數據倉庫的新一代企業級數據庫產品
一個新穎的數據庫中間件產品
- MyCat架構
4、MyCat配置
MyCAT 是作爲通用代理設計的，後端是以 Mysql協議 和 JDBC 的方式連接數據庫，可以支持 Oracle、DB2、SQL Server 、 mongodb、mysql
4.1、數據庫中間件
所以Mycat沒有存儲引擎，本身並不存儲數據，只是起到了請求分析，拆解，路由與結果聚合的作用，爲前端應用提供統一接口，Mycat 與後端的數據庫集羣有機組合才一起構成一個分佈式數據庫系統。
4.2、邏輯庫（schema）
類似於LVM中VG的概念(VG由一個或多個PV構成)，邏輯庫是由一個或多個後端數據庫構成的，展示給應用的是一個單一視圖，是分佈式數據庫在邏輯上的一個抽象
4.3、邏輯表(table)
4.3.1、邏輯表
與數據庫中表相對應的，分佈式數據表在邏輯上的一個抽象
4.3.2、分片表
數據表切分後的一個部分(原表的一個真子集)
4.3.3、非分片表
沒有分片的表，就是非分片表
4.3.4、ER表
保留了實體關係特性的表，就是ER表
關係型數據庫是基於實體關係模型的相關理論來構建的數據庫，表與表間有依賴關係，通過表分組(Table Group) 讓有依賴的表在同一實例庫中從而避免了數據Join不會跨庫操作
4.3.5、全局表
全局表是所有分片上都有一份完整拷貝的表
字典表或符合字典特性的表可以被設置爲全局表
有以下特點的表，被稱作字典表：
變動不頻繁
數據量總體變化不大
數據規模不大(很少超過十萬條記錄)
會與其它表發生關聯
這類表可以通過冗餘來解決join問題，也就是所有的分片都放上一份數據的拷貝來避免跨分片聯查
4.4、分片節點(dataNode)
每個表分片所在的數據庫就是分片節點
4.5、節點主機(dataHost)
分片節點所在的服務器就是節點主機，儘量將讀寫壓力高的分片節點均衡放在不同的節點主機上，以避免單節點主機併發數限制
4.6、分片規則(rule)
分片規則就是切分數據的規則
4.7、全局序列號(sequence)
保證數據全局唯一性標識的外部機制就是全局序列號
4.8、多租戶
多租戶技術也叫多重租憑技術，就是在確保用戶間數據隔離的前提下實現在多用戶環境中共用相同系統或程序等軟硬件資源的一種軟件架構技術
獨立數據庫
共享數據庫，隔離數據架構
共享數據庫，共享數據架構
隔離級別越來越低，共享程度越來越高，均攤成本越來越低
-
- 整體關係
5、MyCat配置
Mycat 的大部分配置都是以 XML 的格式設定的。
| Conf |
Comment |
| conf/wrapper.conf |
JVM運行環境配置 |
| conf/server.xml |
用來定義系統相關變量 |
| conf/schema.xml |
用來定義邏輯庫，表，分片節點 |
| conf/rule.xml |
用來定義分片規則 |
5.1、schema.xml配置
| Attribute |
Comment |
| maxCon |
一個讀寫實例鏈接池的最大連接數 |
| minCon |
一個讀寫實例鏈接池的最小連接數，初始化連接池的大小 |
| balance |
負載均衡類型：0 代表不開啓讀寫分離機制，只使用writeHost; 1 代表readHost與writeHost分擔讀請求; 2 代表隨機分配讀請求和1類似; 3 代表只由readHost來承擔讀請求 |
| writeType |
負載均衡類型：0 代表發到第一個writeHost,掛了後切到還生存的第二個writeHost,重新啓動後以切換後的爲準，也就是不漂回；1 代表寫操作隨機發送到writeHost,這樣不安全； |
| dbType |
後端數據庫類型 |
| dbDriver |
mysql系可以使用native,其它系列得使用JDBC |
| switchType |
切換類型：-1 代表不切換，1 代表自動切換， 2 代表基於主從同步狀態決定是否切換 |
| slaveThreshold |
slave讀的安全邊界，如果Seconds_Behind_Master 大於這個值，這臺slave會被臨時剔除，以免被讀 |
writeHost/readHost
| Attribute |
Comment |
| host |
一個主機標識，便於區分，不必和真實主機名一致 |
| url |
後端實例連接地址 |
| user |
連接賬戶 |
| password |
連接密碼 |
爲什麼需要mycat
應對大數據量的存儲與操作，傳統單機單庫的數據庫無法很好的擴展性切分，架構規模和性能缺陷被放大。
Mycat的目標
解決數據存儲和業務規模迅速增長情況下的數據瓶頸問題。2014年上海《中華架構師》大會上對外宣講，截止2015年4月約估計有60多項目在使用，主要包括電信，互聯網，交易管理等領域項目。
Mycat是什麼
是一個開源的分佈式數據庫系統
是一個實現了MySQL協議的服務器，前端可以看做是一個數據庫代理，可以通過MySQL的客戶端工具訪問，後端用MySQL的原生協議與多個MySQL服務器通信，也可以通過JDBC協議與大多數主流數據庫服務器通信，其核心是分表分庫，即將一個大表水平分割爲N個小表，存儲在後端MySQL服務器或者其他數據庫服務器裏。
後端目前支持oracle，sqlserver，db2,postgresql,mysql,也支持mongodb的nosql方式存儲，對前端支持標準的SQL語句進行數據操作，可以大幅度的降低前端開發難度，提升開發速度。
Mycat解決了哪些問題
連接過多導致應用競爭問題，mycat統一管理所有數據源，後端數據庫對前端應用透明；
ER關係分片，解決ER分片難處理問題，提高誇節點join的效率；
採用全局分片技術，每個節點同時併發讀取、插入和更新數據；
支持基於MySQL主從複製狀態的高級讀寫分離控制機制；
全局表
HBT（Human Brain Tech）人工智能catlet
MyCAT技術原理
攔截，mycat攔截用戶發送的SQL語句，對SQL做特定的分析如分片分析，路由分析，讀寫分離分析，緩存分析等，然後將SQL發往後端的真是數據庫，並將返回結果做適當處理，最終返回給用戶。
MyCAT的問題：
非分片字段查詢
MyCAT中的路由結果是通過分片字段和分片方法來確定的，如果查詢條件是分片字段，查詢將路由到某個具體的分片上；如果查詢條件沒有分片字段，MyCAT無法計算路由，便發送到所有節點，隨着節點的增多，會消耗更多的數據庫資源；
分頁排序問題：消耗大量的計算資源；
無法實現任意表join，必須確保相關聯的表的關聯字段具有相同的分佈；
MyCat無法實現事務強一直性；
趨勢：數據庫應用已經普遍建立於計算機網絡之上了
集中式數據庫的不足
集中式處理勢必造成存儲和性能瓶頸
無法高可用；
系統的規模和配置都不夠靈活，系統的可擴展性差
Amoeba專注於分佈式數據庫前端代理層，具有負載均衡，高可用，SQL過濾，讀寫分離，SQL路由，結果合併等功能，穩定性，性能和功能支持不夠好，核心人員的離開
Cobar 基於Amoeba開發，穩定，可靠，優秀的架構設計2013年後沒在更新
MyCat 基於Cobar開發，
解決數據存儲和業務規模迅速增長的情況下的數據瓶頸問題；
單主機模式：LAMP服務都在一臺主機上；
獨立主機模式：將web服務器和MySQL服務器分開，分別部署獨立主機模式；
讀寫分離：考慮業務實時性要求，寫庫不方便橫向擴展；
業務垂直拆分：解決高併發下單庫寫入壓力無法分擔的問題，單庫的壓力還沒有明顯的緩解；
單業務庫水平垂直切分：水平拆分橫向擴展比較好，對查詢挑戰比較大；
業務垂直切分，業務無關的關鍵字水平拆分，不能無限擴展，確定好分庫個數後基本不可添加