一轮锥、Mycat開源宣言
2013 年阿里的 Cobar 在社區(qū)使用過程中發(fā)現(xiàn)存在一些比較嚴(yán)重的問題淑翼，及其使用限制。Mycat 是基于開源 Cobar 演變而來抽莱，我們對 cobar 的代碼進(jìn)行了徹底的重構(gòu)桐筏，使用 NIO 重構(gòu)了網(wǎng)絡(luò)模塊纸型，并且優(yōu)化了 Buffer 內(nèi)核，增強(qiáng)了聚合梅忌，Join 等基本特性狰腌，同時(shí)兼容絕大多數(shù)數(shù)據(jù)庫成為通用的數(shù)據(jù)庫中間件。1.4 版本以后 完全的脫離基本 cobar 內(nèi)核牧氮，結(jié)合 Mycat 集群管理琼腔、自動(dòng)擴(kuò)容、智能優(yōu)化踱葛，成為高性能的中間件丹莲。
二、數(shù)據(jù)庫切分概述
2.1 OLTP和OLAP
在互聯(lián)網(wǎng)時(shí)代剖毯，海量數(shù)據(jù)的存儲(chǔ)與訪問成為系統(tǒng)設(shè)計(jì)與使用的瓶頸問題圾笨，對于海量數(shù)據(jù)處理教馆，按照使用場景逊谋，
主要分為兩種類型：聯(lián)機(jī)事務(wù)處理（OLTP）和聯(lián)機(jī)分析處理（OLAP）。
聯(lián)機(jī)事務(wù)處理（OLTP）也稱為面向交易的處理系統(tǒng)土铺，其基本特征是原始數(shù)據(jù)可以立即傳送到計(jì)算中心進(jìn)行處
理胶滋，并在很短的時(shí)間內(nèi)給出處理結(jié)果。
聯(lián)機(jī)分析處理（OLAP）是指通過多維的方式對數(shù)據(jù)進(jìn)行分析悲敷、查詢和報(bào)表究恤，可以同數(shù)據(jù)挖掘工具、統(tǒng)計(jì)分析
工具配合使用后德，增強(qiáng)決策分析功能部宿。
對于兩者的主要區(qū)別可以用下表來說明：
2.2 關(guān)系型數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫
針對上面兩類系統(tǒng)有多種技術(shù)實(shí)現(xiàn)方案，存儲(chǔ)部分的數(shù)據(jù)庫主要分為兩大類：關(guān)系型數(shù)據(jù)庫與 NoSQL 數(shù)據(jù)
庫。
關(guān)系型數(shù)據(jù)庫理张，是建立在關(guān)系模型基礎(chǔ)上的數(shù)據(jù)庫赫蛇，其借助于集合代數(shù)等數(shù)學(xué)概念和方法來處理數(shù)據(jù)庫中的
數(shù)據(jù)。主流的 oracle雾叭、DB2悟耘、MS SQL Server 和 mysql 都屬于這類傳統(tǒng)數(shù)據(jù)庫。
NoSQL 數(shù)據(jù)庫织狐，全稱為 Not Only SQL暂幼，意思就是適用關(guān)系型數(shù)據(jù)庫的時(shí)候就使用關(guān)系型數(shù)據(jù)庫，不適用的
時(shí)候也沒有必要非使用關(guān)系型數(shù)據(jù)庫不可移迫，可以考慮使用更加合適的數(shù)據(jù)存儲(chǔ)旺嬉。主要分為臨時(shí)性鍵值存儲(chǔ)
（memcached、Redis）厨埋、永久性鍵值存儲(chǔ)（ROMA鹰服、Redis）、面向文檔的數(shù)據(jù)庫（MongoDB揽咕、CouchDB）悲酷、面向列的數(shù)據(jù)庫（Cassandra、HBase）亲善，每種 NoSQL 都有其特有的使用場景及優(yōu)點(diǎn)设易。
Oracle，mysql 等傳統(tǒng)的關(guān)系數(shù)據(jù)庫非常成熟并且已大規(guī)模商用蛹头，為什么還要用 NoSQL 數(shù)據(jù)庫呢顿肺？主要是
由于隨著互聯(lián)網(wǎng)發(fā)展，數(shù)據(jù)量越來越大渣蜗，對性能要求越來越高屠尊，傳統(tǒng)數(shù)據(jù)庫存在著先天性的缺陷，即單機(jī)（單庫）性能瓶頸耕拷，并且擴(kuò)展困難讼昆。這樣既有單機(jī)單庫瓶頸，卻又?jǐn)U展困難骚烧，自然無法滿足日益增長的海量數(shù)據(jù)存儲(chǔ)及其性能要求浸赫，所以才會(huì)出現(xiàn)了各種不同的 NoSQL 產(chǎn)品，NoSQL 根本性的優(yōu)勢在于在云計(jì)算時(shí)代赃绊，簡單既峡、易于大規(guī)模分布式擴(kuò)展，并且讀寫性能非常高碧查。
下面分析下兩者的特點(diǎn)运敢，及優(yōu)缺點(diǎn)：
雖然在云計(jì)算時(shí)代，傳統(tǒng)數(shù)據(jù)庫存在著先天性的弊端，但是 NoSQL 數(shù)據(jù)庫又無法將其替代传惠，NoSQL 只能作
為傳統(tǒng)數(shù)據(jù)的補(bǔ)充而不能將其替代肤视，所以規(guī)避傳統(tǒng)數(shù)據(jù)庫的缺點(diǎn)是目前大數(shù)據(jù)時(shí)代必須要解決的問題。如果傳統(tǒng)數(shù)據(jù)易于擴(kuò)展涉枫，可切分邢滑，就可以避免單機(jī)（單庫）的性能缺陷，但是由于目前開源或者商用的傳統(tǒng)數(shù)據(jù)庫基本不支持大規(guī)模自動(dòng)擴(kuò)展愿汰，所以就需要借助第三方來做處理困后。
2.3 何為數(shù)據(jù)切分？
簡單來說衬廷，就是指通過某種特定的條件摇予，將我們存放在同一個(gè)數(shù)據(jù)庫中的數(shù)據(jù)分散存放到多個(gè)數(shù)據(jù)庫（主機(jī)）上面，以達(dá)到分散單臺(tái)設(shè)備負(fù)載的效果吗跋。
數(shù)據(jù)的切分（Sharding）根據(jù)其切分規(guī)則的類型侧戴，可以分為兩種切分模式。一種是按照不同的表（或者
Schema）來切分到不同的數(shù)據(jù)庫（主機(jī)）之上跌宛，這種切可以稱之為數(shù)據(jù)的垂直（縱向）切分酗宋；另外一種則是根據(jù)表中的數(shù)據(jù)的邏輯關(guān)系，將同一個(gè)表中的數(shù)據(jù)按照某種條件拆分到多臺(tái)數(shù)據(jù)庫（主機(jī)）上面疆拘，這種切分稱之為數(shù)據(jù)的水平（橫向）切分蜕猫。
垂直切分的最大特點(diǎn)就是規(guī)則簡單，實(shí)施也更為方便哎迄，尤其適合各業(yè)務(wù)之間的耦合度非常低回右，相互影響很小，業(yè)務(wù)邏輯非常清晰的系統(tǒng)漱挚。在這種系統(tǒng)中翔烁，可以很容易做到將不同業(yè)務(wù)模塊所使用的表分拆到不同的數(shù)據(jù)庫中。根據(jù)不同的表來進(jìn)行拆分旨涝，對應(yīng)用程序的影響也更小蹬屹，拆分規(guī)則也會(huì)比較簡單清晰。
水平切分于垂直切分相比颊糜，相對來說稍微復(fù)雜一些哩治。因?yàn)橐獙⑼粋€(gè)表中的不同數(shù)據(jù)拆分到不同的數(shù)據(jù)庫中，對于應(yīng)用程序來說衬鱼，拆分規(guī)則本身就較根據(jù)表名來拆分更為復(fù)雜，后期的數(shù)據(jù)維護(hù)也會(huì)更為復(fù)雜一些憔杨。
2.4 垂直切分
一個(gè)數(shù)據(jù)庫由很多表的構(gòu)成鸟赫，每個(gè)表對應(yīng)著不同的業(yè)務(wù)，垂直切分是指按照業(yè)務(wù)將表進(jìn)行分類，分布到不同
的數(shù)據(jù)庫上面抛蚤，這樣也就將數(shù)據(jù)或者說壓力分擔(dān)到不同的庫上面台谢，如下圖：
往往系統(tǒng)之有些表難以做到完全的獨(dú)立，存在各擴(kuò)庫 join 的情況岁经，對于這類的表朋沮，就需要去做平衡，
是數(shù)據(jù)庫讓步業(yè)務(wù)缀壤，共用一個(gè)數(shù)據(jù)源樊拓，還是分成多個(gè)庫，業(yè)務(wù)之間通過接口來做調(diào)用塘慕。在系統(tǒng)初期筋夏，數(shù)據(jù)量比較少，或者資源有限的情況下图呢，會(huì)選擇共用數(shù)據(jù)源条篷，但是當(dāng)數(shù)據(jù)發(fā)展到了一定的規(guī)模，負(fù)載很大的情況蛤织，就需要必須去做分割赴叹。
由于垂直切分是按照業(yè)務(wù)的分類將表分散到不同的庫，所以有些業(yè)務(wù)表會(huì)過于龐大指蚜，存在單庫讀寫與存儲(chǔ)瓶
頸稚瘾，所以就需要水平拆分來做解決。
2.5 水平切分
相對于垂直拆分姚炕，水平拆分不是將表做分類摊欠，而是按照某個(gè)字段的某種規(guī)則來分散到多個(gè)庫之中，每個(gè)表中
包含一部分?jǐn)?shù)據(jù)柱宦。簡單來說些椒，我們可以將數(shù)據(jù)的水平切分理解為是按照數(shù)據(jù)行的切分，就是將表中的某些行切分到一個(gè)數(shù)據(jù)庫掸刊，而另外的某些行又切分到其他的數(shù)據(jù)庫中免糕，如圖：
拆分?jǐn)?shù)據(jù)就需要定義分片規(guī)則。關(guān)系型數(shù)據(jù)庫是行列的二維模型忧侧，拆分的第一原則是找到拆分維度石窑。比如：
從會(huì)員的角度來分析，商戶訂單交易類系統(tǒng)中查詢會(huì)員某天某月某個(gè)訂單蚓炬，那么就需要按照會(huì)員結(jié)合日期來拆分松逊，不同的數(shù)據(jù)按照會(huì)員 ID 做分組，這樣所有的數(shù)據(jù)查詢 join 都會(huì)在單庫內(nèi)解決肯夏；如果從商戶的角度來講经宏，要查詢某個(gè)商家某天所有的訂單數(shù)犀暑，就需要按照商戶 ID 做拆分；但是如果系統(tǒng)既想按會(huì)員拆分烁兰，又想按商家數(shù)據(jù)耐亏，則會(huì)有一定的困難。如何找到合適的分片規(guī)則需要綜合考慮衡量沪斟。
幾種典型的分片規(guī)則包括：
- 按照用戶 ID 求模广辰，將數(shù)據(jù)分散到不同的數(shù)據(jù)庫，具有相同數(shù)據(jù)用戶的數(shù)據(jù)都被分散到一個(gè)庫中主之；
- 按照日期择吊，將不同月甚至日的數(shù)據(jù)分散到不同的庫中；
- 按照某個(gè)特定的字段求摸杀餐，或者根據(jù)特定范圍段分散到不同的庫中干发。
三、Mycat 概述
3.1 功能介紹
Mycat 是什么史翘？從定義和分類來看枉长，它是一個(gè)開源的分布式數(shù)據(jù)庫系統(tǒng)，是一個(gè)實(shí)現(xiàn)了 MySQL 協(xié)議的Server琼讽，前端用戶可以把它看作是一個(gè)數(shù)據(jù)庫代理必峰，用 MySQL 客戶端工具和命令行訪問，而其后端可以用MySQL 原生（Native）協(xié)議與多個(gè) MySQL 服務(wù)器通信钻蹬，也可以用 JDBC 協(xié)議與大多數(shù)主流數(shù)據(jù)庫服務(wù)器通信吼蚁，其核心功能是分表分庫。
對于 DBA 來說问欠，可以這么理解 Mycat：
Mycat 就是 MySQL Server肝匆，而 Mycat 后面連接的 MySQL Server就好象是 MySQL 的存儲(chǔ)引擎,如InnoDB，MyISAM 等顺献，因此旗国，Mycat 本身并不存儲(chǔ)數(shù)據(jù)，數(shù)據(jù)是在后端的 MySQL 上存儲(chǔ)的注整，因此數(shù)據(jù)可靠性以及事務(wù)等都是 MySQL 保證的能曾，簡單的說，Mycat 就是MySQL 最佳伴侶肿轨，它在一定程度上讓 MySQL 擁有了能跟 Oracle PK 的能力寿冕。
對于軟件工程師來說，可以這么理解 Mycat：
Mycat 就是一個(gè)近似等于 MySQL 的數(shù)據(jù)庫服務(wù)器椒袍，你可以用連接 MySQL 的方式去連接 Mycat（除了端口不同驼唱，默認(rèn)的 Mycat 端口是 8066 而非 MySQL 的 3306，因此需要在連接字符串上增加端口信息）槐沼，大多數(shù)情況下曙蒸，可以用你熟悉的對象映射框架使用 Mycat捌治，但建議對于分片表岗钩，盡量使用基礎(chǔ)的 SQL 語句纽窟，因?yàn)檫@樣能達(dá)到最佳性能，特別是幾千萬甚至幾百億條記錄的情況下兼吓。
對于架構(gòu)師來說臂港，可以這么理解 Mycat：
Mycat 是一個(gè)強(qiáng)大的數(shù)據(jù)庫中間件，不僅僅可以用作讀寫分離视搏、以及分表分庫审孽、容災(zāi)備份，而且可以用于多租戶應(yīng)用開發(fā)浑娜、云平臺(tái)基礎(chǔ)設(shè)施佑力、讓你的架構(gòu)具備很強(qiáng)的適應(yīng)性和靈活性，借助于即將發(fā)布Mycat 智能優(yōu)化模塊筋遭，系統(tǒng)的數(shù)據(jù)訪問瓶頸和熱點(diǎn)一目了然打颤，根據(jù)這些統(tǒng)計(jì)分析數(shù)據(jù)，你可以自動(dòng)或手工調(diào)整后端存儲(chǔ)漓滔，將不同的表映射到不同存儲(chǔ)引擎上编饺，而整個(gè)應(yīng)用的代碼一行也不用改變。
3.2 Mycat 原理
Mycat 的原理中最重要的一個(gè)動(dòng)詞是“攔截”响驴，它攔截了用戶發(fā)送過來的 SQL 語句透且，首先對 SQL 語句做了一些特定的分析：如分片分析、路由分析豁鲤、讀寫分離分析秽誊、緩存分析等，然后將此 SQL 發(fā)往后端的真實(shí)數(shù)據(jù)庫琳骡，并將返回的結(jié)果做適當(dāng)?shù)奶幚砉郏罱K再返回給用戶。
當(dāng) Mycat 收到一個(gè) SQL 時(shí)日熬，會(huì)先解析這個(gè) SQL棍厌，查找涉及到的表，然后看此表的定義竖席，如果有分片規(guī)則耘纱，則獲取到 SQL 里分片字段的值，并匹配分片函數(shù)毕荐，得到該 SQL 對應(yīng)的分片列表束析，然后將 SQL 發(fā)往這些分片去執(zhí)行，最后收集和處理所有分片返回的結(jié)果數(shù)據(jù)憎亚，并輸出到客戶端员寇。以 select * from Orders where prov=?語句為例弄慰，查到 prov=wuhan，按照分片函數(shù)蝶锋，wuhan 返回 dn1陆爽，于是 SQL 就發(fā)給了 MySQL1，去取 DB1 上的查詢結(jié)果扳缕，并返回給用戶慌闭。
如果上述 SQL 改為 select * from Orders where prov in (‘wuhan’,‘beijing’)，那么躯舔，SQL 就會(huì)發(fā)給MySQL1 與 MySQL2 去執(zhí)行驴剔，然后結(jié)果集合并后輸出給用戶。但通常業(yè)務(wù)中我們的 SQL 會(huì)有 Order By 以及Limit 翻頁語法粥庄，此時(shí)就涉及到結(jié)果集在 Mycat 端的二次處理丧失，這部分的代碼也比較復(fù)雜，而最復(fù)雜的則屬兩個(gè)表的 Jion 問題惜互，為此布讹，Mycat 提出了創(chuàng)新性的 ER 分片、全局表载佳、HBT（Human Brain Tech)人工智能的 Catlet炒事、以及結(jié)合 Storm/Spark 引擎等十八般武藝的解決辦法，從而成為目前業(yè)界最強(qiáng)大的方案蔫慧，這就是開源的力量挠乳。
3.3 應(yīng)用場景
Mycat 發(fā)展到現(xiàn)在，適用的場景已經(jīng)很豐富姑躲，而且不斷有新用戶給出新的創(chuàng)新性的方案睡扬，以下是幾個(gè)典型的應(yīng)用場景：
- 1.單純的讀寫分離，此時(shí)配置最為簡單黍析，支持讀寫分離卖怜，主從切換；
- 2.分表分庫阐枣，對于超過 1000 萬的表進(jìn)行分片马靠，最大支持 1000 億的單表分片；
- 3.多租戶應(yīng)用蔼两，每個(gè)應(yīng)用一個(gè)庫甩鳄，但應(yīng)用程序只連接 Mycat，從而不改造程序本身额划，實(shí)現(xiàn)多租戶化妙啃；
- 4.報(bào)表系統(tǒng)，借助于 Mycat 的分表能力俊戳，處理大規(guī)模報(bào)表的統(tǒng)計(jì)揖赴；
- 5.替代 Hbase馆匿，分析大數(shù)據(jù)；
- 6.作為海量數(shù)據(jù)實(shí)時(shí)查詢的一種簡單有效方案燥滑，比如 100 億條頻繁查詢的記錄需要在 3 秒內(nèi)查詢出來結(jié)果渐北，除了基于主鍵的查詢，還可能存在范圍查詢或其他屬性查詢突倍，此時(shí) Mycat 可能是最簡單有效的選擇腔稀。
四盆昙、Mycat 中的概念
4.1 數(shù)據(jù)庫中間件
前面講了 Mycat 是一個(gè)開源的分布式數(shù)據(jù)庫系統(tǒng)羽历，但是由于真正的數(shù)據(jù)庫需要存儲(chǔ)引擎，而 Mycat 并沒有
存儲(chǔ)引擎淡喜，所以并不是完全意義的分布式數(shù)據(jù)庫系統(tǒng)秕磷。
那么 Mycat 是什么？Mycat 是數(shù)據(jù)庫中間件炼团，就是介于數(shù)據(jù)庫與應(yīng)用之間澎嚣，進(jìn)行數(shù)據(jù)處理與交互的中間服務(wù)。由于前面講的對數(shù)據(jù)進(jìn)行分片處理之后瘟芝，從原有的一個(gè)庫易桃，被切分為多個(gè)分片數(shù)據(jù)庫，所有的分片數(shù)據(jù)庫集群構(gòu)成了整個(gè)完整的數(shù)據(jù)庫存儲(chǔ)锌俱。
如上圖所表示晤郑，數(shù)據(jù)被分到多個(gè)分片數(shù)據(jù)庫后，應(yīng)用如果需要讀取數(shù)據(jù)贸宏，就要需要處理多個(gè)數(shù)據(jù)源的數(shù)據(jù)造寝。如果沒有數(shù)據(jù)庫中間件，那么應(yīng)用將直接面對分片集群吭练，數(shù)據(jù)源切換诫龙、事務(wù)處理、數(shù)據(jù)聚合都需要應(yīng)用直接處理鲫咽，原本該是專注于業(yè)務(wù)的應(yīng)用签赃，將會(huì)花大量的工作來處理分片后的問題，最重要的是每個(gè)應(yīng)用處理將是完全的重復(fù)造輪子分尸。所以有了數(shù)據(jù)庫中間件锦聊，應(yīng)用只需要集中與業(yè)務(wù)處理，大量的通用的數(shù)據(jù)聚合寓落，事務(wù)括丁，數(shù)據(jù)源切換都由中間件來處理，中間件的性能與處理能力將直接決定應(yīng)用的讀寫性能伶选，所以一款好的數(shù)據(jù)庫中間件至關(guān)重要史飞。
4.2 邏輯庫(schema)
通常對實(shí)際應(yīng)用來說尖昏，并不需要知道中間件的存在，業(yè)務(wù)開發(fā)人員只需要知道數(shù)據(jù)庫的概念构资，所以數(shù)據(jù)庫中間件可以被看做是一個(gè)或多個(gè)數(shù)據(jù)庫集群構(gòu)成的邏輯庫抽诉。在云計(jì)算時(shí)代，數(shù)據(jù)庫中間件可以以多租戶的形式給一個(gè)或多個(gè)應(yīng)用提供服務(wù)吐绵，每個(gè)應(yīng)用訪問的可能是一個(gè)獨(dú)立或者是共享的物理庫迹淌，常見的如阿里云數(shù)據(jù)庫服務(wù)器 RDS。
4.3 邏輯表（table）
4.3.1 邏輯表
既然有邏輯庫己单，那么就會(huì)有邏輯表唉窃，分布式數(shù)據(jù)庫中，對應(yīng)用來說纹笼，讀寫數(shù)據(jù)的表就是邏輯表纹份。邏輯表，可
以是數(shù)據(jù)切分后廷痘，分布在一個(gè)或多個(gè)分片庫中蔓涧，也可以不做數(shù)據(jù)切分，不分片笋额，只有一個(gè)表構(gòu)成元暴。
4.3.2 分片表
分片表，是指那些原有的很大數(shù)據(jù)的表兄猩，需要切分到多個(gè)數(shù)據(jù)庫的表茉盏，這樣，每個(gè)分片都有一部分?jǐn)?shù)據(jù)厦滤，所
有分片構(gòu)成了完整的數(shù)據(jù)援岩。例如在 mycat 配置中的 t_node 就屬于分片表，數(shù)據(jù)按照規(guī)則被分到 dn1,dn2 兩個(gè)分片節(jié)點(diǎn)(dataNode)上掏导。
<table name="t_node" primaryKey="vid" autoIncrement="true" dataNode="dn1,dn2" rule="rule1" />
4.3.3 非分片表
一個(gè)數(shù)據(jù)庫中并不是所有的表都很大享怀，某些表是可以不用進(jìn)行切分的，非分片是相對分片表來說的趟咆，就是那
些不需要進(jìn)行數(shù)據(jù)切分的表添瓷。如下配置中 t_node，只存在于分片節(jié)點(diǎn)（dataNode）dn1 上值纱。
<table name="t_node" primaryKey="vid" autoIncrement="true" dataNode="dn1" />
4.3.4 ER 表
關(guān)系型數(shù)據(jù)庫是基于實(shí)體關(guān)系模型（Entity-Relationship Model)之上鳞贷，通過其描述了真實(shí)世界中事物與關(guān)系，Mycat 中的 ER 表即是來源于此虐唠。根據(jù)這一思路搀愧，提出了基于 E-R 關(guān)系的數(shù)據(jù)分片策略，子表的記錄與所關(guān)聯(lián)的父表記錄存放在同一個(gè)數(shù)據(jù)分片上，即子表依賴于父表咱筛，通過表分組（Table Group）保證數(shù)據(jù) Join 不會(huì)跨庫操作艇抠。表分組（Table Group）是解決跨分片數(shù)據(jù) join 的一種很好的思路笔宿，也是數(shù)據(jù)切分規(guī)劃的重要一條規(guī)則。
4.3.5 全局表
一個(gè)真實(shí)的業(yè)務(wù)系統(tǒng)中拍埠，往往存在大量的類似字典表的表督怜，這些表基本上很少變動(dòng)错蝴，字典表具有以下幾個(gè)特
性：
- 變動(dòng)不頻繁妓雾；
- 數(shù)據(jù)量總體變化不大炮温；
- 數(shù)據(jù)規(guī)模不大，很少有超過數(shù)十萬條記錄奕塑。
對于這類的表堂污，在分片的情況下，當(dāng)業(yè)務(wù)表因?yàn)橐?guī)模而進(jìn)行分片以后爵川，業(yè)務(wù)表與這些附屬的字典表之間的關(guān)聯(lián)敷鸦，就成了比較棘手的問題，所以 Mycat 中通過數(shù)據(jù)冗余來解決這類表的 join寝贡，即所有的分片都有一份數(shù)據(jù)的拷貝，所有將字典表或者符合字典表特性的一些表定義為全局表值依。數(shù)據(jù)冗余是解決跨分片數(shù)據(jù) join 的一種很好的思路圃泡，也是數(shù)據(jù)切分規(guī)劃的另外一條重要規(guī)則。
4.4 分片節(jié)點(diǎn)(dataNode)
數(shù)據(jù)切分后愿险，一個(gè)大表被分到不同的分片數(shù)據(jù)庫上面颇蜡，每個(gè)表分片所在的數(shù)據(jù)庫就是分片節(jié)點(diǎn)（dataNode）。
4.5 節(jié)點(diǎn)主機(jī)(dataHost)
數(shù)據(jù)切分后辆亏，每個(gè)分片節(jié)點(diǎn)（dataNode）不一定都會(huì)獨(dú)占一臺(tái)機(jī)器风秤，同一機(jī)器上面可以有多個(gè)分片數(shù)據(jù)庫，這樣一個(gè)或多個(gè)分片節(jié)點(diǎn)（dataNode）所在的機(jī)器就是節(jié)點(diǎn)主機(jī)（dataHost）,為了規(guī)避單節(jié)點(diǎn)主機(jī)并發(fā)數(shù)限制扮叨，盡量將讀寫壓力高的分片節(jié)點(diǎn)（dataNode）均衡的放在不同的節(jié)點(diǎn)主機(jī)（dataHost）缤弦。
4.6 分片規(guī)則(rule)
前面講了數(shù)據(jù)切分，一個(gè)大表被分成若干個(gè)分片表彻磁，就需要一定的規(guī)則碍沐，這樣按照某種業(yè)務(wù)規(guī)則把數(shù)據(jù)分到某個(gè)分片的規(guī)則就是分片規(guī)則，數(shù)據(jù)切分選擇合適的分片規(guī)則非常重要衷蜓，將極大的避免后續(xù)數(shù)據(jù)處理的難度累提。
4.7 全局序列號(hào)(sequence)
數(shù)據(jù)切分后，原有的關(guān)系數(shù)據(jù)庫中的主鍵約束在分布式條件下將無法使用磁浇，因此需要引入外部機(jī)制保證數(shù)據(jù)唯一性標(biāo)識(shí)斋陪，這種保證全局性的數(shù)據(jù)唯一標(biāo)識(shí)的機(jī)制就是全局序列號(hào)（sequence）。
4.8 多租戶
多租戶技術(shù)或稱多重租賃技術(shù)，是一種軟件架構(gòu)技術(shù)无虚，它是在探討與實(shí)現(xiàn)如何于多用戶的環(huán)境下共用相同的系統(tǒng)或程序組件鞍匾，并且仍可確保各用戶間數(shù)據(jù)的隔離性。在云計(jì)算時(shí)代骑科，多租戶技術(shù)在共用的數(shù)據(jù)中心以單一系統(tǒng)架構(gòu)與服務(wù)提供多數(shù)客戶端相同甚至可定制化的服務(wù)橡淑，并且仍然可以保障客戶的數(shù)據(jù)隔離。目前各種各樣的云計(jì)算服務(wù)就是這類技術(shù)范疇咆爽，例如阿里云數(shù)據(jù)庫服務(wù)（RDS）梁棠、阿里云服務(wù)器等等。多租戶在數(shù)據(jù)存儲(chǔ)上存在三種主要的方案斗埂，分別是：
4.8.1 獨(dú)立數(shù)據(jù)庫
這是第一種方案符糊，即一個(gè)租戶一個(gè)數(shù)據(jù)庫，這種方案的用戶數(shù)據(jù)隔離級(jí)別最高呛凶，安全性最好男娄，但成本也高。
優(yōu)點(diǎn)：
為不同的租戶提供獨(dú)立的數(shù)據(jù)庫漾稀，有助于簡化數(shù)據(jù)模型的擴(kuò)展設(shè)計(jì)模闲，滿足不同租戶的獨(dú)特需求；
如果出現(xiàn)故障崭捍，恢復(fù)數(shù)據(jù)比較簡單尸折。
缺點(diǎn)：
增大了數(shù)據(jù)庫的安裝數(shù)量，隨之帶來維護(hù)成本和購置成本的增加殷蛇。
這種方案與傳統(tǒng)的一個(gè)客戶实夹、一套數(shù)據(jù)、一套部署類似粒梦，差別只在于軟件統(tǒng)一部署在運(yùn)營商那里亮航。如果面對的是銀行、醫(yī)院等需要非常高數(shù)據(jù)隔離級(jí)別的租戶匀们，可以選擇這種模式缴淋，提高租用的定價(jià)。如果定價(jià)較低昼蛀，產(chǎn)品走低價(jià)路線宴猾，這種方案一般對運(yùn)營商來說是無法承受的。
4.8.2 共享數(shù)據(jù)庫叼旋，隔離數(shù)據(jù)架構(gòu)
這是第二種方案仇哆，即多個(gè)或所有租戶共享 Database，但是每個(gè)租戶一個(gè) Schema夫植。
優(yōu)點(diǎn)：
為安全性要求較高的租戶提供了一定程度的邏輯數(shù)據(jù)隔離讹剔，并不是完全隔離油讯；每個(gè)數(shù)據(jù)庫可以支持更多的租戶數(shù)量。
缺點(diǎn)：
如果出現(xiàn)故障延欠，數(shù)據(jù)恢復(fù)比較困難陌兑，因?yàn)榛謴?fù)數(shù)據(jù)庫將牽扯到其他租戶的數(shù)據(jù)；
如果需要跨租戶統(tǒng)計(jì)數(shù)據(jù)由捎，存在一定困難兔综。
4.8.3 共享數(shù)據(jù)庫，共享數(shù)據(jù)架構(gòu)
這是第三種方案狞玛，即租戶共享同一個(gè) Database软驰、同一個(gè) Schema，但在表中通過 TenantID 區(qū)分租戶的數(shù)據(jù)心肪。這是共享程度最高锭亏、隔離級(jí)別最低的模式。
優(yōu)點(diǎn)：
三種方案比較硬鞍，第三種方案的維護(hù)和購置成本最低慧瘤，允許每個(gè)數(shù)據(jù)庫支持的租戶數(shù)量最多。
缺點(diǎn)：
隔離級(jí)別最低固该，安全性最低锅减，需要在設(shè)計(jì)開發(fā)時(shí)加大對安全的開發(fā)量；
數(shù)據(jù)備份和恢復(fù)最困難蹬音，需要逐表逐條備份和還原上煤；
如果希望以最少的服務(wù)器為最多的租戶提供服務(wù)，并且租戶接受以犧牲隔離級(jí)別換取降低成本著淆，這種方案最適合。
五拴疤、Mycat 的分片 join
Join 絕對是關(guān)系型數(shù)據(jù)庫中最常用一個(gè)特性永部，然而在分布式環(huán)境中,跨分片的 join 確是最復(fù)雜的，最難解決一
個(gè)問題呐矾。
Mycat 目前版本支持跨分片的 join,主要實(shí)現(xiàn)的方式有四種：
1苔埋、全局表
2、ER 分片
3蜒犯、catletT(人工智能)
4组橄、ShareJoin
ShareJoin 在開發(fā)版中支持，前面三種方式 1.3.0.1 支持罚随。
5.1 全局表
一個(gè)真實(shí)的業(yè)務(wù)系統(tǒng)中玉工，往往存在大量的類似字典表的表格，它們與業(yè)務(wù)表之間可能有關(guān)系淘菩，這種關(guān)系遵班，可以理解為“標(biāo)簽”屠升，而不應(yīng)理解為通常的“主從關(guān)系”，這些表基本上很少變動(dòng)狭郑，可以根據(jù)主鍵 ID 進(jìn)行緩存腹暖。
在分片的情況下，當(dāng)業(yè)務(wù)表因?yàn)橐?guī)模而進(jìn)行分片以后翰萨，業(yè)務(wù)表與這些附屬的字典表之間的關(guān)聯(lián)脏答，就成了比較棘手的問題，考慮到字典表具有以下幾個(gè)特性：
1亩鬼、變動(dòng)不頻繁
2殖告、數(shù)據(jù)量總體變化不大
3、數(shù)據(jù)規(guī)模不大辛孵，很少有超過數(shù)十萬條記錄丛肮。
鑒于此，MyCAT 定義了一種特殊的表魄缚，稱之為“全局表”宝与，全局表具有以下特性：
1、全局表的插入冶匹、更新操作會(huì)實(shí)時(shí)在所有節(jié)點(diǎn)上執(zhí)行习劫，保持各個(gè)分片的數(shù)據(jù)一致性
2、全局表的查詢操作嚼隘，只從一個(gè)節(jié)點(diǎn)獲取
3诽里、全局表可以跟任何一個(gè)表進(jìn)行 JOIN 操作
將字典表或者符合字典表特性的一些表定義為全局表，則從另外一個(gè)方面飞蛹，很好的解決了數(shù)據(jù) JOIN 的難題谤狡。通過全局表+基于 E-R 關(guān)系的分片策略，MyCAT 可以滿足 80%以上的企業(yè)應(yīng)用開發(fā)卧檐。
全局表配置比較簡單墓懂，不用寫 Rule 規(guī)則，如下配置即可：
<table name="company" primaryKey="ID" type="global" dataNode="dn1,dn2,dn3" />
需要注意的是霉囚，全局表每個(gè)分片節(jié)點(diǎn)上都要有運(yùn)行創(chuàng)建表的 DDL 語句捕仔。
5.2 ER Join
MyCAT 借鑒了 NewSQL 領(lǐng)域的新秀 Foundation DB 的設(shè)計(jì)思路，F(xiàn)oundation DB 創(chuàng)新性的提出了 Table Group 的概念盈罐，其將子表的存儲(chǔ)位置依賴于主表榜跌，并且物理上緊鄰存放，因此徹底解決了 JION 的效率和性能問題盅粪，根據(jù)這一思路钓葫，提出了基于 E-R 關(guān)系的數(shù)據(jù)分片策略，子表的記錄與所關(guān)聯(lián)的父表記錄存放在同一個(gè)數(shù)據(jù)分片上湾揽。
customer 采用 sharding-by-intfile 這個(gè)分片策略瓤逼，分片在 dn1,dn2 上笼吟，orders 依賴父表進(jìn)行分片，兩個(gè)表的關(guān)聯(lián)關(guān)系為 orders.customer_id=customer.id霸旗。于是數(shù)據(jù)分片和存儲(chǔ)的示意圖如下：
這樣一來贷帮，分片 Dn1 上的的 customer 與 Dn1 上的 orders 就可以進(jìn)行局部的 JOIN 聯(lián)合，Dn2 上也如此诱告，再合并兩個(gè)節(jié)點(diǎn)的數(shù)據(jù)即可完成整體的 JOIN撵枢，試想一下，每個(gè)分片上 orders 表有 100 萬條精居，則 10 個(gè)分片就有 1 個(gè)億锄禽，基于 E-R 映射的數(shù)據(jù)分片模式，基本上解決了 80%以上的企業(yè)應(yīng)用所面臨的問題靴姿。
以上述例子為例沃但，schema.xml 中定義如下的分片配置：
<table name="customer" dataNode="dn1,dn2" rule="sharding-by-intfile">
<childTable name="orders" joinKey="customer_id" parentKey="id"/>
</table>
5.3 Share join
ShareJoin 是一個(gè)簡單的跨分片 Join,基于 HBT 的方式實(shí)現(xiàn)。目前支持 2 個(gè)表的 join,原理就是解析 SQL 語句佛吓，拆分成單表的 SQL 語句執(zhí)行宵晚，然后把各個(gè)節(jié)點(diǎn)的數(shù)據(jù)匯集。
5.4 catlet（人工智能）
解決跨分片的 SQL JOIN 的問題维雇，遠(yuǎn)比想象的復(fù)雜淤刃，而且往往無法實(shí)現(xiàn)高效的處理，既然如此吱型，就依靠人工的智力逸贾，去編程解決業(yè)務(wù)系統(tǒng)中特定幾個(gè)必須跨分片的 SQL 的 JOIN 邏輯，MyCAT 提供特定的 API 供程序員調(diào)用津滞，這就是 MyCAT 創(chuàng)新性的思路——人工智能铝侵。
六、全局序列號(hào)
6.1 全局序列號(hào)介紹
在實(shí)現(xiàn)分庫分表的情況下触徐，數(shù)據(jù)庫自增主鍵已無法保證自增主鍵的全局唯一哟沫。為此，MyCat 提供了全局sequence锌介，并且提供了包含本地配置和數(shù)據(jù)庫配置等多種實(shí)現(xiàn)方式。
6.2 本地文件方式
1猾警、原理：此方式 MyCAT 將 sequence 配置到文件中孔祸，當(dāng)使用到 sequence 中的配置后，MyCAT 會(huì)更下classpath 中的 sequence_conf.properties 文件中 sequence 當(dāng)前的值发皿。
2崔慧、配置方式：
在 sequence_conf.properties 文件中做如下配置：
GLOBAL_SEQ.HISIDS=
GLOBAL_SEQ.MINID=1001
GLOBAL_SEQ.MAXID=1000000000
GLOBAL_SEQ.CURID=1000
其中 HISIDS 表示使用過的歷史分段(一般無特殊需要可不配置)，MINID 表示最小 ID 值穴墅，MAXID 表示最大ID 值惶室，CURID 表示當(dāng)前 ID 值温自。
3、server.xml 中配置：
<system><property name="sequnceHandlerType">0</property></system>
注：sequnceHandlerType 需要配置為 0皇钞，表示使用本地文件方式悼泌。
4、使用示例：
insert into table1(id,name) values(next value for MYCATSEQ_GLOBAL,‘test’);
缺點(diǎn)：當(dāng) MyCAT 重新發(fā)布后夹界，配置文件中的 sequence 會(huì)恢復(fù)到初始值馆里。
優(yōu)點(diǎn)：本地加載，讀取速度較快可柿。
6.3 數(shù)據(jù)庫方式
原理：在數(shù)據(jù)庫中建立一張表鸠踪，存放 sequence 名稱(name)，sequence 當(dāng)前值(current_value)复斥，步長(increment int 類型每次讀取多少個(gè) sequence营密，假設(shè)為 K)等信息。
6.4 本地時(shí)間戳方式
ID= 64 位二進(jìn)制 (42(毫秒)+5(機(jī)器 ID)+5(業(yè)務(wù)編碼)+12(重復(fù)累加)
換算成十進(jìn)制為 18 位數(shù)的 long 類型目锭，每毫秒可以并發(fā) 12 位二進(jìn)制的累加评汰。
6.5 分布式 ZK ID 生成器
<property name="sequnceHandlerType">3</property>
Zk 的連接信息統(tǒng)一在 myid.properties 的 zkURL 屬性中配置。
基于 ZK 與本地配置的分布式 ID 生成器(可以通過 ZK 獲取集群（機(jī)房）唯一 InstanceID侣集，也可以通過配置文
件配置 InstanceID)
ID 結(jié)構(gòu)：long 64 位键俱，ID 最大可占 63 位
6.6 ZK 遞增方式
<property name="sequnceHandlerType">4</property>
Zk 的連接信息統(tǒng)一在 myid.properties 的 zkURL 屬性中配置。
4 是 zookeeper 實(shí)現(xiàn)遞增序列號(hào)
- 配置文件：sequence_conf.properties
- 只要配置好 ZK 地址和表名的如下屬性
- TABLE.MINID 某線程當(dāng)前區(qū)間內(nèi)最小值
- TABLE.MAXID 某線程當(dāng)前區(qū)間內(nèi)最大值
- TABLE.CURID 某線程當(dāng)前區(qū)間內(nèi)當(dāng)前值
- 文件配置的 MAXID 以及 MINID 決定每次取得區(qū)間世分，這個(gè)對于每個(gè)線程或者進(jìn)程都有效
- 文件中的這三個(gè)屬性配置只對第一個(gè)進(jìn)程的第一個(gè)線程有效编振，其他線程和進(jìn)程會(huì)動(dòng)態(tài)讀取 ZK
七、Mycat 分片規(guī)則
7.1 分片規(guī)則概述
在數(shù)據(jù)切分處理中臭埋，特別是水平切分中踪央，中間件最終要的兩個(gè)處理過程就是數(shù)據(jù)的切分、數(shù)據(jù)的聚合瓢阴。選擇
合適的切分規(guī)則畅蹂，至關(guān)重要，因?yàn)樗鼪Q定了后續(xù)數(shù)據(jù)聚合的難易程度荣恐，甚至可以避免跨庫的數(shù)據(jù)聚合處理液斜。
7.2 Mycat 全局表
如果你的業(yè)務(wù)中有些數(shù)據(jù)類似于數(shù)據(jù)字典，比如配置文件的配置叠穆，常用業(yè)務(wù)的配置或者數(shù)據(jù)量不大很少變動(dòng)的表少漆，這些表往往不是特別大，而且大部分的業(yè)務(wù)場景都會(huì)用到硼被，那么這種表適合于 Mycat 全局表示损，無須對數(shù)據(jù)進(jìn)行切分，只要在所有的分片上保存一份數(shù)據(jù)即可嚷硫，Mycat 在 Join 操作中检访，業(yè)務(wù)表與全局表進(jìn)行 Join 聚合會(huì)優(yōu)先選擇相同分片內(nèi)的全局表 join始鱼，避免跨庫 Join，在進(jìn)行數(shù)據(jù)插入操作時(shí)脆贵，mycat 將把數(shù)據(jù)分發(fā)到全局表對應(yīng)的所有分片執(zhí)行医清，在進(jìn)行數(shù)據(jù)讀取時(shí)候?qū)?huì)隨機(jī)獲取一個(gè)節(jié)點(diǎn)讀取數(shù)據(jù)。
目前 Mycat 沒有做全局表的數(shù)據(jù)一致性檢查丹禀，后續(xù)版本 1.4 之后可能會(huì)提供全局表一致性檢查状勤，檢查每個(gè)分
片的數(shù)據(jù)一致性。
全局表的配置如下
<table name="t_area" primaryKey="id" type="global" dataNode="dn1,dn2" />
7.3 ER 分片表
有一類業(yè)務(wù)双泪，例如訂單（order）跟訂單明細(xì)（order_detail）,明細(xì)表會(huì)依賴于訂單持搜，也就是說會(huì)存在表的主從關(guān)系，這類似業(yè)務(wù)的切分可以抽象出合適的切分規(guī)則焙矛，比如根據(jù)用戶 ID 切分,其他相關(guān)的表都依賴于用戶 ID葫盼，再或者根據(jù)訂單 ID 切分，總之部分業(yè)務(wù)總會(huì)可以抽象出父子關(guān)系的表村斟。這類表適用于 ER 分片表贫导，子表的記錄與所關(guān)聯(lián)的父表記錄存放在同一個(gè)數(shù)據(jù)分片上，避免數(shù)據(jù) Join 跨庫操作蟆盹。
以 order 與 order_detail 例子為例孩灯，schema.xml 中定義如下的分片配置,order,order_detail 根據(jù) order_id進(jìn)行數(shù)據(jù)切分，保證相同 order_id 的數(shù)據(jù)分到同一個(gè)分片上逾滥，在進(jìn)行數(shù)據(jù)插入操作時(shí)峰档，Mycat 會(huì)獲取 order 所在的分片，然后將 order_detail 也插入到 order 所在的分片寨昙。
<table name="order" dataNode="dn$1-32" rule="mod-long">
<childTable name="order_detail" primaryKey="id" joinKey="order_id" parentKey="order_id" />
</table>
7.4 多對多關(guān)聯(lián)
有一類業(yè)務(wù)場景是 “主表 A+關(guān)系表+主表 B”讥巡，舉例來說就是商戶會(huì)員+訂單+商戶，對應(yīng)這類業(yè)務(wù)舔哪，如何切分欢顷？
從會(huì)員的角度，如果需要查詢會(huì)員購買的訂單捉蚤，那按照會(huì)員進(jìn)行切分即可抬驴，但是如果要查詢商戶當(dāng)天售出的訂單，那又需要按照商戶做切分缆巧，可是如果既要按照會(huì)員又要按照商戶切分怎爵，幾乎是無法實(shí)現(xiàn)，這類業(yè)務(wù)如何選擇切分規(guī)則非常難盅蝗。目前還暫時(shí)無法很好支持這種模式下的 3 個(gè)表之間的關(guān)聯(lián)。目前總的原則是需要從業(yè)務(wù)角度來看姆蘸，關(guān)系表更偏向哪個(gè)表墩莫，即“A 的關(guān)系”還是“B 的關(guān)系”芙委，來決定關(guān)系表跟從那個(gè)方向存儲(chǔ)，未來 Mycat版本中將考慮將中間表進(jìn)行雙向復(fù)制狂秦，以實(shí)現(xiàn)從 A-關(guān)系表 以及 B-關(guān)系表的雙向關(guān)聯(lián)查詢?nèi)缦聢D所示：
7.5 Mycat 常用的分片規(guī)則
7.5.1 分片枚舉
通過在配置文件中配置可能的枚舉 id灌侣，自己配置分片，本規(guī)則適用于特定的場景裂问，比如有些業(yè)務(wù)需要按照省份或區(qū)縣來做保存侧啼，而全國省份區(qū)縣固定的，這類業(yè)務(wù)使用本條規(guī)則堪簿。
7.5.2 固定分片 hash 算法
本條規(guī)則類似于十進(jìn)制的求模運(yùn)算痊乾，區(qū)別在于是二進(jìn)制的操作,是取 id 的二進(jìn)制低 10 位，即 id 二進(jìn)制&1111111111椭更。此算法的優(yōu)點(diǎn)在于如果按照 10 進(jìn)制取模運(yùn)算哪审，在連續(xù)插入 1-10 時(shí)候 1-10 會(huì)被分到 1-10 個(gè)分片，增大了插入的事務(wù)控制難度虑瀑，而此算法根據(jù)二進(jìn)制則可能會(huì)分到連續(xù)的分片湿滓，減少插入事務(wù)事務(wù)控制難度。
7.5.3 范圍約定
此分片適用于舌狗，提前規(guī)劃好分片字段某個(gè)范圍屬于哪個(gè)分片叽奥，
start <= range <= end.
range start-end ,data node index
K=1000,M=10000.
7.5.4 取 模
此規(guī)則為對分片字段求摸運(yùn)算。
7.5.5 按日期（天）分片
此規(guī)則為按天分片痛侍。
7.5.6 取模范圍約束
此種規(guī)則是取模運(yùn)算與范圍約束的結(jié)合朝氓，主要為了后續(xù)數(shù)據(jù)遷移做準(zhǔn)備，即可以自主決定取模后數(shù)據(jù)的節(jié)點(diǎn)
分布恋日。
7.5.7 截取數(shù)字做 hash 求模范圍約束
此種規(guī)則類似于取模范圍約束膀篮，此規(guī)則支持?jǐn)?shù)據(jù)符號(hào)字母取模。
7.5.8 應(yīng)用指定
此規(guī)則是在運(yùn)行階段有應(yīng)用自主決定路由到那個(gè)分片岂膳。
7.5.9 截取數(shù)字 hash 解析
此規(guī)則是截取字符串中的 int 數(shù)值 hash 分片誓竿。
7.5.10 一致性 hash
一致性 hash 預(yù)算有效解決了分布式數(shù)據(jù)的擴(kuò)容問題。
7.5.11 按單月小時(shí)拆分
此規(guī)則是單月內(nèi)按照小時(shí)拆分谈截，最小粒度是小時(shí)筷屡，可以一天最多 24 個(gè)分片，最少 1 個(gè)分片簸喂，一個(gè)月完后下月
從頭開始循環(huán)毙死。每個(gè)月月尾，需要手工清理數(shù)據(jù)喻鳄。
7.5.12 范圍求模分片
先進(jìn)行范圍分片計(jì)算出分片組扼倘，組內(nèi)再求模，優(yōu)點(diǎn)可以避免擴(kuò)容時(shí)的數(shù)據(jù)遷移，又可以一定程度上避免范圍分片的熱點(diǎn)問題再菊，綜合了范圍分片和求模分片的優(yōu)點(diǎn)爪喘，分片組內(nèi)使用求模可以保證組內(nèi)數(shù)據(jù)比較均勻纠拔，分片組之間是范圍分片可以兼顧范圍查詢秉剑。最好事先規(guī)劃好分片的數(shù)量，數(shù)據(jù)擴(kuò)容時(shí)按分片組擴(kuò)容稠诲，則原有分片組的數(shù)據(jù)不需要遷移侦鹏。由于分片組內(nèi)數(shù)據(jù)比較均勻，所以分片組內(nèi)可以避免熱點(diǎn)數(shù)據(jù)問題臀叙。
7.5.13 日期范圍 hash 分片
思想與范圍求模一致略水，當(dāng)由于日期在取模會(huì)有數(shù)據(jù)集中問題，所以改成 hash 方法匹耕。先根據(jù)日期分組聚请，再根據(jù)時(shí)間 hash 使得短期內(nèi)數(shù)據(jù)分布的更均勻優(yōu)點(diǎn)可以避免擴(kuò)容時(shí)的數(shù)據(jù)遷移，又可以一定程度上避免范圍分片的熱點(diǎn)問題要求日期格式盡量精確些稳其，不然達(dá)不到局部均勻的目的驶赏。
7.5.14 冷熱數(shù)據(jù)分片
根據(jù)日期查詢?nèi)罩緮?shù)據(jù) 冷熱數(shù)據(jù)分布 ，最近 n 個(gè)月的到實(shí)時(shí)交易庫查詢既鞠，超過 n 個(gè)月的按照 m 天分片煤傍。
7.5.15 自然月分片
按月份列分區(qū) ，每個(gè)自然月一個(gè)分片嘱蛋，格式 between 操作解析的范例蚯姆。
7.5.16 有狀態(tài)分片算法
有狀態(tài)分片算法與之前的分片算法不同,它是為數(shù)據(jù)自動(dòng)遷移而設(shè)計(jì)的。直至 2018 年 7 月 24 日為止,現(xiàn)支持有狀態(tài)算法的分片策略只有 crc32slot 歡迎大家提供更多有狀態(tài)分片算法洒敏。
7.5.17 crc32slot 分片算法
crc32solt 是有狀態(tài)分片算法的實(shí)現(xiàn)之一龄恋，crc32(key)%102400=slot，slot 按照范圍均勻分布在 dataNode 上凶伙，針對每張表進(jìn)行實(shí)例化郭毕，通過一個(gè)文件記錄 slot 和節(jié)點(diǎn)映射關(guān)系，遷移過程中通過 zk 協(xié)調(diào)其中需要在分片表中增加 slot 字段函荣，用以避免遷移時(shí)重新計(jì)算显押，只需要遷移對應(yīng) slot 數(shù)據(jù)即可分片最大個(gè)數(shù)為 102400 個(gè)，短期內(nèi)應(yīng)該夠用傻挂，每分片一千萬乘碑，總共可以支持一萬億數(shù)據(jù)
八、Mycat常見問題與解決方案
8.1 Mycat 目前有哪些功能與特性金拒？
? 支持 SQL 92 標(biāo)準(zhǔn)兽肤；
? 支持 Mysql 集群，可以作為 Proxy 使用；
? 支持 JDBC 連接多數(shù)據(jù)庫轿衔；
? 支持 NoSQL 數(shù)據(jù)庫沉迹；
? 支持 galera for mysql 集群，percona-cluster 或者 mariadb cluster害驹，提供高可用性數(shù)據(jù)分片集群；
? 自動(dòng)故障切換蛤育，高可用性宛官；
? 支持讀寫分離，支持 Mysql 雙主多從瓦糕，以及一主多從的模式底洗；
? 支持全局表，數(shù)據(jù)自動(dòng)分片到多個(gè)節(jié)點(diǎn)咕娄，用于高效表關(guān)聯(lián)查詢亥揖；
? 支持獨(dú)有的基于 E-R 關(guān)系的分片策略，實(shí)現(xiàn)了高效的表關(guān)聯(lián)查詢圣勒；
? 支持一致性 Hash 分片费变，有效解決分片擴(kuò)容難題；
多平臺(tái)支持圣贸，部署和實(shí)施簡單挚歧；
? 支持 Catelet 開發(fā)，類似數(shù)據(jù)庫存儲(chǔ)過程吁峻，用于跨分片復(fù)雜 SQL 的人工智能編碼實(shí)現(xiàn)滑负，143 行 Demo 完成
跨分片的兩個(gè)表的 JION 查詢；
? 支持 NIO 與 AIO 兩種網(wǎng)絡(luò)通信機(jī)制用含，Windows 下建議 AIO矮慕，Linux 下目前建議 NIO；
? 支持 Mysql 存儲(chǔ)過程調(diào)用啄骇；
? 以插件方式支持 SQL 攔截和改寫痴鳄；
? 支持自增長主鍵、支持 Oracle 的 Sequence 機(jī)制肠缔。
8.2 Mycat 除了 Mysql 還支持哪些數(shù)據(jù)庫夏跷？
mongodb、oracle明未、sqlserver 槽华、hive 、db2 趟妥、 postgresql猫态。
8.3 Mycat 支持集群么？
目前 Mycat 沒有實(shí)現(xiàn)對多 Mycat 集群的支持，可以暫時(shí)使用 haproxy 來做負(fù)載亲雪，或者統(tǒng)計(jì)硬件負(fù)載勇凭。
8.4 Mycat 多主切換需要人工處理么？
Mycat 通過心跳檢測义辕，自主切換數(shù)據(jù)庫虾标，保證高可用性，無須手動(dòng)切換灌砖。
九璧函、讀寫分離
9.1 MySQL 主從復(fù)制的幾種方案
數(shù)據(jù)庫讀寫分離對于大型系統(tǒng)或者訪問量很高的互聯(lián)網(wǎng)應(yīng)用來說，是必不可少的一個(gè)重要功能基显。從數(shù)據(jù)庫的角度來說蘸吓，對于大多數(shù)應(yīng)用來說，從集中到分布撩幽，最基本的一個(gè)需求不是數(shù)據(jù)存儲(chǔ)的瓶頸库继，而是在于計(jì)算的瓶頸，即 SQL 查詢的瓶頸窜醉，我們知道帖渠，正常情況下琼锋，Insert SQL 就是幾十個(gè)毫秒的時(shí)間內(nèi)寫入完成靶草，而系統(tǒng)中的大多數(shù) Select SQL 則要幾秒到幾分鐘才能有結(jié)果松蒜，很多復(fù)雜的 SQL，其消耗服務(wù)器 CPU 的能力超強(qiáng)读串，不亞于死循環(huán)的威力聊记。在沒有讀寫分離的系統(tǒng)上，很可能高峰時(shí)段的一些復(fù)雜 SQL 查詢就導(dǎo)致數(shù)據(jù)庫服務(wù)器 CPU爆表恢暖，系統(tǒng)陷入癱瘓排监，嚴(yán)重情況下可能導(dǎo)致數(shù)據(jù)庫崩潰。因此杰捂，從保護(hù)數(shù)據(jù)庫的角度來說舆床，我們應(yīng)該盡量避免沒有主從復(fù)制機(jī)制的單節(jié)點(diǎn)數(shù)據(jù)庫。
對于 MySQL 來說嫁佳，標(biāo)準(zhǔn)的讀寫分離是主從模式挨队，一個(gè)寫節(jié)點(diǎn) Master 后面跟著多個(gè)讀節(jié)點(diǎn)，讀節(jié)點(diǎn)的數(shù)量取
決于系統(tǒng)的壓力蒿往，通常是 1-3 個(gè)讀節(jié)點(diǎn)的配置盛垦，如下圖所示：
MySQL 支持更多的主從復(fù)制的拓?fù)潢P(guān)系，如下圖所示瓤漏，但通常我們不會(huì)采用雙向主從同步以及環(huán)狀的拓?fù)洌?/p>
9.2 MySQL 主從復(fù)制的幾個(gè)問題
MySQL 主從復(fù)制并不完美腾夯，存在著幾個(gè)由來已久的問題颊埃，首先一個(gè)問題是復(fù)制方式：
? 基于 SQL 語句的復(fù)制(statement-based replication, SBR)；
? 基于行的復(fù)制(row-based replication, RBR)蝶俱；
? 混合模式復(fù)制(mixed-based replication, MBR)班利；
? 基于 SQL 語句的方式最古老的方式，也是目前默認(rèn)的復(fù)制方式榨呆，后來的兩種是 MySQL 5 以后才出現(xiàn)的復(fù)
制方式罗标。
選擇哪種方式復(fù)制，會(huì)影響到復(fù)制的效率以及服務(wù)器的損耗积蜻，甚以及數(shù)據(jù)一致性性問題馒稍，目前其實(shí)沒有很好
的客觀手手段去評估一個(gè)系統(tǒng)更適合哪種方式的復(fù)制，Mycat 未來希望能通過智能調(diào)優(yōu)模塊給出更科學(xué)的建議浅侨。
第二個(gè)問題是關(guān)于主從同步的監(jiān)控問題，Mysql 有主從同步的狀態(tài)信息证膨，可以通過命令 show slave status獲取如输，除了獲知當(dāng)前是否主從同步正常工作，另外一個(gè)重要指標(biāo)就是 Seconds_Behind_Master央勒，從字面理解不见，它表示當(dāng)前 MySQL 主從數(shù)據(jù)的同步延遲，單位是秒崔步，但這個(gè)指標(biāo)從 DBA 的角度并不能簡單的理解為延遲多少秒稳吮，但對于應(yīng)用來說，簡單的認(rèn)為是主從同步的時(shí)間差就可以了井濒，另外灶似，當(dāng)主從同步停止以后，重新啟動(dòng)同步瑞你，這個(gè)數(shù)值可能會(huì)是幾萬秒酪惭，取決于主從同步停止的時(shí)間長短，我們可以認(rèn)為數(shù)據(jù)此時(shí)有很多天沒有同步了者甲，而這個(gè)數(shù)值越接近零春感，則說明主從同步延遲最小，我們可以采集這個(gè)指標(biāo)并匯聚曲線圖虏缸，來分析我們的數(shù)據(jù)庫的同步延遲曲線鲫懒，然后根據(jù)此曲線，給出一個(gè)合理的閥值刽辙，主從同步的時(shí)延小于閥值時(shí)窥岩，我們認(rèn)為從庫是同步的，此時(shí)可以安全的從從庫讀取數(shù)據(jù)扫倡。Mycat 未來將支持這種優(yōu)化谦秧，讓應(yīng)用更加可靠的讀取到預(yù)期的從庫數(shù)據(jù)竟纳。
十、高可用與集群
10.1 MySQL 高可用的幾種方案
10.1.1 主從復(fù)制+讀寫分離
對于數(shù)據(jù)實(shí)時(shí)性要求不是特別嚴(yán)格的應(yīng)用疚鲤，只需要通過廉價(jià)的 pc server 來擴(kuò)展 Slave 的數(shù)量锥累，將讀壓力分散到多臺(tái) Slave 的機(jī)器上面，即可通過分散單臺(tái)數(shù)據(jù)庫服務(wù)器的讀壓力來解決數(shù)據(jù)庫端的讀性能瓶頸集歇，畢竟在大多數(shù)數(shù)據(jù)庫應(yīng)用系統(tǒng)中的讀壓力還是要比寫壓力大很多桶略。這在很大程度上解決了目前很多中小型網(wǎng)站的數(shù)據(jù)庫壓力瓶頸問題，甚至有些大型網(wǎng)站也在使用類似方案解決數(shù)據(jù)庫瓶頸诲宇。
10.1.2 MySQL Cluster
重啟 MySQLCluster 數(shù)據(jù)庫的管理操作之前需要執(zhí)行 46 個(gè)手動(dòng)命令际歼，需要耗費(fèi) DBA 2.5 小時(shí)的時(shí)間，而依靠 MySQLCluster Manager 只需一個(gè)命令即可完成姑蓝，但 MySQL Cluster Manager 僅作為商用 MySQL Cluster 運(yùn)營商級(jí)版本 (CGE) 數(shù)據(jù)庫的一部分提供鹅心，需要購買。其官方的說明纺荧，若應(yīng)用中的 SQL 操作為主鍵數(shù)據(jù)庫訪問旭愧，包含一些JOIN 操作而非對整個(gè)表執(zhí)行常規(guī)掃描和 JOIN 而返回?cái)?shù)萬行數(shù)據(jù)，則適合 Cluster宙暇，否則不合適输枯，從這一條限制來看，表明大多數(shù)業(yè)務(wù)場景并不合適 MySQL Cluster占贫，業(yè)內(nèi)有資深人士也憑評價(jià)：NDB 不適合大多數(shù)業(yè)務(wù)場景桃熄，而且有安全問題。
10.1.3 HeartBeat+雙主復(fù)制
heartbeat 是 Linux-HA 工程的一個(gè)組件,heartbeat 最核心的包括兩個(gè)部分：心跳監(jiān)測和資源接管型奥。在指定的時(shí)間內(nèi)未收到對方發(fā)送的報(bào)文瞳收，那么就認(rèn)為對方失效，這時(shí)需啟動(dòng)資源接管模塊來接管運(yùn) 行在對方主機(jī)上的資源或者服務(wù)桩引。
10.1.4 HeartBeat+DRBD+MySQL
DRBD 是通過網(wǎng)絡(luò)來實(shí)現(xiàn)塊設(shè)備的數(shù)據(jù)鏡像同步的一款開源 Cluster 軟件缎讼，它自動(dòng)完成網(wǎng)絡(luò)中兩個(gè)不同服務(wù)器上的磁盤同步，相對于 binlog 日志同步坑匠，它是更底層的磁盤同步血崭，理論上 DRDB 適合很多文件型系統(tǒng)的高可用。
10.1.5 LVS+Keepalived+雙主復(fù)制
Lvs 是一個(gè)虛擬的服務(wù)器集群系統(tǒng)厘灼，可以實(shí)現(xiàn) LINUX 平臺(tái)下的簡單負(fù)載均衡夹纫。keepalived 是一個(gè)類似于layer3, 4 & 5 交換機(jī)制的軟件，主要用于主機(jī)與備機(jī)的故障轉(zhuǎn)移设凹，這是一種適用面很廣的負(fù)載均衡和高可用方案舰讹，最常用于 Web 系統(tǒng)。
10.1.6 MariaDB Galera
這種 gluster 模式可以說是全新的一種高可用方案闪朱，前面也提到其優(yōu)點(diǎn)月匣，它的缺點(diǎn)不多钻洒，不支持 XA，不支持
Lock Table锄开，只能用 InnoDB 引擎素标。
10.2 Mycat 高可用方案
Mycat 作為一個(gè)代理層中間件，Mycat 系統(tǒng)的高可用涉及到 Mycat 本身的高可用以及后端 MySQL 的高可用萍悴，前面所講的 MySQL 高可用方案都可以在此用來確保 Mycat 所連接的后端 MySQL 服務(wù)的高可用性头遭。在大多數(shù)情況下，建議采用標(biāo)準(zhǔn)的 MySQL 主從復(fù)制高可用性配置并交付給 Mycat 來完成后端 MySQL 節(jié)點(diǎn)的主從自動(dòng)切換癣诱。
如圖所示计维，MySQL 節(jié)點(diǎn)開啟主從復(fù)制的配置方案，并將主節(jié)點(diǎn)配置為 Mycat 的 dataHost 里的 writeNode撕予，從節(jié)點(diǎn)配置為 readNode鲫惶，同時(shí) Mycat 內(nèi)部定期對一個(gè) dataHost 里的所有 writeHost 與 readHost 節(jié)點(diǎn)發(fā)起心跳檢測，正常情況下实抡，Mycat 會(huì)將第一個(gè) writeHost 作為寫節(jié)點(diǎn)剑按，所有的 DML SQL 會(huì)發(fā)送給此節(jié)點(diǎn)，若Mycat開啟了讀寫分離澜术，則查詢節(jié)點(diǎn)會(huì)根據(jù)讀寫分離的策略發(fā)往 readHost(+writeHost)執(zhí)行，當(dāng)一個(gè) dataHost 里面配置了兩個(gè)或多個(gè) writeHost 的情況下猬腰，如果第一個(gè) writeHost 宕機(jī)鸟废，則 Mycat 會(huì)在默認(rèn)的 3 次心跳檢查失敗后，自動(dòng)切換到下一個(gè)可用的 writeHost 執(zhí)行 DML SQL 語句姑荷，并在 conf/dnindex.properties 文件里記錄當(dāng)前所用的 writeHost 的 index（第一個(gè)為 0盒延，第二個(gè)為 1，依次類推）鼠冕，注意添寺，此文件不能刪除和擅自改變，除非你深刻理解了它的作用以及你的目的懈费。
那么問題來了计露，當(dāng)原來配置的 MySQL 寫節(jié)點(diǎn)宕機(jī)恢復(fù)以后，怎么重新加入 Mycat憎乙，要不要恢復(fù)為原來的寫節(jié)點(diǎn)票罐？關(guān)于這個(gè)問題，我們也曾與 DBA 討論很久泞边，最終的建議方案是该押，保持現(xiàn)有狀態(tài)不變，改旗易幟阵谚，恢復(fù)后的MySQL節(jié)點(diǎn)作為從節(jié)點(diǎn)蚕礼，跟隨新的主節(jié)點(diǎn)烟具，重新配置主從同步，原先跟隨該節(jié)點(diǎn)做同步的其他節(jié)點(diǎn)也同樣換帥奠蹬，重新配置同步源朝聋，這些節(jié)點(diǎn)的數(shù)據(jù)手工完成同步以后，再加入 Mycat 里罩润。目前 1.3 版本的 Mycat 還沒有實(shí)現(xiàn)監(jiān)控MySQL 主從同步狀態(tài)的功能玖翅，因此這個(gè)過程里，DBA 可以先修改 MySQL 的密碼割以，讓 Mycat 無法鏈接故障服務(wù)器金度，等同步完成以后，恢復(fù)密碼严沥，這樣 Mycat 就自動(dòng)重新將修復(fù)好的 Mycat 納管進(jìn)來了猜极。
說完了 MySQL 部分，接下來我們看看 Mycat 自身的高可用性消玄，由于 Mycat 自身是屬于無狀態(tài)的中間件（除了主從切換過程中記錄的 dnindex.properties 文件）跟伏，因此 Mycat 很容易部署為集群方式，提供高可用案翩瓜。原先有規(guī)劃 Mycat-balance 組件受扳，專門用于 Mycat 負(fù)載均衡，但由于缺乏志愿者兔跌，也沒有經(jīng)過生產(chǎn)實(shí)踐證勘高，因此暫時(shí)不建議使用，官方建議是采用基于硬件的負(fù)載均衡器或者軟件方式的 HAproxy坟桅，HAProxy 相比 LVS 的使用要簡單很多华望，功能方面也很豐富，免費(fèi)開源仅乓，穩(wěn)定性也是非常好赖舟，可以與 LVS 相媲美，根據(jù)官方文檔夸楣，HAProxy 可以跑滿 10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs (Myri10G PCI-Express)宾抓，這個(gè)作為軟件級(jí)負(fù)載均衡，也是比較驚人的豫喧，下圖是 HAproxy+Mycat 集+MySQL 主從所組成的高可用性方案：
如果還擔(dān)心 HAproxy 的穩(wěn)定性和單點(diǎn)問題洞慎，則可以用 keepalived 的 VIP 的浮動(dòng)功能，加以強(qiáng)化：
