mycat權(quán)威指南第三章數(shù)據(jù)切分概述

篇第一章MYCAT開源第二章MYCAT前世今 COBAR的十一個 第三章數(shù)據(jù)切分概 第四章走進 第五章MYCAT中的概 多租 第六章快速十分鐘 快速鏡像方式體驗 warpper日 mycat日 debug模式下分析sql執(zhí) 第七章MYCAT的配 搞定 schematablechildTabledataNodedataHost優(yōu)化配置 usersystem規(guī)則配置 tableRulefunction第八章MYCAT的 分片 JOIN概 全局 ER SHARE SPARK/STORM對JOIN擴 第九章全局序列 第十章MYCAT分片規(guī) ER分片 主鍵分片VS非主鍵分 第十一章MYCAT支持的分片規(guī) 固定分片HASH算 求 ASCII碼求模范圍約 字符串HASH解 一致性 第十二章常見問題與解決方 第十三章MYCAT性能測 高級進第十四章MYCAT讀寫分 MYSQL主從的原 第十五章高可用與集 第十六章事務(wù)支 XA事務(wù)原 XA事務(wù)的問題和MYSQL的局 MYSQL的XA事務(wù)缺 第十七章SQL 默認SQL 捕獲記錄SQL 第十八章MYCAT注 第十九章MYCATCATLET和JDBC多數(shù)據(jù)庫支 MYCAT支持的CATLET實 JDBC多數(shù)據(jù)庫支 SQL Spark 第二十章管理命令與命令行 第二十一章壓縮協(xié)議支 SNMP管 中 生產(chǎn)實第二十三章生產(chǎn)實踐案 SAAS多租戶案 第二十四章生產(chǎn)環(huán)境部 單節(jié)點MYCAT部 第二十五章MYCAT實施指 第二十六章數(shù)據(jù)遷移與擴容實 一致性HASH分片遷 配置一致性HASH分 一致性HASH的數(shù)據(jù)遷移（擴容 使用MYSQLDUMP進行數(shù)據(jù)遷 LOADDATAINFILE批量導(dǎo) 數(shù)據(jù)遷移的第二十七章性能調(diào) JVM調(diào) JVM結(jié) 回收機 常 JVM參數(shù)分 吞吐量VS暫停時 GC日 開發(fā)篇第二十八章加入 如何加入 第二十九章MYCAT架構(gòu)分 MYCAT和TDDL、AMOEBA、COBAR的架 第三十章MYCAT線程模型分 SQL請求的線程切換 COBAR線程介 MYCAT與COBAR的比 第三十一章MYCAT連接 第三十二章MYCAT的網(wǎng)絡(luò)通信框 MYCAT與COBAR對比測 NIOSocketWR和NIOReactor分 與COBAR原有NIO細節(jié)比 COBAR的 比較MYCAT和COBAR兩種寫方 MYCAT的AIO實 第三十三章MYCAT的路由與分發(fā)流 第三十四章MYCAT的JDBC后端框 JDBC方式后端數(shù)據(jù) 第三十五章MYCAT的事務(wù)管理機 第三十六章MYCAT的分頁和跨庫 SHAREJOIN代碼分 第三十七章MYCAT緩 第三十八章MYCAT的分片規(guī)則設(shè) 第三十九章LOADDATA與壓縮協(xié)議源碼分 MYCAT群英 篇MYCAT隨著技術(shù)的不斷進步，是否應(yīng)該有一種比公司形態(tài)更有效的組織來支撐經(jīng)濟的進一步發(fā)展這種新型組織在以有形資產(chǎn)為的，以農(nóng)業(yè)經(jīng)濟和工業(yè)經(jīng)濟為主導(dǎo)的社會是不可能取得成功的，而在以無形資產(chǎn)逐漸成為的，以知識經(jīng)濟為主導(dǎo)的信息社會將會成為可能。如國內(nèi)崛起的分布式數(shù)據(jù)庫中間件產(chǎn)品Mct并不是由任何一家公司主導(dǎo)開發(fā)的，而是由民間自發(fā)組織的由那些喜愛它的不知名的程序員，共同開發(fā)，如今該產(chǎn)品的發(fā)展速度極快其也逐漸擴大。國內(nèi)外類似的開源組織和產(chǎn)品還有很多，這些開源產(chǎn)品潛力無限，無論開發(fā)效率和質(zhì)量都逐漸任何一家公司的產(chǎn)品。這也導(dǎo)致了一些公司試圖通過收購等遏制開源產(chǎn)品的發(fā)展。那么這些開源產(chǎn)品愛好者和貢獻者獲得了什么呢？在「無私奉獻」的過程中他們獲得了知識——信息社會最有價值的資產(chǎn)，他們可以用這些知識以換來不可估量的，信息社會的開源組織使「按勞分配」達到了前所未有的公平與公正。企業(yè)所采取的激勵、扁平化管理、自由工作時間等模式，正是對公司這種生產(chǎn)關(guān)系「自頂向下」的改良，以適應(yīng)持久技術(shù)進步帶來的生產(chǎn)力的高速發(fā)展。但公司的本質(zhì)：追求股東利益最大化，使其不可能實現(xiàn)真正意義的去中心化。信息社會的開源組織形態(tài)是對原有公司模式「自底向上」的一次式創(chuàng)新,他們將帶來生產(chǎn)力的極速發(fā)展。這種組織具有開放、共享、敏捷、去中心化等等這些可以帶來高效率的特性，可以想像擁有杰出技術(shù)與高效團隊的開源組織可以創(chuàng)造出一切公司的更優(yōu)秀的產(chǎn)品。每一個人為改變他的狀況而自然做出的努力，當(dāng)其具有施展的自由和安全時，就是一個十分強有力的原則，不需要借助其他，這種個人的努力，就能給社會帶來和繁榮」密的這段話是工業(yè)中的小公司向擁有國家特許經(jīng)營權(quán)的企業(yè)發(fā)出的吶喊。沒有工業(yè)就沒有現(xiàn)代公司存在的必要性；沒有現(xiàn)代公司的存在和發(fā)展，工業(yè)的快速進程也無法出現(xiàn)。歷史重演，信息社會的開源組織將這段話原封不動的回贈給了現(xiàn)代公司制度。它讓知識經(jīng)濟不再只是少數(shù)資本家的游戲，而成為普通人登臺表演的機會。技術(shù)不再高高在上，而是落地生根。開源組織將成為引領(lǐng)信息社會進步的發(fā)動機，接下來的競爭，就看誰能在無限的數(shù)字世界里更好的發(fā)揮開源組織的能量了，一個新的時代即將到來！隨著的持續(xù)快速發(fā)展和中國經(jīng)濟實力的不斷加強，以Myct為代表的中國開源組織和產(chǎn)品的價值和發(fā)展前景不可限量！————ByMYCAT背景介 n 10能—“每一個成功的背后都有一個女人”。自然Mycat也逃脫不了這個法則。Mycat背后是阿里曾經(jīng)開源的知名產(chǎn)品——Cobar。Cobar的功能和優(yōu)勢是MySQL數(shù)據(jù)庫分片，此產(chǎn)品曾經(jīng)廣為流傳，據(jù)說最早的發(fā)起者對Mysql很精通，后來從阿里跳槽了，阿里隨后開源的Cobar，并維持到2013年年初，然后，就沒Cobar的思路路徑的確不錯。基于Java開發(fā)的，實現(xiàn)了MySQL公開的二進制傳輸協(xié)議，巧妙地將自己成一個MySQLServer，目前市面上絕大多數(shù)MySQL客戶端工具和應(yīng)用都能兼容。比自己實現(xiàn)一Cobar使用起來也非常方便。由于是基于Java語言開發(fā)的，下來解壓，安裝JDK，然后配置幾個不是很復(fù)雜的配置文件，猛擊鼠標(biāo)，就能啟動Cobar。因此這個開源產(chǎn)品贏得了很多Java粉絲以及PHP用戶的追捧。當(dāng)然，笨人(Leaderus)也跟著進入，并且在某個大型云項目中——“苦海無邊”的煎著熬，良久。愛情就像是見鬼。只有撞見了，你才會明白愛情是怎么回事。A是如此神秘，欲語還羞。情竇初開的你又玩命將A的優(yōu)點放大，使自己成為一只迷途的羔羊。每個用過Coar的人就像談過一段一波三折、蕩氣回腸的愛情，令你肝腸寸斷。就像圍城：里面的人已經(jīng)出不來了，還有的人拼命想擠進去。僅以此文，獻給哪些努力在IT界尋求未來的精英和小白們，還有被無視的，正準(zhǔn)備轉(zhuǎn)行的同仁，同在江湖混，不容易啊，面試時候就裝裝糊涂，放人家一馬，說不定，以后又是一個Madein的如果我有一個32的服務(wù)器，我就可以實現(xiàn)1個億的數(shù)據(jù)分片，我有32的服務(wù)器么？沒有，所以我至今無法實現(xiàn)1個億的數(shù)據(jù)分片?！狹ycat‘sn曾經(jīng)的TA，長發(fā)飄飄，膚若凝脂，，長袖善舞，所以，一笑傾城。那已成，一如您年少時CobarITTACobar的這段美好的描述(不能說Cobar是阿里巴巴研發(fā)的關(guān)系型數(shù)據(jù)的分布式處理系統(tǒng)，該產(chǎn)品成功替代了原先基于Oracle的數(shù)據(jù)方案，目前已經(jīng)接管了3000+個MySQL數(shù)據(jù)庫的schema50SQL執(zhí)行請求。50億有多大？99%的普通人類看到這個數(shù)字，已經(jīng)不能呼吸。當(dāng)然，我指的是**RMB**99%的程序猿除了對工資比較敏感，其實對數(shù)字通常并不感冒。上面這個簡單的數(shù)字描述，已立刻讓我們程序型的大腦短路。恨不得立刻Coar，立刻Dwlod，立刻熬夜研究。做個簡單的推算，50億次請求轉(zhuǎn)換為每個schema每秒的數(shù)據(jù)請求即PS，于是我們得到一個讓自己不能相信的數(shù)字：20TPS，每秒不到20個。Cobar最重要的特性是分庫分Cobar可以讓你把一個MySQLTable放到10個甚100個位于不同物理機上的MySQL服務(wù)器上去，而在用戶看來是一張表（邏輯表。這樣功能很有價值。比如：我們有1億的訂單，則可以劃分為10個分片，到2-10個物理機上。每個MySQL服務(wù)器的壓力減少，而系統(tǒng)的響應(yīng)時間則不會增加?？瓷先ズ芡昝赖墓δ埽依?，執(zhí)行這句SQL：100%1條數(shù)據(jù)，但事實上，CobarN條數(shù)據(jù)，N=分片個數(shù)。接下來我們繼續(xù)執(zhí)行SQL:selectselectcount(*)fromorderorderby你會發(fā)現(xiàn)奇怪的亂序現(xiàn)象，而且結(jié)果還隨機，這是因為，Cobar只是簡單的把上述SQL發(fā)給了后端N個分片對應(yīng)的MySQL服務(wù)器去執(zhí)行，然后把結(jié)果集直接輸出….再繼續(xù)看看，我們常用的Limit分頁的結(jié)果…可以么？答案是：不可以這個問題可以在客戶端程序里做些工作來解決。所以隨后出現(xiàn)了Cobar。據(jù)我所知，很多Cobar的使用者也都是自行開發(fā)了類似Cobar的工具來解決此類問題。從實際應(yīng)用效果來說，一方面，客戶端編程方式解決，度很高，Bug率也居高不下；另一方面，對于DBA和運維來說，增加了度。當(dāng)你發(fā)現(xiàn)這個問題的嚴(yán)重性，再回頭看看Cobar的文檔，你悵然若失，四顧茫然。接下來，本文將隱藏在Cobar代碼中那些不為人知的逐一披漏，你洞悉了這些，就會明白Mycat為什么會橫空COBAR的十一個第一個：cobar會假死是的，很多人遇到這個問題。如何來驗證這點呢？可以做個簡單的小實驗，假如你的分片表中配置有表,則打開ysl終端，執(zhí)行下面的SQL： 此SQL會執(zhí)行等待500秒，你再努力以最快的速度打開N個mysql終端，都執(zhí)行相同的SQL，確保當(dāng)前cobar的執(zhí)行線者試圖新建立連接，都會無法響應(yīng)，此時show@@threadpool 里面看到TASK_QUEUE_SIZE已經(jīng)在積壓中。而后端跟Mysql的交互，是阻塞模式，其NIO代碼只給出了框架，還未來得及實現(xiàn)。在代碼里，第二個：高可用的陷阱每一個的背后，總是隱藏著更大的。cobar假死的的背后，還隱藏著一個更為“強大”的秘密，那就是假死以后，cobar的頻繁主從切換問題。我們看看cobar的一個很好的優(yōu)點——“高可用性”的實現(xiàn)機制，下圖解釋cobar如何實現(xiàn)高可用性：分片節(jié)點dn2_M1配置了兩個dataSource，并且配置了心跳檢測(heartbeat)語句，在這種配置頻繁來回切換，懂得MySQL主從機制的人都知道，在兩個節(jié)點上都執(zhí)行寫操作意味著什么？——可能還有什么情況下，會導(dǎo)致心跳檢測失敗呢？這是一個不得不說的：當(dāng)后端數(shù)據(jù)庫達到最大連接后，會對建連接全，此時Cobar心跳檢測建立的連接也會，于是心跳檢測敗，于是一切都悄悄的發(fā)生了。幸好，大多數(shù)同學(xué)都沒有配置高可用性，或者還不了解此特性，因此，這個，一直在安全的沉睡。第三個：看上去很美的自動切在真實的生產(chǎn)環(huán)境中，我們通常會用至少兩個Cobar實例組成負載均衡，前端用硬件或者HA這樣的負載均衡組件，防止單點故障，這樣一來，即使某個Cobar實例死了，還有另外一臺接手，某個Mysql節(jié)點死了，切換到備節(jié)點繼續(xù)，至此，一切看起來依然很美，喝著咖啡，聽著音樂，視察，你微笑著點頭——NoprolemEvertigisOK!直到有一天，某個Cbar實例果然如你所愿的死了，不管是假死還是真死，你按照早已做好的應(yīng)急方案，優(yōu)雅的做了一個不是很艱難的決定——重啟那個故障節(jié)點，然后繼續(xù)喝著咖啡，聽著音樂，輕松寫好故障處理報告發(fā)給，然后又度過了美好的一天。你忽然被深夜一個 給驚醒，你來不及發(fā)火，因為你的告訴你，這個問題很嚴(yán)重，大量的訂單數(shù)據(jù)發(fā)生錯誤很可能是昨天重啟cobar導(dǎo)致的數(shù)據(jù)庫發(fā)生奇怪的問題。你努力排查了幾個小時，終于發(fā)現(xiàn)，主備兩個庫都在同時寫數(shù)據(jù)，主備同步失敗，你根本不知道那個庫是數(shù)據(jù)，緊急情況下，你做了一個很英明的決定，停止昨天故障的那個cobar實例，然后你花了3個通宵，解決了數(shù)據(jù)問題。這個陷阱的代價太高，不知道有多少同學(xué)中槍過，反正我也是躺著中槍過了。若你還不清楚為何會產(chǎn)生這個陷阱，現(xiàn)在我來告訴你：Cobar啟動的時候，會用默認第一個Datasource進行數(shù)據(jù)讀寫操作當(dāng)?shù)谝粋€Datasource心跳檢測失敗，會切換到第二個那么，怎么避免這個陷阱？目前只有一個辦法，節(jié)點切換以后，盡快找個合適的時間，全部集群都時重啟，避免隱患。為何是重啟而不是用節(jié)點切換令去切換？想象一下32個分片的數(shù)據(jù)庫，要多少次切MyCATproperties文件（conf下），重啟的時候，里面的節(jié)點index，真正實現(xiàn)了無故障無隱患的高可用性。第四個：只實現(xiàn)了一半的NIOJAVAJava程序員，沒聽NIO，都不好意思說自己是Java人。所以Cobar采用NIO技術(shù)并不意外，但意外的是，只用了一半。Cobar本質(zhì)上是一個“數(shù)據(jù)庫路由器”，客戶端連接Cobar，發(fā)SQL語句，CobarSQL語句通過后端MySQL的通Socket發(fā)出去，然后將結(jié)果返回Socket中。下面SQL執(zhí)行過程SQL->FrontConnection->Cobar->MySQLChanel-FrontConnectionNIOMySQLChanelIO通訊，原因很簡單，指令比較復(fù)雜，NIOBIONIO部分一個線程池，后端BIO部分一個線程池。各自相互不干擾，但這個設(shè)計的結(jié)果，導(dǎo)致了線程的浪費，BIO，所以Cobar吞吐量無法太高、另外也是其假死的根源。MyCATCobar的基礎(chǔ)上，完成了徹底的NIO通訊，并且合并了兩個線程池，這是很大一個提升。從1.1版本開始，MyCAT則徹底用了JDK7的AIO，有一個重要提升。第五個：阻塞、又見阻Cbar本質(zhì)上類似一個交換機，將后端Mysl的返回結(jié)果數(shù)據(jù)經(jīng)過加工后再寫入前端連接并返回，于是前后端連接都存在一個“寫隊列”用作緩沖，后端返回的數(shù)據(jù)發(fā)到前端連接FoConnecion的寫隊列中排隊等待被發(fā)送，而通常情況下，后端寫入的的速度要大于前端消費的速度，在跨分片查詢的情況下，這個現(xiàn)象更為明顯，于是寫線程就在這里又一次被阻塞。解決辦法有兩個，增大每個前端連接的“寫隊列”長度，減少阻塞出現(xiàn)的情況，但此辦法只是將問題拋給了使用者，要是使用者能夠知道這個寫隊列的默認值小了，然后根據(jù)情況進行手動嘗試調(diào)整也行，但Cbar的代碼中并沒有把這個問題出來，比如寫一個告警日志，隊列滿了，建議增大隊列數(shù)。于是絕大多數(shù)情況下，大家就默默的排隊阻塞，無人知曉。MyCT解決此問題的方式則更加人性化，首先將原先數(shù)組模式的固定長度的隊列改為鏈表模式，無限制，并且并發(fā)性更好，此外，為了讓用戶知道是否隊列過長了（一般是因為QL結(jié)果集返回太多，比如1萬條記錄，當(dāng)超過指定閥值（可配）后，會產(chǎn)生一個告警日志。<system><property<system><property第六個：又愛又恨的SQL批處理模正如一枚硬幣的正無法分離，一塊磁石怎樣切割都有南北極，愛情中也一樣，愛與恨總是糾纏著，無法理順，而Cobar的QL批處理模式，也恰好是這樣一個令人又愛又恨的個性。再返回處理結(jié)果，這個特性對于數(shù)據(jù)批量插入來說，性能提升很大，因此也被普遍應(yīng)用。JDBC的代碼通常StringStringsql="insertintotravelrecord(id,user_id,traveldate,fee,days)values(?,?,?,?,?)";ps=con.prepareStatement(sql);for(Map<String,String>map:{ps.setLong(1,ps.setString(2,(String)map.get("user_id"));ps.setString(4,(String)map.get("fee"));ps.setString(5,(String)map.get("days"));}但Cobar的批處理模式的實現(xiàn)，則有幾個地方是與傳統(tǒng)不同的提交到cobar的批處理中的每一條SQL批處理中的SQL并發(fā)多連接同時執(zhí)行，則意味著Bach并發(fā)執(zhí)行，則又帶來一個意外的副作用，即事務(wù)跨連接了，若一部分事務(wù)提交成功，而另一部分失敗，則導(dǎo)致臟數(shù)據(jù)問題?？吹竭@里，你是該“愛”呢還是該“恨”？先不用急著下結(jié)論，我們繼續(xù)看看Cobar的邏輯，SQL并發(fā)執(zhí)行，其實也是依次獲取獨立連接并執(zhí)行，因此還是有稍微的時間差，若某一條失敗了，則cobar會在會話中標(biāo)記”事務(wù)失敗，需要回滾“，下一個沒執(zhí)行的SQL就拋出異常并跳過執(zhí)行，客戶端就捕獲到異常，并執(zhí)行rollback，回滾事務(wù)。絕大多數(shù)情況下，數(shù)據(jù)庫正常運行，此刻沒有宕機，因此事務(wù)還是完整保證了，但萬一恰好在某個SQLcommit指令的時候宕機，于但這個概率有多大呢？一條insertinsert語句執(zhí)行commit50毫秒，100條同時提交，最長時間是5000毫秒，即5秒中，而這個C指令的時間占據(jù)程序整個插入邏輯的時間的最多20%，假99.9%0.1%×4%=99.996%的可靠性，另外一個問題，即批量執(zhí)行的SQL，通常都是insert的，插入成功就OK，失敗的怎么辦？通常會記錄最后，假如真要多個SQL使用同一個后端MYSQL連接并保持事務(wù)怎么辦？就采用通常的事務(wù)模式，單條執(zhí)行SQL，這個過程中，Cobar會采用Session中上次用過的物理連接執(zhí)行下一個SQL語句，因此，整個過第七個：庭院深深鎖清說起死鎖，貌似我們大家都只停留在很久遠的回憶中，只在教科書里看到過，也看到過關(guān)于死鎖產(chǎn)生的原因以及方法，只有DBA可能會偶爾碰到數(shù)據(jù)庫死鎖的問題。但很多用了Cobar的同學(xué)后來經(jīng)常發(fā)現(xiàn)一個奇怪的問題，SQL很久沒有應(yīng)答，百思不得其解，無奈之下找DBA排查后發(fā)現(xiàn)竟然有數(shù)據(jù)庫死鎖現(xiàn)象，而且比較頻繁發(fā)生。要搞明白為什么Cobar增加了數(shù)據(jù)庫死鎖的概率，只能從源碼分析，當(dāng)一個SQL需要拆分為多條QL去到多個分片上執(zhí)行的時候，這個執(zhí)行過程是并發(fā)執(zhí)行的，即N個QL同時在N個分片上執(zhí)行，這個過程抽象為教科書里的事務(wù)模型，就變成一個線程需要鎖定N個資源并執(zhí)行操作以后，才結(jié)束事務(wù)。當(dāng)這N個資源的鎖定順序是隨機的情況下，那么就很容易產(chǎn)生死鎖現(xiàn)象，而恰好Cbar并沒有保證N資源的鎖順序，于是們再次榮“”。第八個：出乎意料的連接數(shù)據(jù)庫連接池，可能是僅次于線程池的我們所最依賴的“資源池”，其重要性不言而喻，業(yè)界也因此而誕MySQLServer1000-3000之間，DatabaseCobar的分表分庫這里，就出現(xiàn)了問題，因為Cobar對后端MySQL的連接池管理是基于分片——Database來實現(xiàn)的，而不MySQL的連接池共享，以一個分片數(shù)為10050Server1上，就意味著Sever1上的數(shù)據(jù)庫連接被切分為50個連接池，每個池是20個左右的連接，這些連接池并不能互通，于是，在分片表的情況下，我們的并發(fā)能力被嚴(yán)重削弱。明明其他水池的水都是滿的，你卻只能守著空池子等待。第九個：無奈的熱裝載Cbar有一個優(yōu)點，配置文件熱裝載，不用重啟系統(tǒng)而熱裝載配置文件，但這里存在幾個問題，其中一個問題是很多人不滿的，即每次重載都把后端數(shù)據(jù)庫重新斷連一次，導(dǎo)致業(yè)務(wù)中斷，而很多時候，大家改配置僅僅是為了修改分片表的定義，規(guī)則，增加分片表或者分片定義，而不會改變數(shù)據(jù)庫的配置信息，這個問題由來已久，但卻不太好修復(fù)。第十個：不支持讀寫分不支持讀寫分離，可能熟悉相關(guān)中間件的同學(xué)第一反應(yīng)就是驚訝，因為一個MySQL最基本的功能就是提供讀寫分離能力，以提升系統(tǒng)的查詢吞吐量和查詢性能。但的確Cobar不支持讀寫分離，而且根據(jù)Cobar的配置文件，要實現(xiàn)讀寫分離，還很麻煩?？赡苡行┤苏J為，因為無法保證讀寫分離的時延，因此無法確定是否能查到之前寫入的數(shù)據(jù)，因此讀寫分離并不重要，但實際上，Mycat的用戶里，幾乎沒有不使用讀寫分離功能的，后來還有增加了強制查詢語句走主庫（寫庫）的功能，以解決剛才那個問題。第十一個：不可控的主從切Cbar提供了MyQL主從切換能力，這個功能很實用也很方便，但你無法控制它的切換開啟或關(guān)閉，有時候我們不想它自動切換，因為到目前為止，還沒有什么好的方法來確認MyQL寫節(jié)點宕機的時候，備節(jié)點是否已經(jīng)100%完成數(shù)據(jù)同步，因此存在數(shù)據(jù)不一致的風(fēng)險，如何更可靠的確定是否能安全切換，這個問題比較復(fù)雜，Myct也一直在努力完善這個特性。工Mycat最早的版本完成于2013年年底，實現(xiàn)于中的城。Mycat要解決的第一個問題就是要將Cobar后端實現(xiàn)為非阻塞模式。將Cobar從“個人版”提升到真正的“企業(yè)版”。據(jù) 證實的了解，非開源的Cobar內(nèi)部版本已經(jīng)實現(xiàn)后端NIO，但是并沒有開源出來。于是Mycat注定要誕生了，盡管可能不會是代碼，驚艷了。MycatOpencloudDBMycatQQMycloudOASAAS企頭銜的、超過20個“研發(fā)”頭銜的龐大團隊，然后，僅有不到3個人提交過文檔和少量代碼，其他的人MycloudOA出師未捷身先死。OpencloudDB改名為Mycat，一個原因是簡單好記，另外一個原因，是打算未來入駐Apache。因為Apache方第一萌妹子，雖然目前Rainbow大俠設(shè)計的MycatLogo，看起來是個100%的女漢子。Mycat1.0MycloudOA開發(fā)的一些小伙伴陸續(xù)加入進來，資深醬油師Michael還了一個openclouddb的，隨后又實現(xiàn)了Mycat全局序列號（基于文件方式；一些了解或使用過Cobar的同學(xué)也陸續(xù)加入，網(wǎng)名為無影的大俠，提供了最早的Mycat分頁排序的源碼，最早在生產(chǎn)系統(tǒng)上部署了Mycat并且采用HA方式做高可用方案；隨后，一個叫做小魚的PHP高手，在不到3個月時間內(nèi)，用Mycat改造了原先的系統(tǒng)。后來又有一些美容美發(fā)的SAAS創(chuàng)業(yè)項目采用了Mycat；再后來，一些比較大的電信軟件領(lǐng)域的公司和項目開始使用Mycat，他們中的大多數(shù)都對Mycat做過不少的貢獻，比如測試，Bug修復(fù)等。發(fā)展到今天，Mycat研發(fā)團隊里的大多數(shù)人，都是來自上述這些公Mycat１.3的誕生，是Mycat歷史上最重大的一個里程碑。在這個版本里，需求、測試和功能開發(fā)各項工作，首次從個人為主變?yōu)殚_源團隊為主的模式，的人參與到需求、開發(fā)、測試以及Bug修動中，基本上確定的Bug都在２４小時內(nèi)修復(fù)并有或用戶確認修復(fù)。Mycat1.3版本的性能與1.2比提升巨大，功能更完備，這是因為包括武、-研發(fā)、冰峰影、Leader-us等實力派編程高手各自負責(zé)一部分重要模塊并一起協(xié)同研發(fā)，后來又加入聆聽、從零開始、、Mclaren、兵臨城下等新的一批實力派編程PCYMycat官網(wǎng)建設(shè)、文檔編寫和翻譯的就更多了（當(dāng)然也失聯(lián)很多。截至目前，Mycat團隊有以Marshy大為首的負責(zé)官網(wǎng)和的團隊，Leader-usMycat-ServerRainbowMycat-Web的研發(fā)團隊、以海王星為首的QA團隊，以及群龍無首的測試團隊和DBA團隊。此外，Mycat開源社區(qū)正在進一步強化數(shù)據(jù)庫、智能調(diào)優(yōu)等方面的功能，未來將實現(xiàn)一鍵優(yōu)化的能力，根據(jù)到的SQL的執(zhí)行統(tǒng)計數(shù)據(jù)，自動分析熱點數(shù)據(jù)、給出建議的索引和優(yōu)化措施以及讀寫分離的建議，DBA一鍵完成優(yōu)化，數(shù)據(jù)遷移也將可以在上點擊鼠標(biāo)完成。大部分是和管理系統(tǒng)，少量是信息系統(tǒng)。比較大的系統(tǒng)中，數(shù)據(jù)規(guī)模單表單月30億。以后Mycat和Mycat社區(qū)成為IT和互聯(lián)網(wǎng)創(chuàng)業(yè)的最佳伴侶。下面信息是使用者在Mycat上公布的使用案例案例/MyCATApache/Mycat-OLTP和在互聯(lián)網(wǎng)時代，海量數(shù)據(jù)的與成為系統(tǒng)設(shè)計與使用的瓶頸問題，對于海量數(shù)據(jù)處理，按照使用場景，主要分為兩種類型：聯(lián)機事務(wù)處理（OP）和聯(lián)機分析處理（OLP。聯(lián)機事務(wù)處理（OP）也稱為面向的處理系統(tǒng)，其基本特征是原始數(shù)據(jù)可以立即傳送到計算中心進行處理，并在很短的時間內(nèi)給出處理結(jié)果。聯(lián)機分析處理（OLAP）是指通過的方式對數(shù)據(jù)進行分析、查詢和報表，可以同數(shù)據(jù)挖掘工具、統(tǒng)計分析工具配合使用，增強決策分析功能。對于兩者的主要區(qū)別可以用下表來說日常處面向?qū)崟r類應(yīng)當(dāng)前的,的細節(jié)的,二維的分歷史的,的,的集成的,統(tǒng)一的事關(guān)系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫針對上面兩類系統(tǒng)有多種技術(shù)實現(xiàn)方案，部分的數(shù)據(jù)庫主要分為兩大類：關(guān)系型數(shù)據(jù)庫 數(shù)據(jù)庫關(guān)系型數(shù)據(jù)庫，是建立在關(guān)系模型基礎(chǔ)上的數(shù)據(jù)庫，其借助于集合代數(shù)等數(shù)學(xué)概念和方法來處理數(shù)據(jù)庫中的數(shù)據(jù)。主流的oacle、DB2、MSQLSever和msl都屬于這類傳統(tǒng)數(shù)據(jù)庫。NoSQLNotOnlySQL，意思就是適用關(guān)系型數(shù)據(jù)庫的時候就使用關(guān)系型數(shù)據(jù)庫，不適用的時候也沒有必要非使用關(guān)系型數(shù)據(jù)庫不可，可以考慮使用更加合適的數(shù)據(jù)。主要分為臨時性鍵值（memcached、Redis）、永久性鍵值（ROMA、Redis、面向文檔的數(shù)據(jù)庫（MongoDB、CouchDB、面向列的數(shù)據(jù)庫（Cassandra、HBase，NoSQL都有其特有的使用場景及優(yōu)點。Ocle，msl等傳統(tǒng)的關(guān)系數(shù)據(jù)庫非常成熟并且已大規(guī)模，為什么還要用oQL數(shù)據(jù)庫呢？主要是由于隨著互聯(lián)網(wǎng)發(fā)展，數(shù)據(jù)量越來越大，對性能要求越來越高，傳統(tǒng)數(shù)據(jù)庫存在著性的缺陷，即單機（單庫）性能瓶頸，并且擴展。這樣既有單機單庫瓶頸，卻又?jǐn)U展，自然日益增長的海量數(shù)據(jù)及其性能要求，所以才會出現(xiàn)了各種不同的NoQL產(chǎn)品，NoSQL根本性的優(yōu)勢在于在云計算時代，簡單、易于大規(guī)模分布式擴展，并且讀寫性能非常高。下面分析下兩者的特點，及優(yōu)缺點關(guān)系型數(shù)據(jù)庫關(guān)系數(shù)據(jù)庫的特點是數(shù)據(jù)關(guān)系模型基于關(guān)系模型，結(jié)構(gòu)化，完整性約束基于二維表及其之間的聯(lián)系，需要連接、并、交、差、除等數(shù)據(jù)操作采用結(jié)構(gòu)化的查詢語言（SQL）做數(shù)據(jù)讀寫操作需要數(shù)據(jù)的一致性，需要事務(wù)甚至是強一致性保持?jǐn)?shù)據(jù)的一致性（事務(wù)處理可以進行join等復(fù)雜查詢?nèi)秉c數(shù)據(jù)讀寫必須經(jīng)過sql解析，大量數(shù)據(jù)、高并發(fā)下讀寫性能不足對數(shù)據(jù)做讀寫，或修改數(shù)據(jù)結(jié)構(gòu)時需要加鎖，影響并發(fā)操作無法適應(yīng)非結(jié)構(gòu)化擴展昂貴、復(fù)雜NoSQL數(shù)據(jù)NoSQL非結(jié)構(gòu)化的基于關(guān)系模型具有特有的使用場景高并發(fā)，大數(shù)據(jù)下讀寫能力較強基本支持分布式，易于擴展，可伸縮簡單，弱結(jié)構(gòu)化缺點join等復(fù)雜操作能力較弱事務(wù)支持較弱通用性差無完整約束復(fù)雜業(yè)務(wù)場景支持較差雖然在云計算時代，傳統(tǒng)數(shù)據(jù)庫存在著性的弊端，但是NSQL數(shù)據(jù)庫又無法將其替代，NoQL只能作為傳統(tǒng)數(shù)據(jù)的補充而不能將其替代，所以規(guī)避傳統(tǒng)數(shù)據(jù)庫的缺點是目前大數(shù)據(jù)時代必須要解決的問題。如果傳統(tǒng)數(shù)據(jù)易于擴展，可切分，就可以避免單機（單庫）的性能缺陷，但是由于目前開源或者的傳統(tǒng)數(shù)據(jù)庫基本不支持大規(guī)模自動擴展，所以就需要借助第來做處理，那就是本書要講的數(shù)據(jù)切分，下面就來分析一下如何進行數(shù)據(jù)切分。何為數(shù)據(jù)切分簡單來說，就是指通過某種特定的條件，將我們存放在同一個數(shù)據(jù)庫中的數(shù)據(jù)分散存放到多個數(shù)據(jù)（主機）上面，以達到分散單臺設(shè)備負載的效果數(shù)據(jù)的切分（Sharing）根據(jù)其切分規(guī)則的類型，可以分為兩種切分模式。一種是按照不同的表（或者cema）來切分到不同的數(shù)據(jù)庫（主機）之上，這種切可以稱之為數(shù)據(jù)的垂直（縱向）切分；另外一種則是根據(jù)表中的數(shù)據(jù)的邏輯關(guān)系，將同一個表中的數(shù)據(jù)按照某種條件拆分到多臺數(shù)據(jù)庫（主機）上面，這種切分稱之為數(shù)據(jù)的水平（橫向）切分。垂直切分的最大特點就是規(guī)則簡單，實施也更為方便，尤其適合各業(yè)務(wù)之間的耦合度非常低，相互影響很小，業(yè)務(wù)邏輯非常清晰的系統(tǒng)。在這種系統(tǒng)中，可以很容易做到將不同業(yè)務(wù)模塊所使用的表分拆到不同的數(shù)據(jù)庫中。根據(jù)不同的表來進行拆分，對應(yīng)用程序的影響也更小，拆分規(guī)則也會比較簡單清晰。水平切分于垂直切分相比，相對來說稍微復(fù)雜一些。因為要將同一個表中的不同數(shù)據(jù)拆分到不同的數(shù)據(jù)庫中，對于應(yīng)用程序來說，拆分規(guī)則本身就較根據(jù)表名來拆分更為復(fù)雜，后期的數(shù)據(jù)也會更為復(fù)雜一些。垂直切一個數(shù)據(jù)庫由很多表的構(gòu)成，每個表對應(yīng)著不同的業(yè)務(wù)，垂直切分是指按照業(yè)務(wù)將表進行分類，分布到不同的數(shù)據(jù)庫上面，這樣也就將數(shù)據(jù)或者說壓力分擔(dān)到不同的庫上面，如下圖：系統(tǒng)被切分成了，用戶，訂單，支付幾個模塊一個架構(gòu)設(shè)計較好的應(yīng)用系統(tǒng)，其總體功能肯定是由很多個功能模塊所組成的，而每一個功能模塊所需要的數(shù)據(jù)對應(yīng)到數(shù)據(jù)庫中就是一個或者多個表。而在架構(gòu)設(shè)計中，各個功能模塊相互之間的交互點越統(tǒng)一越少，系統(tǒng)的耦合度就越低，系統(tǒng)各個模塊的性以及擴展性也就越好。這樣的系統(tǒng)，實現(xiàn)數(shù)據(jù)的垂直切分也就越容易。但是往往系統(tǒng)之有些表難以做到完全的獨立，存在這擴庫jin的情況，對于這類的表，就需要去做平衡，是數(shù)據(jù)庫讓步業(yè)務(wù)，共用一個數(shù)據(jù)源，還是分成多個庫，業(yè)務(wù)之間通過接口來做調(diào)用。在系統(tǒng)初期，數(shù)據(jù)量比較少，或者資源有限的情況下，會選擇共用數(shù)據(jù)源，但是當(dāng)數(shù)據(jù)發(fā)展到了一定的規(guī)模，負載很大的情況，就需要必須去做分割。一般來講業(yè)務(wù)存在著復(fù)雜jin的場景是難以切分的，往往業(yè)務(wù)獨立的易于切分。如何切分，切分到何種程度是考驗技術(shù)架構(gòu)的一個難題。下面來分析下垂直切分的優(yōu)缺點：優(yōu)點拆分后業(yè)務(wù)清晰，拆分規(guī)則明確系統(tǒng)之間整合或擴展容易部分業(yè)務(wù)表無 join，只能通過接口方式解決，提高了系統(tǒng)復(fù)雜度受每種業(yè)務(wù)不同的限制存在單庫性能瓶頸，不易數(shù)據(jù)擴展跟性能提高事務(wù)處理復(fù)雜水平切相對于垂直拆分，水平拆分不是將表做分類，而是按照某個字段的某種規(guī)則來分散到多個庫之中，每個表中包含一部分?jǐn)?shù)據(jù)。簡單來說，我們可以將數(shù)據(jù)的水平切分理解為是按照數(shù)據(jù)行的切分，就是將表中的某些行切分到一個數(shù)據(jù)庫，而另外的某些行又切分到其他的數(shù)據(jù)庫中，如圖：拆分?jǐn)?shù)據(jù)就需要定義分片規(guī)則。關(guān)系型數(shù)據(jù)庫是行列的二維模型，拆分的第一原則是找到拆分維度。比如：從會員的角度來分析，商戶訂單類系統(tǒng)中查詢會員某天某月某個訂單，那么就需要按照會員結(jié)合日期來拆分，不同的數(shù)據(jù)按照會員ID做分組，這樣所有的數(shù)據(jù)查詢join都會在單庫內(nèi)解決；如果從商戶的角度來講，要查詢某個商家某天所有的訂單數(shù)，就需要按照商戶ID做拆分；但是如果系統(tǒng)既想按會員拆分，又想按商家數(shù)據(jù)，則會有一定的。如何找到合適的分片規(guī)則需要綜合考慮衡量。幾種典型的分片規(guī)則包括按照用戶 求模，將數(shù)據(jù)分散到不同的數(shù)據(jù)庫，具有相同數(shù)據(jù)用戶的數(shù)據(jù)都被分散到一個庫中按照日期，將不同月甚至日的數(shù)據(jù)分散到不同的庫中按照某個特定的字段求摸，或者根據(jù)特定范圍段分散到不同的庫中如圖，切分原則都是根據(jù)業(yè)務(wù)找到適合的切分規(guī)則分散到不同的庫，下面用用戶 求模舉例拆分規(guī)則抽象好 操作基本可以數(shù)據(jù)庫做不存在單庫大數(shù)據(jù)，高并發(fā)的性能瓶應(yīng)用端改造較少分片事務(wù)一致性難以解決數(shù)據(jù)多次擴展難度跟量極大前面講了垂直切分跟水平切分的不同跟優(yōu)缺點，會發(fā)現(xiàn)每種切分方式都有缺點，但共同的特點缺點有引入分布式事務(wù)的問跨節(jié)點合并排序分頁問題針對數(shù)據(jù)源管理，目前主要有兩種思客戶端模式，在每個應(yīng)用程序模塊中配置管理自己需要的一個（或者多個）數(shù)據(jù)源，直接各個數(shù)據(jù)庫，在模塊內(nèi)完成數(shù)據(jù)的整合；通過中間層來統(tǒng)一管理所有的數(shù)據(jù)源，后端數(shù)據(jù)庫集群對前端應(yīng)用程序透明可能90%以上的人在面對上面這兩種解決思路的時候都會傾向于選擇第二種，尤其是系統(tǒng)不斷變得龐大復(fù)雜的時候。確實，這是一個非常正確的選擇，雖然短期內(nèi)需要付出的成本可能會相對更大一些，但是對整個系統(tǒng)的擴展性來說，是非常有幫助的。Myct通過數(shù)據(jù)切分解決傳統(tǒng)數(shù)據(jù)庫的缺陷，又有了oQL易于擴展的優(yōu)點。通過中間層規(guī)避了多數(shù)據(jù)源的處理問題，對應(yīng)用完全透明，同時對數(shù)據(jù)切分后存在的問題，也做了解決方案。下面章節(jié)就分析，mct的由來及如何進行數(shù)據(jù)切分問題。由于數(shù)據(jù)切分后數(shù)據(jù)Join的難度在此也一下數(shù)據(jù)切分的經(jīng)驗：第第二原則：如果要切分一定要選擇合適的切分規(guī)則，提前規(guī)劃好第三原則：數(shù)據(jù)切分盡量通過數(shù)據(jù)冗余或表分組（TableGroup）來降低跨庫Join的可能第四原則：由于數(shù)據(jù)庫中間件對數(shù)據(jù)Jin實現(xiàn)的優(yōu)劣難以把握，而且實現(xiàn)高性能難度極大，業(yè)務(wù)盡量少使用多表in。MYCATMycat是什么？從定義和分類來看，它是一個開源的分布式數(shù)據(jù)庫系統(tǒng)，是一個實現(xiàn)了MySQL協(xié)議的的Server，前端用戶可以把它看作是一個數(shù)據(jù)庫，用MySQL客戶端工具和命令行，而其后端可以MySQL原生（Native）MySQLJDBC協(xié)議與大多數(shù)主流數(shù)據(jù)庫服務(wù)器通信，其功能是分表分庫，即將一個大表水平分割為N個小表，在后端MySQL服務(wù)器里或者其他數(shù)據(jù)類型的。而在最終用戶看來，無論是那種方式，在Mycat里，都是一個傳統(tǒng)的數(shù)據(jù)庫表，支持標(biāo)在測試階段，可以將一個表定義為任何一種Mycat支持的方式，比如MySQL的MyASIM表、內(nèi)存表、上，大量讀頻率遠超過寫頻率的數(shù)據(jù)如訂單的快照數(shù)據(jù)存放于InnoDB中，一些日志數(shù)據(jù)存放于MongoDBOracleMySQL的表做關(guān)聯(lián)查詢，你是否有一種不能呼吸的感覺？而未來，還能通過Mycat自動將一些計算分析后的數(shù)據(jù)灌入到HadoopMycat+Storm/SparkStream引擎做大規(guī)模數(shù)據(jù)分析，看到這里，你大概明白了，Mycat是什么？Mycat就是BigSQL，BigDataOnSQLDatabase。 ）對于DBA來說，可以這 ）MycatMycatMySQLServerMycatMySQLServerMySQL引擎,MyISAM等，因此，Mycat本身并 MySQLMycatMySQLMySQLOraclePK的能力。對于軟件工程師來說，可以這么理解MycatMycat就是一個近似等于MySQL的數(shù)據(jù)庫服務(wù)器，你可以用連接MySQL的方式去連接Mycat（除了端口不同，默Mycat端口8066而非MySQL3306，因此需要在連接字符串上增加端口信息，大多數(shù)情況下，可以用你熟悉的對象映射框架使用Mycat，但建議對于分片表，盡量使用基礎(chǔ)的SQL語句，因為這樣對于架構(gòu)師來說，可以這么理解MycatMycatMycat當(dāng)前是個大數(shù)據(jù)的時代，但究竟怎樣規(guī)模的數(shù)據(jù)適合數(shù)據(jù)庫系統(tǒng)呢？對此，國外有一個數(shù)據(jù)庫領(lǐng)域的說了一個結(jié)論：千億以下的數(shù)據(jù)規(guī)模仍然是數(shù)據(jù)庫領(lǐng)域的專長，而Hadoop等這種系統(tǒng)，更適合的是千億以上的規(guī)模。所以，Mycat適合1000億條以下的單表規(guī)模，如果你的數(shù)據(jù)超過了這個規(guī)模，請投靠MycatPlus吧！MYCATMycat的原理并不復(fù)雜，復(fù)雜的是代碼，如果代碼也不復(fù)雜，那么早就成為一個了。Mycat的原理如分片分析、路由分析、讀寫分離分析、緩存分析等，然后將此SQL發(fā)往后端的真實數(shù)據(jù)庫，并將返回的上述里，Orders表被分為三個分片datanode（簡稱dn)，這三個分片是分布在兩臺MySQL上(DataHost)，即datanode=database@datahost方式，因此你可以用一臺到N臺服務(wù)器來分片，分片規(guī)則（shardingrule)典型的字符串枚舉分片規(guī)則，一個規(guī)則的定義是分片字段（shardingcolumn)+分片函數(shù)(rulefunction)，這里的分片字段為prov而分片函數(shù)為字符串枚舉方式。SQLSQLSQL發(fā)往這些分片select*fromOrderswhereprov=?prov=wuhan，按照分片函數(shù)，wuhandn1SQLMySQL1DB1上,語法，此時就涉及到結(jié)果集在Mycat端的二次處理，這部分的代碼也比較復(fù)雜，而最復(fù)雜的則屬兩個表的Jion問題，為此，Mycat提出了創(chuàng)新性的ER分片、全局表、HBT（HumanBrainTech)人工智能的Catlet、以及結(jié)合Storm/Spark 引擎等十八般武藝的解決辦法，從而成為目前業(yè)界最強大的方案，這就是開源的力量！應(yīng)用場Mycat發(fā)展到現(xiàn)在，適用的場景已經(jīng)很豐富，而且不斷有新用戶給出新的創(chuàng)新性的方案，以下是幾個典型單純的讀寫分離，此時配置最為簡單，支持讀寫分離，主從切分表分庫，對于超過1000萬的表進行分片，最大支持1000億的單表分多租戶應(yīng)用，每個應(yīng)用一個庫，但應(yīng)用程序只連 Mycat，從而不改造程序本身，實現(xiàn)多租戶報表系統(tǒng)，借助于Mycat的分表能力，處理大規(guī)模報表的統(tǒng)替代Hbase，分析大數(shù)結(jié)果，除了基于主鍵的查詢，還可能存在范圍查詢或其他屬性查詢，此時Mycat可能是最簡單有效的選擇。MYCAT強化分布式數(shù)據(jù)庫中間件的方面的功能，使之具備豐富的插件、強大的數(shù)據(jù)庫智能優(yōu)化功能、全面的系統(tǒng) 能力、以及方便的數(shù)據(jù)運維工具，實現(xiàn)數(shù)據(jù)擴容、遷移等高級功能進一步挺進大數(shù)據(jù)計算領(lǐng)域，深度結(jié)合SparkStream和Storm等分布式實時流引擎，能夠完成快速的巨表關(guān)聯(lián)、排序、分組聚合等OLAP方向的能力，并集成一些熱門常用的實時分析算法，讓工程師以及DBA們更容易用Mycat實現(xiàn)一些高級數(shù)據(jù)分析處理功能。并將Mycat推到Apache，成為國內(nèi)頂尖開源項目，最終能夠讓一部分成為專職的Mycat開依托Mycat社區(qū)，100個CXO級別的精英，眾籌建設(shè)親親山莊，Mycat社區(qū)+親親山莊=中國最大ITO2O社區(qū)版本選擇與升級指版本選Mycat已經(jīng)1.4版本預(yù)計本書發(fā)布不久后就可以發(fā)1.4alpha版本，1.4幾乎完全兼容之前所有版本，如果你是研究階段可以用1.4作為研究1.3是最穩(wěn)定的版本，可以放心用于生產(chǎn)，1.3系列只做bug修復(fù)，不再進行功能升級，如果需要的功能可以用1.4。Mycat1.2中的功能ER讀寫分離支不支持手動選擇select走寫節(jié)點，如果需要select走寫節(jié)點需要添加事務(wù)。全局序列號與自增主鍵支持，分為本地文件與數(shù)據(jù)庫兩種方式默認sql解析器為founddbMycat1.3中的功能dump批量導(dǎo)入，導(dǎo)入列必須指定insertvalues 多數(shù)據(jù)庫支持，部分分頁特性不支持主鍵緩存只能路由優(yōu)增加LockTable和UnlockTables語句支持多租戶實現(xiàn)默認sql解析器為Druid，sql的兼容性進一步提高節(jié)點通配方式為dataNode="distribute(dn1$0-371,dn11$0-371)"rule="latest-month-calldate"/><dataNodename="dn1"dataHost="localhost1"database="db$0-371"<dataNodename="dn11"dataHost="localhost2"database="db$0-371"有表必須配置。mycat1.4中的功能：loaddatasqljdbc自主主鍵支持批量插新增分片規(guī)則dataNode節(jié)點的通配配置同一個dataHost上有多個<dataNodename=“dn$1-3”<dataNodename=“dn$1-3”dataHost=“test1”database=“base$1-3”<dataNodename=“dn1”dataHost=“test1”database=“base1”<dataNodename=“dn2”dataHost=“test1”database=“base2”<dataNodename=“dn3”dataHost=“test1”database=“base3”多個dataHost上有相同的<dataNode<dataNodename=“dn$1-3”dataHost=“test$1-3”database=“base”等價于3個節(jié)點，其中name和dataHost中的通配數(shù)量必須相等<dataNodename=“dn1”dataHost=“test1”database=“base”<dataNodename=“dn2”dataHost=“test2”database=“base”<dataNodename=“dn3”dataHost=“test3”database=“base” 多個dataHost上有相同的多個datahostdatabase<dataNodename=“dn1”dataHost=“test1”database=“base1”<dataNodename=“dn2”dataHost=“test1”database=“base2”<dataNodename=“dn3”dataHost=“test2”database=“base1”<dataNodename=“dn4”dataHost=“test2”database=“base2”<dataNodename=“dn5”dataHost=“test3”database=“base1”<dataNodename=“dn6”dataHost=“test3”database=“base2”63dataHostdataHost2databasename<dataNodename=“dn$1-6”dataHost=“test$1-3”database=“base$1-2”支持MySQL主從狀態(tài)綁定的讀寫分離機表的節(jié)點配置中，添加對不分片的表不配置，走默認節(jié)點支持升級指linux中，直接wget，windows，右鍵另存為。 Resolving ...Connectingtoraw.git HTTPrequestsent,awaitingresponse...200OK Savingto:“Mycat-server-1.4-RC-20150623170038-======>] in [root@vm00~]#ll-hMycat-server-1.4-RC-20150623170038- 確認大小是否正建立一個新的這里主要是為了保證不破環(huán)1.3的環(huán)境。新建一 [root@vm00[root@vm00~]#mkdir[root@vm00~]#tar-xfMycat-server-1.4-RC-20150623170038-linux.tar.gz-C/usr/local/mycat1.4[root@vm00~]#ls/usr/local/mycat1.4/mycat/ [root@vm00~]#cat/usr/local/mycat1.4/mycat/version.txt 2015-06-2309:00:32 MavenVersion1.4-RC MyCatSitehttp:/ 修改配置文件在修改之前，我們最好保留一份備份然后使用原配置文件（1.3版本的，替換新的配置文件（剛解壓出來的1.4版本的 cp:overwrite`/usr/local/mycat1.4/mycat/conf/schema.xml'?yes cp:overwrite`/usr/local/mycat1.4/mycat/conf/server.xml'?yes cp/usr/local/mycat/conf/rule.xmlcp:overwrite`/usr/local/mycat1.4/mycat/conf/rule.xml'?啟動之前，先停掉mycat1.3的進程[root@vm00[root@vm00mycat]#/usr/local/mycat1.4/mycat/bin/mycatStartingStartingMycat-登陸簡單測試Enter etotheMySQLmonitor.Commandsendwith;or\g.YourMySQLconnectionidis2CopyrightCopyright(c)2000,2013,Oracleand/oritsaffiliates.All.OracleisaregisteredtrademarkofOracleCorporationand/oritsaffiliates.Othernamesmaybetrademarksoftheirrespectiveowners.mysql>mysql>showType'help;'or'\h'forhelp.Type'\c'toclearthecurrentinput | 1rowinset(0.01ReadingtableinformationforcompletionoftableandcolumnnamesYoucanturnoffthisfeaturetogetaquickerstartupwith-ADatabasechanged |Tablesint_mycat | | | | | 6rowsinset(0.00mysql>select*from | |city_code|city_name 1 101| 2 102| 300 103| 600 104| |1000 105|shenzheng 5rowsinset(0.17 |NAME|DATHOST |INDEX|TYPE |ACTIVE|IDLE|SIZE|EXECUTE|TOTAL_TIME|MAX_TIME|MAX_SQL|RECOVERY_TIME| | 0|mysql 0 5|1000 5 0 000 -1| 0|mysql 0 5|1000 53 0 000 -1| 0|mysql 0 5|1000 5 0 000 -1| 0|mysql 0 6|1000 54 0 000 -1| 0|mysql 0 5|1000 5 0 000 -1| 0|mysql 0 6|1000 54 0 000 -1| 0|mysql 0 5|1000 6 0 000 -1| 0|mysql 0 6|1000 54 0 00-1++ +++++++++8rowsinset(0.02 | | |PORT| |ACTIVE|IDLE|SIZE|EXECUTE | |hostM1|mysql|55|3306| 0 11|1000 67| |hostM1|mysql|54|3306| 0 11|1000 66| |hostM1|mysql|55|3306| 0 11|1000 67| |hostM1|mysql|53|3306| 0 11|1000 66| |hostM1|mysql|54|3306| 0 11|1000 66| |hostM1|mysql|52|3306| 0 10|1000 65| |hostM2|mysql|51|3306| 0 1|1000 55| |hostM1|mysql|53|3306| 0 11|1000 66| |hostM1|mysql|52|3306| 0 10|1000 65| |hostM2|mysql|51|3306| 0 1|1000 55 10rowsinset(0.01OK，升級完成小目前 版本比1.2穩(wěn)定性有很大提高，但是支持的特性也有很大提高，建議升級到穩(wěn)版版本中為最穩(wěn)定版本，存在較多bug，以廢棄不建議使用為目前的開發(fā)版本，進一步加強了新特性，如果是項目屬于開發(fā)階段可以研 1.4，等到代碼開完畢1.4預(yù)計發(fā)布穩(wěn)定版本，目前的1.4開發(fā)版本存在部分bug，如果擔(dān)心生產(chǎn)問題可以使用1.3版本期建議升級各版本的升級直接到對應(yīng)版本的更新日期版本進行升級/MyCATApache/Mycat-MYCAT數(shù)據(jù)庫中間前面講了Mct是一個開源的分布式數(shù)據(jù)庫系統(tǒng)，但是由于真正的數(shù)據(jù)庫需要引擎，而Myct并沒有引擎，所以并不是完全意義的分布式數(shù)據(jù)庫系統(tǒng)。那么Myct是什么？Mcat是數(shù)據(jù)庫中間件，就是介于數(shù)據(jù)庫與應(yīng)用之間，進行數(shù)據(jù)處理與交互的中間服務(wù)。由于前面講的對數(shù)據(jù)進行分片處理之后，從原有的一個庫，被切分為多個分片數(shù)據(jù)庫，所有的分片數(shù)據(jù)庫集群構(gòu)成了整個完整的數(shù)據(jù)庫。如上圖所表示，數(shù)據(jù)被分到多個分片數(shù)據(jù)庫后，應(yīng)用如果需要數(shù)據(jù)，就要需要處理多個數(shù)據(jù)源的數(shù)據(jù)。如果沒有數(shù)據(jù)庫中間件，那么應(yīng)用將直接面對分片集群，數(shù)據(jù)源切換、事務(wù)處理、數(shù)據(jù)聚合都需要應(yīng)用直接處理，原本該是專注于業(yè)務(wù)的應(yīng)用，將會花大量的工作來處理分片后的問題，最重要的是每個應(yīng)用處理將是完全的重復(fù)造。所以有了數(shù)據(jù)庫中間件，應(yīng)用只需要集中與業(yè)務(wù)處理，大量的通用的數(shù)據(jù)聚合，事務(wù)，數(shù)據(jù)源切換都由中間件來處理，中間件的性能與處理能力將直接決定應(yīng)用的讀寫性能，所以一款好的數(shù)據(jù)庫中間件至關(guān)重要。邏輯庫前面一節(jié)講了數(shù)據(jù)庫中間件，通常對實際應(yīng)用來說，并不需要知道中間件的存在，業(yè)務(wù)開發(fā)人員只需要知道數(shù)據(jù)庫的概念，所以數(shù)據(jù)庫中間件可以被看做是一個或多個數(shù)據(jù)庫集群構(gòu)成的邏輯庫。在云計算時代，數(shù)據(jù)庫中間件可以以多租戶的形式給一個或多個應(yīng)用提供服務(wù)，每個應(yīng)用的可能是一個獨立或者是共享的物理庫，常見的如阿里云數(shù)據(jù)庫服務(wù)器RDS。邏輯表既然有邏輯庫，那么就會有邏輯表，分布式數(shù)據(jù)庫中，對應(yīng)用來說，讀寫數(shù)據(jù)的表就是邏輯表。邏輯表，可以是數(shù)據(jù)切分后，分布在一個或多個分片庫中，也可以不做數(shù)據(jù)切分，不分片，只有一個表構(gòu)成。分片分片表，是指那些原有的很大數(shù)據(jù)的表，需要切分到多個數(shù)據(jù)庫的表，這樣，每個分片都有一部分?jǐn)?shù)據(jù)，所有分片構(gòu)成了完整的數(shù)據(jù)。例如在mycat配置中的t_node就屬于分片表，數(shù)據(jù)按照規(guī)則被分到dn1,dn2兩個分片節(jié)點上<table<tablename="t