1、什麼是MyCat
1.1
MyCat是一個開源的分佈式數據庫系統，是一個實現了MySQL協議的服務器，前端用戶開源把它看做是一個數據庫代理，用MySQL客戶端工具和命令行訪問，其後端能夠用MySQL原生協議與多個MySQL服務器通訊，也能夠用JDBC協議與大多數主流數據庫服務器通訊，其核心功能是分表分庫，即將一個大表水平分割爲N個小表，存儲在後端MySQL服務器裏或者其餘數據庫裏。html
MyCat發展到目前的版本，已經不是一個單純的MySQL代理了，它的後端能夠支持MySQL、SQL Server、Oracle、DB二、PostgreSQL等主流數據庫，也支持MongoDB這種新型NoSQL方式的存儲。而在最終用戶看來，不管是哪一種存儲方式，在MyCat裏，都是一個傳統的數據庫表，支持標準的SQL語句進行數據的操做，這樣一來，對前端業務系統來講，能夠大幅下降開發難度，提高開發速度。前端
1.2
- 一個完全開源的，面向企業應用開發的大數據庫集羣
- 支持事務、ACID
- 一個能夠視爲MySQL集羣的企業級數據庫，用來替代昂貴的Oracle集羣
- 一個融合內存緩存技術、NoSQL技術、HDFS大數據的新型SQL Server
- 結合傳統數據庫和新型分佈式數據倉庫
- 數據庫中間件產品
1.3
MyCat是一個開源的分佈式數據庫系統，可是因爲真正的數據庫須要存儲引擎，而Mycat並無存儲引擎，因此並非徹底意義的分佈式數據庫系統。node
Mycat是一個數據庫中間件，也能夠理解爲是數據庫代理。在架構體系中是位於數據庫和應用層之間的一個組件，而且對於應用層是透明的，即數據庫感覺不到mycat的存在，認爲是直接連的mysql數據庫（其實是鏈接的mycat，mycat實現了mysql的原生協議）mysql
mycat的三大功能：分表、讀寫分離、主從切換git
2、爲何要使用MyCat
2.1
例如操做系統是對各種計算機硬件的抽象。那麼咱們何時須要抽象？假如只有一種硬件的時候，咱們須要開發一個操做系統嗎？再好比一個項目只須要一我的完成的時候不須要leader，可是當須要幾十我的完成時，就應該由一個管理者，發揮溝通協調等做用，而這個管理者對於他的上層來講就是對項目組的抽象。github
一樣的，當咱們的應用只須要一臺數據庫服務器的時候咱們並不須要MyCat，而若是你須要分庫甚至分表，這時候應用要面對不少個數據庫的時候，這個時候就須要對數據庫層作一個抽象，來管理這些數據庫，而最上面的應用只須要面對一個數據庫層的抽象或者說數據庫中間件就行了，這就是MyCat的核心做用。web
因此能夠這樣理解：數據庫是對底層存儲文件的抽象，而MyCat是對數據庫的抽象。算法
2.2
客戶端拆分：sql
每一個應用程序模塊中配置管理本身須要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合；mongodb
優勢：相對簡單，無性能損耗
缺點：不夠通用，數據庫鏈接的處理複雜，對業務不夠透明，處理複雜
中間件模式：
經過中間代理層來統一管理全部的數據源，後端數據庫集羣對前端應用程序透明
優勢：通用，對應用透明，改造少
缺點：實現難度大，有二次轉發性能損失，單機損失30%左右
3、MyCat的關鍵特性
- 支持SQL92標準
- 支持MySQL、Oracle、DB二、SQL Server、PostgreSQL等DB的常見SQL語法
- 遵照Mysql原生協議，跨語言、跨平臺、跨數據庫的通用中間件代理
- 基於心跳的自動故障切換，支持讀寫分離，支持MySQL主從，以及galera cluster集羣
- 支持Galera for MySQL集羣，Percona Cluster或者MariaDB cluster
- 基於Nio實現，有效管理線程，解決高併發問題
- 支持數據的多片自動路由與聚合，支持sum、count、max等經常使用的聚合函數，支持跨庫分頁
- 支持單庫內部任意join，支持跨庫2表join，甚至基於caltlet的多表join
- 支持經過全局表，ER關係的分片策略，實現了高效的多表join查詢
- 支持多租戶方案
- 支持分佈式事務（弱xa）
- 支持XA分佈式事務
- 支持全局序列號，解決分佈式下的主鍵生成問題。
- 分片規則豐富，插件化開發，易於擴展
- 強大的web，命令行監控
- 支持前端做爲MySQL通用代理，後端JDBC方式支持Oracle、DB二、SQL Server、mongodb
- 支持密碼加密
- 支持服務降級
- 支持IP白名單
- 支持SQL黑名單、sql注入攻擊攔截
- 支持prepare預編譯指令
- 支持非堆內存（Direct Memory）聚合計算
- 支持PostgreSQL的native協議
- 支持mysql和oracle存儲過程，out參數、多結果返回
- 支持zookeeper協調主從切換、zk序列、配置zk化
- 支持庫內分表
- 集羣基於zookeeper管理，在線升級、擴容、智能優化，大數據處理
4、MyCat原理
MyCat就是一個數據庫中間件，數據庫的代理，它屏蔽了物理數據庫，應用鏈接MyCat，而後MyCat再鏈接物理數據庫。
MyCat的原理中最重要的一個動詞是「攔截」，它攔截了用戶發送過來的SQL語句，首先對SQL語句作了一些特定的分析：如分片分析、路由分析、讀寫分離分析、緩存分析等，而後將此SQL發日後端的真實數據庫，並將返回的結果作適當的處理，最終再返回給用戶。
1.application提交sql後，通過sql解析，優化，路由，解析爲對應的sql指令，交給具體的sql機器執行
2.各節點的計算結果進行結果集合並
3.manager負責master的集羣管理，內存管理等
5、MyCat的核心技術
5.1
數據庫分片指：經過某種特定的條件，將咱們存放在一個數據庫中的數據分散存放在不一樣的多個數據庫（主機）中，這樣來達到分散單臺設備的負載，根據切片規則，能夠分爲如下兩種切片模式
MyCat經過定義表的分片規則來實現分片，每一個表格能夠捆綁一個分片規則，每一個分片規則指定一個分片字段並綁定一個函數，來實現動態分片算法。
1.Schema：邏輯庫，與MySQL中的Datebase（數據庫）對應，一個邏輯庫中定義了所包括的Table。
2.Table：邏輯表，即物理數據庫中存儲的某一張表，與傳統數據庫不一樣，這裏的表格須要聲明其所存儲的邏輯數據節點DataNode。在此能夠指定表的分片規則。
3.DataNode：MyCat的邏輯數據節點，是存放table的具體物理節點，也稱之爲分片節點，經過DataSource來關聯到後端某個具體數據庫上。
4.DataSource：定義某個物理庫的訪問地址，用於捆綁到Datanode上。
5.分片規則：前面獎勵數據切分，一個大表分紅若干個分片表，就須要必定的規則，這樣按照某種業務規則把數據分到某個分片的規則就是分片規則，數據切分選擇合適的分片規則很是重要，將極大的避免後續數據處理的難
5.2
數據切分：簡單來講，就是指經過某種特定的條件，按照某個維度，將咱們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面以達到分散單庫（主機）負載的效果。
切分模式：
垂直切分--單庫性能瓶頸
一個數據庫由不少表的構成，每一個表對應着不一樣的業務，垂直切分是指按照業務將表進行分類，分佈到不一樣的數據庫上面，這樣也就將數據或者說壓力分擔到不一樣的庫上面
優勢：拆分後業務清晰，拆分規則明確；
系統之間整合或擴展容易；
數據維護簡單
缺點：部分業務表沒法join，只能經過接口方式解決，提升了系統複雜度；
受每種業務不一樣的限制存在單庫性能瓶頸，不易數據擴展跟性能提升；
事務處理複雜
水平切分：按照某個字段的某種規則來分散到多個庫之中，每一個表包含一部分數據。簡單來講，咱們能夠將數據的水平切分理解爲是按照數據行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其餘的數據庫中，主要有分表、分庫兩種模式
優勢：不存在單庫大數據，高併發的性能瓶頸；
對應用透明，應用端改造較少；
按照合理拆分規則拆分；
join操做基本避免跨庫，提升了系統的穩定性跟負載能力
缺點：拆分規則難以抽象；
分片事務一致性難以解決；
數據屢次擴展難度跟維護量極大
跨庫join性能較差
5.3
5.3.1分表
對於數據量很大的表（千萬級以上），mysql性能會有很大降低，所以儘可能控制在每張表的大小在百萬級別。對於數據量很大的一張表，能夠考慮將這些記錄按照必定的規則放到不一樣的數據庫裏面。這樣每一個數據庫的數據量不是太大，性能也不會有太大損失。
mycat分表的實現：首先在mycat的scheme.xml中配置邏輯表，而且在配置中說明此表在哪幾個物理庫上。此邏輯表的名字與真實數據庫中的名字一致！而後須要配置分片規則，即按照什麼邏輯分庫！
5.3.2讀寫分離
通過統計發現，對數據庫的大量操做是讀操做，通常佔到全部操做70%以上。因此作讀寫分離仍是頗有必要的，若是不作讀寫分離，那麼從庫也是一種很大的浪費。
5.3.3 MyCat基本元素
1.邏輯庫：MyCat中存在，對應用來講至關於mysql數據庫，後端困難對應了多個物理數據庫，邏輯庫中不保存數據
2.邏輯表：邏輯庫中的表，對應用來講至關於mysql的數據表，後端困難對應多個物流數據庫中的表，也不保存數據
邏輯表分類
1）分片表：進行了水平切分的表，具備相同表結構但存儲在不一樣數據庫中的表，全部分片表的集合纔是一張完整的表
分片表，是指那些有很大數據，須要切分到多個數據庫的表，這樣每一個分片都有一部分數據，全部分片構成了完整的數據。
<table name="t_goods" primaryKey="vid" autolncrement="true" dataNode="dn1,dn2" rule="rule1" />
2）非分片表：垂直切分的表，一個數據庫中就保存了一張完整的表
一個數據庫中並非全部的表都很大，某些表是能夠不用進行切分的，非分片是相對分片表來講的，就是那些不須要進行數據切分的表。
<table name="t_node" primaryKey="vid" autolncrement="true" dataNode="dn1" />
3）全局表：全部分片數據庫中都存在的表，如字典表，數據量少，由MyCat來進行維護更新
意義：例如國家列表，存量小（100w如下的數據表），須要常常和其餘表進行join，因此能夠用空間換取時間，防止跨庫訪問，則全部分片上面都放入全局表。
一個真實的業務系統中，每每存在大量的相似字典表的表，這些表基本上不多變更。
問題：業務表每每須要和字典表join查詢，當業務表由於規模而進行分片之後，業務表與字典表之間的關聯跨庫了。
解決：MyCat中經過表冗餘來解決這類表的join，即它的定義中指定的dataNode上都有一份該表的拷貝（將字典表或者符合字典表特性的表定義爲全局表）
<table name="company" primaryKey="ID" type="global" dataNode="dn1,dn2,dn3">
4）ER關係表：MyCat獨有，子表依賴父表，保證在同一個數據庫中
MyCat中的ER表是基於E-R關係的數據分片策略，子表的記錄與所關聯的父表記錄存放在同一個數據分片上，保證數據join不會跨庫操做。
ER分片是解決跨分片數據join的一種很好的思路，也是數據切分規劃的一條重要規則。
<table name="customer" primaryKey="ID" dataNode="dn1,dn2" rule="sharding-by-intfile"> <childTable name="orders" primaryKey="ID" joinKey="customer_id" parentKey="id"> <childTable name="order_items" joinKey="order_id" parentKey="id"/> </childTable> </table>
6、什麼是dble
dble是基於mysql的高可擴展性的分佈式中間件，存在如下幾個優點特性：
- 數據水平拆分：隨着業務的發展，您可使用dble來替換原始的單個MySQL實例。
- 兼容Mysql：與MySQL協議兼容，在大多數狀況下，您能夠用它替換MySQL來爲你的應用程序提供新的存儲，而無需更改任何代碼。
- 高可用性：dble服務器能夠用做集羣，業務不會受到單節點故障的影響。
- SQL支持：支持SQL 92標準和MySQL方言。咱們支持複雜的SQL查詢，如group by，order by，distinct，join，union，sub-query等等。
- 複雜查詢優化：優化複雜查詢，包括但不限於全局錶鏈接分片表，ER關係表，子查詢，簡化選擇項等。
- 分佈式事務支持：使用兩階段提交的分佈式事務。您能夠爲了性能選擇普通模式或者爲了數據安全採用XA模式。固然，XA模式依賴於MySQL-5.7的XA Transcation，MySQL節點的高可用性和數據的可靠性。
dble是基於開源項目MyCat的，但取消了多其餘數據庫的支持，專一於MySQL，對兼容性、複雜查詢和分佈式事務的行爲進行了深刻的改進/優化。修復了MyCat的一些bug。
dble內部架構：
7、dble的優點
7.1缺陷修復
目前MyCat社區不活躍，再也不追鍾MyCat的bug
- 因爲堆外內存的使用不當，致使高併發操做時堆同一片內存可能發生「double free」，從而形成JVM異常，服務崩潰。#4
- XA事務漏洞：包亂序致使客戶端崩潰。#21
- where關鍵字寫錯時，會忽視後面的where條件，會獲得錯誤的結果，好比select * from customer wher id=1；#126
- 對於一些隱式分佈式事務，例如insert into table values（節點1），（節點2）：原生MyCat直接下發，這樣當某個節點錯誤時，會形成該SQL執行了一部分
- 權限黑名單針對同一條sql只在第一次生效。#92
- 聚合/排序的支持度很是有限，並且在不少場景下還存在結果不正確、執行異常等問題。#43，#31，#44
- 針對between A and B語法，hash拆分算法計算出來的範圍有誤。#23
- 開啓全局表一致性檢查時，對全局表處理存在諸多問題，例如不能alert table、insert……on duplicate……時不更新時間戳、update……in（）報錯等。#24，#25，#26，#5
- 多值插入時，全局序列生成重複值。#1
- ER表在一個事務內被隔離，不能正確插入子表數據。#13
- sharding-join結果集不正確。#17
詳情及其餘修正：修復列表
7.2實現改進
- 對某些標準SQL語法支持不夠好的方面作了改進，例如對create table if not exists..、alter table add/drop [primary] key...等語法的支持。
- 對總體內部IO結構進行了大幅的改造和調優。
- 禁止普通用戶鏈接管理端口進行管理操做，加強安全性。#56
- 對全局序列作了以下改進：
· 刪去無工程意義的本地文件方式。
· 改進數據庫方式、ZK方式，使獲取的序列號更加準確。
· 修復了數據庫方式全局序列中線程安全的問題。#489
· 移除自定義語法限制：全局序列值不能顯式指定
@ 原來：insert into table(id,name) values( 10059,'test');
@ 如今1：insert into table(name) values('test');
@ 如今2：insert into talbe values('test');
@ 注意時間戳方式須要該字段是bigint。
- 改進對ER表的支持，智能處理鏈接隔離，解決同一事物內不能夠同時寫入父子表的問題，並優化ER表的執行計劃。
- 系統經過智能判斷，對於一些沒有顯示配置但實際符合ER條件的表視做ER表一樣處理。
- 在中間件內進行智能解析與判斷，使用正確的schema，替換有缺陷的checkSQLschema參數。
- conf/index_to_charset.properties的內容固化到代碼。
- 對於前端按照用戶限制鏈接數、限制總鏈接數。
- 改進本來的SQL統計，增長UPDATE/DELETE/INSERT
7.3功能加強
- 提供了更強大的查詢解析樹，取代ShareJoin，使跨節點的語法支持度更廣（join，union，subquery），執行效率更高，同時聚合/排序也有了較大改進。
- 提供科學的元數據管理機制，更好的支持show、desc等管理命令，支持部指定columns的insert語句。#7
- 元數據自動檢查：
· 啓動時對元數據進行一致性檢查。
· 配置定時任務，對元數據進行一致性檢查。
- 提供更詳實的執行計劃，更準確的反映SQL語句的執行過程。
- set系統變量語句的改進。
- set charset/names語句的支持。
- 分佈式事務：XA實現方式的異常處理的改進。
- 大小寫敏感支持。
- 支持DUAL。
- 支持單詞請求多語句（部分客戶端有使用，C和C++常見）。
- 不斷豐富的路由規則優化和條件優化。
- 升級Druid，跟進最新的解析器。
- 升級fastjson，避免安全問題。
- 智能判斷reload鏈接變動，熱更新鏈接池。
- 對MySQL協議及GUI工具/Driver更友好的支持。
- 增長更多的管理端命令，知足更多運維須要。
- 緩存支持使用RocksDB。
- 增長慢查詢日誌功能，兼容mysqldumpslow和pt-query-digest。
- Trace功能，用於分析單條查詢的性能瓶頸。
- 大小寫明哥依賴於後端MySQL。
- 支持Prepared SQL Statement Syntax。
- 支持如下子查詢：
· The Subquery as Scalar Operand.#子查詢做爲標量操做數
` Comparisons Using Subqueries.#比較使用子查詢
· Subqueries with ANY,IN or SOME
` Subqueries with ALL
` Subqueries with EXISTS or NOT EXISTS
` Derived Tables(Subqueries in the FROM Clause)#派生表(FROM子句中的子查詢)
- 支持dble層面的View。
- 支持MySQL8.0默認登陸驗證插件。
- 提供自定義告警接口。
- 支持自定義拆分算法。
- 支持自增列能夠設置爲非主鍵列。
- 能夠觀察執行中的DDL。
- 提供配置預檢查功能。
- 流量暫停和恢復功能。
7.4功能裁減
- 僅保留枚舉、範圍、HASH、日期等分片算法，對這幾個算法進行了可用性的改進，使之更加貼合實際應用，項目須要時能夠按需提供。
- 移除異構數據庫支持。
- 禁止某些不支持的功能，這些功能客戶端調用時不會報錯，但結果並不是用戶想要的結果，例如無效的set語句。
- 移除目前實現由問題的第一結點庫內分表模式。
- 移除writeType參數，等效於原來writeType=1。
- 移除handleDistributedTransactions選項，直接支持分佈式事務。
8、MyCat與DBLE比較
8.1Nio線程處理
Nio處理器（處理線程）內部爲掛載不定數量個鏈接，而且循環響應每一個鏈接的請求。
在數據處理和數據接收進行線程分割以後（dble 2.18.02），使得dble能夠併發響應掛載在同一個NIO鏈接器（同一個processor線程）上的請求。
eg：剛好咱們存在場景鏈接1，2同時有請求過來，舊版本須要循環處理鏈接1，2的任務，在鏈接1的任務處理完成以前，鏈接2的任務沒法進行處理。
在新的IO結構中，鏈接1的數據被接收完畢周，NIO線程舊能夠接收鏈接2的數據，而且此時鏈接1的數據以及在executor線程池進行處理中，鏈接1，2之間的任務執行變成並行。
9、參考資料
https://blog.csdn.net/nxw_tsp/article/details/56277430
https://blog.csdn.net/sinat_27933301/article/details/81292276
https://www.jianshu.com/p/c6e29d724fca
https://www.cnblogs.com/wenbronk/p/7819224.html
https://www.jianshu.com/p/f02a48226222
https://www.jianshu.com/p/87c7a5abd74a
《dble-manual.pdf》