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

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