引子

分布式數(shù)據(jù)庫，已經(jīng)進(jìn)入了全面快速發(fā)展階段，這種發(fā)展，是與時俱進(jìn)的，與人的需求是分不開的，因為現(xiàn)在信息時代的高速發(fā)展，導(dǎo)致數(shù)據(jù)量和交易量越來越大。這種現(xiàn)象首先導(dǎo)致的就是存儲瓶頸，因為MySQL數(shù)據(jù)庫，實質(zhì)上，還是一個單機(jī)版本的數(shù)據(jù)庫，而只要是單機(jī)，就必然會遇到的一個問題就是存儲問題，因為存儲是硬需求，而CPU和內(nèi)存如果不夠的話，只是性能不好，并不會直接否定方案或者架構(gòu)。

存儲問題的解決，其實我們每一家公司或者個人，都一直在努力著。解決方案大概有三個方面：

增大磁盤

這種方式，應(yīng)該是最直接，最簡單的方案了，因為磁盤空間不足了，當(dāng)然加磁盤是手到病除，比如現(xiàn)在是800G，可以增加到2T，這是沒問題的，如果現(xiàn)在已經(jīng)達(dá)到了2T，當(dāng)然，還是可以增加到5T的盤，但實際上，這個時候可能DBA就要捏把汗了，這么大數(shù)據(jù)量的MySQL實例，如何運維?如果數(shù)據(jù)壞了，如何恢復(fù)呢?時間成本呢?5T的數(shù)據(jù)量，已經(jīng)非常嚇人了，估計在業(yè)內(nèi)各大公司，沒有DBA想要自己運維的MySQL實例達(dá)到這個量級吧?其實我個人認(rèn)為，這個已經(jīng)是不能接受的量了，最合適的***保持在1T以下即可。超過這個就要想辦法了。當(dāng)然這個數(shù)據(jù)量不宜達(dá)到這個大小的原因，可能會有人考慮到這是性能的問題，其實不然，或者性能問題很小，因為InnoDB采用的是B+樹的存儲方案，小表最壞情況下沒有查到數(shù)據(jù)是要找3層，也就是3個頁面的IO，而大表需要的是4個頁面的IO，影響不大。

數(shù)據(jù)壓縮

為了減少數(shù)據(jù)對磁盤空間的占用，我們通常也會將數(shù)據(jù)做壓縮處理，通過一個語句即可搞定，是InnoDB原生支持的一種方式，一般情況下，會將數(shù)據(jù)占用減少到原來的三分之一到一半不等，效果還是足夠明顯的，不過這樣處理之后的數(shù)據(jù)，在性能上會有所下降，對于響應(yīng)要求比較高的業(yè)務(wù)，可能需要謹(jǐn)慎考慮一下，但這種方式，可能還是治標(biāo)不治本，在數(shù)據(jù)量繼續(xù)增長的情況下，過段時間之后，依然面臨相同的問題，這種情況下，就不能繼續(xù)使用這種方式來實現(xiàn)了。

數(shù)據(jù)分片

數(shù)據(jù)分片的解決方案，現(xiàn)在業(yè)內(nèi)也用得很多，這種方案已經(jīng)超出了MySQL本身，包括HBase、Redis等也都在使用這種方案，應(yīng)該說這種方案是***擴(kuò)展性的，并且可以稱得上是***擴(kuò)展，而上面兩種方案，根本談不上擴(kuò)展性。所以這種方案在業(yè)內(nèi)成為主流，并且這種方案才能稱得上是分布式存儲，具體的實現(xiàn)也層出不窮，當(dāng)然也存在優(yōu)秀的分布式解決方案，也存在一些“偽”分布式方案了。

分布式解決方案需求

擴(kuò)展性

使用分布式，其實最主要的就是擴(kuò)展性，如果空間不足了，可以很方便容易的擴(kuò)展節(jié)點個數(shù)，并且將數(shù)據(jù)做新的平衡處理。這個過程要不影響業(yè)務(wù)使用，對業(yè)務(wù)透明。

支持事務(wù)

分布式數(shù)據(jù)庫，對于業(yè)務(wù)本身，使用方面與單機(jī)區(qū)別不大，也就是對業(yè)務(wù)透明，因為使用MySQL是支持事務(wù)的，那么MySQL變身為分布式之后，事務(wù)特性還是不能少的，所以整體上看來，還是要支持分布式事務(wù)。

SQL語句***制

業(yè)務(wù)需求的多樣性，導(dǎo)致在SQL需求上面，都是比較廣泛的，針對業(yè)務(wù)的透明性，如果某些SQL語句不支持，那這樣導(dǎo)致的問題是，一方面，限制了業(yè)務(wù)程序的功能和性能，另一方面，導(dǎo)致業(yè)務(wù)程序與“分布式數(shù)據(jù)庫”的捆綁問題。

性能足夠好

使用分布式數(shù)據(jù)庫，其實基本上是對性能的要求比較低的業(yè)務(wù)才會這樣選擇，即使是這樣，還是性能越高，越多人才會選擇這樣的分布式數(shù)據(jù)庫。

元數(shù)據(jù)變更透明性

元數(shù)據(jù)變更，在任何數(shù)據(jù)庫中都是存在的，在單點情況下，改表操作我們有多種友好的方法來實現(xiàn)，但到了分布式環(huán)境下，可能這種操作就成為了問題，因為數(shù)據(jù)的分片導(dǎo)致了元數(shù)據(jù)的變更需要多點修改，進(jìn)而很多問題就來了，比如原子性、數(shù)據(jù)可見性、正確性等等，所以這是最基本的問題。

底層數(shù)據(jù)庫的高可用性

話說經(jīng)濟(jì)基礎(chǔ)決定上層建筑，在分布式數(shù)據(jù)庫中也是一樣的，如果底層數(shù)據(jù)庫的不穩(wěn)定，或者數(shù)據(jù)復(fù)制延遲，亦或出現(xiàn)數(shù)據(jù)不一致的問題，則上層應(yīng)用的訪問正確性就沒法保證，所以底層數(shù)據(jù)庫最基本的就是保證數(shù)據(jù)一致性(高可用)。

流行分布式數(shù)據(jù)庫解決方案

中間件分庫分表(偽分布式)

在MySQL界，一個存在很久的話題，就是：

哪個中間件實現(xiàn)的分庫分表方案比較好啊?

當(dāng)然對于同一個問題，不同人有不同的理解，也都具有兩面性的特征，有人說好，也有人說不好，我們首先看一下這種方案是如何實現(xiàn)的。 

MyCat的實現(xiàn)架構(gòu)大概上上圖所示，其實如果只看圖的話，這樣的架構(gòu)真是***無缺，自動分片，自動聚合，分布均衡都實現(xiàn)的非常好。但事實并非如此。

我們可以通過問答的方式，一步步認(rèn)清楚這種方式的核心問題：

MyCat如何知道數(shù)據(jù)分片原理，或者說他是如何決定路由路徑的?

這個問題，在圖上面是看不出來的，MyCat是如何定義或者決定一條SQL語句的執(zhí)行方式，或者如何決定去哪里取數(shù)據(jù)及寫入到哪里的?解決這樣的問題是需要某一個地方來存儲的，它的做法是——schema.xml配置文件，竟然用配置文件來搞定。那這樣問題就多了，修改分庫分表規(guī)則之后，如何保證配置與數(shù)據(jù)同步更新?即使不使用schema.xml配置文件，而是用數(shù)據(jù)庫存儲，那配置規(guī)則的變更與數(shù)據(jù)節(jié)節(jié)點中數(shù)據(jù)的遷移，也是沒辦法保證統(tǒng)一的，勢必會對業(yè)務(wù)造成影響。

如果需要擴(kuò)展節(jié)點了，并且需要做rebalance，如何來做?

很多用戶，基本都是重新準(zhǔn)備一套集群，或者先把數(shù)據(jù)一點點手動導(dǎo)出導(dǎo)入，導(dǎo)到目標(biāo)節(jié)點之后，然后去手動修改schema.xml配置文件，然后做一次reload操作，這樣就實現(xiàn)了重新路由，但這樣同樣會導(dǎo)致上面的結(jié)果。并且這個過程，需要處理好多數(shù)據(jù)，處理完成之后各種檢查，并且占用空間需要兩倍，這樣折騰，一個DBA只要干一次，可能就有辭職的沖動。

全局表是什么東西?

MyCat支持一個所謂的全局表，用來解決跨節(jié)點數(shù)據(jù)聚合的問題，實現(xiàn)方法是在每一個分片上面，都創(chuàng)建這樣的全局表，它的定義是不怎么修改，查詢比較頻繁表可以定義為全局表，這樣的話在每一個分片節(jié)點上，只要用到這個表，就可以實現(xiàn)本地查詢連接等操作，是可以解決部分問題，但問題是如果分片多的話(假如分片100個)，如何保證數(shù)據(jù)一致性?這么多節(jié)點的XA事務(wù)影響是什么?如果出現(xiàn)不一致或者訪問錯誤，引起的問題就是數(shù)據(jù)結(jié)果錯誤，這樣的結(jié)果肯定不是業(yè)務(wù)想要看到的吧?這還不是最關(guān)鍵的，一個數(shù)據(jù)庫集群，搞這么一個特殊處理的東西是何道理?

MyCat究竟做了什么事情?

作為一個中間層，本職工作應(yīng)該是接收客戶端的SQL請求，然后通過語法分析，根據(jù)讀寫原則，然后確定一個集群中一個讀寫節(jié)點即可，然后就等著結(jié)果集的返回，對于結(jié)果集本身，中間層并不需要去關(guān)心，他只需要將結(jié)果集(或者異常)原原本本發(fā)回給客戶端即可。而MyCat做的事情，遠(yuǎn)比這個多，在語法分析之后，再做語義分析，拿到對應(yīng)數(shù)據(jù)庫表結(jié)構(gòu)，同時判斷這個表的分發(fā)路由規(guī)則，再找到語句中的數(shù)據(jù)及涉及到的列，再決定路由到哪個分片中，如果在分發(fā)時路由規(guī)則配置錯誤，或者程序計算錯誤，會導(dǎo)致整個語句的結(jié)果出現(xiàn)不可預(yù)知的問題。請問這前半部分，是一個中間層應(yīng)該做的事情么?竟然還要關(guān)心語句中涉及到的表結(jié)構(gòu)，主鍵，數(shù)據(jù)等信息，這其實都是數(shù)據(jù)庫要做的事情啊，實則是越俎代庖，再請問，所做的這些事情，能比一個專業(yè)數(shù)據(jù)庫做得更好么?咱再看后半部分，等收到結(jié)果集之后，MyCat為了處理一些結(jié)果集的聚合計算，需要把各個節(jié)點本來已經(jīng)封裝好的結(jié)果集(二進(jìn)制MySQL協(xié)議流數(shù)據(jù))，解析出來，然后通過需要計算出來(這個計算有可能非常慢，并且不是所有的都可以搞定)，計算完成之后，再打包成MySQL協(xié)議流數(shù)據(jù)，傳給客戶端，請問這樣的中間層，做了這么多事情，性能如何保證?而本身這些聚合計算Order By、Group By的處理，本身是數(shù)據(jù)庫的事情，實則還是越俎代庖。

通過SQL語句的變換，實現(xiàn)分布式是不是有點困難?

MyCat這種中間層，代表了宣稱分布式數(shù)據(jù)庫的一類使用方式，但這種實現(xiàn)方法實際上都是通過在SQL語句上做文章，從客戶端拿到的是SQL語句，給后端數(shù)據(jù)庫的也是SQL語句，但這兩個SQL語句是經(jīng)過變換的，當(dāng)然這種方法也只能這樣，因為后端數(shù)據(jù)庫只接收SQL語句，試問，一個復(fù)雜的SQL語句查詢操作，通過SQL變換或重寫，就能實現(xiàn)對不同分片數(shù)據(jù)庫的分布式查詢?想想就清楚了，雖然SQL語句通用靈活，但可擴(kuò)展性或者重寫的邏輯還是有點復(fù)雜的吧?當(dāng)然了，有人可能會說，我們有兜底的啊，大不了把這個語句就改一下庫名表名然后其它保持不變分給每一個節(jié)點去執(zhí)行，這樣總沒問題吧，是的，你說的沒錯。

在同一個事務(wù)中要修改不同節(jié)點的數(shù)據(jù)是如何處理的?

這個問題就是我們通常所說的分布式事務(wù)了，究竟是怎么回事呢，MyCat下面對的是MySQL Server，也就是說MyCat只能用SQL語句與MySQL Server交流，這樣就是局限于MySQL的SQL語句的功能了，那在分布式實現(xiàn)上面，MySQL XA本身有多少人用，MyCat如果實現(xiàn)一個跨節(jié)點的數(shù)據(jù)更新，不用MySQL XA，還能用其它什么?別無他選，本身依賴一個沒有太多人用，并且可能存在很多問題，包括性能，Bug的功能，這樣上層MyCat乃至應(yīng)用程序的可靠性如何保證?當(dāng)然基于這些問題，有些方案選擇不用XA，如果某些節(jié)點失敗了，選擇忽略不解決，這當(dāng)然也可以，妥協(xié)嘛————不需要底線的。

MyCat后端數(shù)據(jù)庫的架構(gòu)是什么，如何保證穩(wěn)定可靠高可用?

這個據(jù)某些文章宣傳說，之前可以選擇主從復(fù)制，現(xiàn)在可以選擇Galera Cluster，或者也可以選擇更新的MGR，當(dāng)然不得不說，從前到后，可能確實保證了更好的可靠性，但有一個很大的問題是，Galera的門檻比較高，遇到問題的話，很少人能解決掉(很自豪的是，去哪兒可以稱得上全球為數(shù)不多的使用Galera比較多并且使用的比較好的公司)，再到MGR，本身還得等，能用還要比較長的時間，這問題還是要回到主從復(fù)制，這是老問題了，主從復(fù)制的一致性很難保證，MyCat如果通過讀寫分離策略將讀打到從上面，而這個正好有延遲，這樣產(chǎn)生的后果可能是整個應(yīng)用程序的計算結(jié)果是錯誤的，當(dāng)然可以說有延遲檢查，那問題是，延遲檢查的話，是不是還有一個參數(shù)可以配置呢?如果延遲超過100秒的話就去查主庫?沒錯，不過100秒難道就不是延遲了?那可以設(shè)置為0，看到的0，你以為真的是0?其實還是主從復(fù)制的劣根性。所以問題還是回到了起點，經(jīng)濟(jì)基礎(chǔ)決定上層建筑，基礎(chǔ)不好，上層如何是好?

分片多了的情況下，性能是如何保證損失最小的?

這個問題，我并不知道MyCat有沒有做過優(yōu)化，比如10個分片，如果一個語句的執(zhí)行會涉及到這十個分片，那在每個分片上重寫語句之后，就要分別在這十個分片上執(zhí)行對應(yīng)的語句了，執(zhí)行時是串行，還是并行?串行的話，性能必然會下降10倍以上，所以做得好點的話，就是并行了，但并行的實現(xiàn)方法是，在MyCat這個連接上面，創(chuàng)建10個線程，去處理這十個節(jié)點的執(zhí)行情況，那這樣的連接多了，MyCat產(chǎn)生的對系統(tǒng)的沖擊就非常大了，性能還是不行。當(dāng)然也可以說，這里做了連接池，沒錯，是可以的，但MyCat是這樣做的么?這樣做了性能又如何呢?如果有一個超時，整個訪問就失敗了。

配置文件或者配置庫出問題，整個集群會出現(xiàn)什么情況?

前面已經(jīng)說了，MyCat用的是schema.xml來配置的分庫分表策略，這是一個配置文件，MyCat本身的高可用，如果配置多套的話，他們的同步問題，是如何解決的?如果沒有同步(或者同步出問題，或者延遲等)，某一個MyCat掛了，業(yè)務(wù)切換到其它的MyCat時，此時的情況就是，故障……故障……。因為數(shù)據(jù)都亂了。有可能造成的問題是，寫入了錯誤的位置，進(jìn)而導(dǎo)致整個集群的數(shù)據(jù)被寫壞。感覺比直接被刪了還嚴(yán)重。同樣的問題，感覺MyCat可能會優(yōu)化這點，也許會改為將其集中存儲在某一個數(shù)據(jù)庫中，這樣集中管理的話就不需要同步了，想法是好的，但這相當(dāng)于是把雞蛋放在一個籃子里面了，如果這個配置庫出問題了，業(yè)務(wù)何去何從?

DDL如何進(jìn)行?

這個問題也許是每個人都關(guān)心的事情了，MyCat把數(shù)據(jù)都分而不相關(guān)的分片MySQL節(jié)點了，這樣很多在單點上的改表策略都不能用了，而DDL又是一個必須要保證每個節(jié)點同時完成的事情，那在分布式上面是如何保證的呢?根據(jù)我的調(diào)研，好像現(xiàn)在使用MyCat的人，都是通過“同一時刻啟動在每一個節(jié)點上更新表結(jié)構(gòu)”這樣的方法來做的，當(dāng)然還得選擇是半夜，當(dāng)然我個人覺得也是可行的，因為畢竟已經(jīng)使用了它，而沒有更好的辦法來解決這個問題。當(dāng)然咱再說后果，如果做不到無縫原子修改，那對業(yè)務(wù)的影響不是一星半點，可能會有很多SQL會報表不存在的問題。如果一個語句和另一個語句修改完成時間相差比較多的話，兩個相減的時間就是故障時間了。

據(jù)我調(diào)研，MyCat還實現(xiàn)了自動故障切換的功能，請問這個靠譜么?

我們現(xiàn)在討論的是分布式架構(gòu)方案，而這個問題講的情況是，某一個MyCat發(fā)現(xiàn)了后端數(shù)據(jù)庫連不上了，會自動切換的功能，這就非常明顯了，我們要的是分布式，某“一個”MyCat節(jié)點認(rèn)為的問題就真的是他所認(rèn)為的嗎?也就是說，一個節(jié)點并不能保證他判斷的或者他看到的現(xiàn)象是真實的，那這種情況下就存在誤切換的情況，而如果其它中間層節(jié)點還不知道這個情況，或者未及時收到切換的消息，就出現(xiàn)了多點寫入的問題，挺可怕的。這不是自相矛盾嗎?我們要的是分布式，結(jié)果又存在“獨斷”的環(huán)節(jié)，可靠性又下降了不少。關(guān)于分布式監(jiān)控切換的問題，因為在去哪兒用的mysql-sentinel對Galera Cluster做的監(jiān)控，我對這點深有感觸，所以不得不在這里講一下。

在MyCat上面?zhèn)浞菔侨绾巫龅?能做到恢復(fù)一個快照嗎?

說起備份，做為數(shù)據(jù)庫使用者，應(yīng)該沒有一個不清楚，沒有一個人會覺得他不重要吧?當(dāng)然，重要是重要，但這種事情屬于重要不緊急的工作，但沒有是不行的，這個連公司內(nèi)審這一關(guān)都過不了，也許我們每一個人都不會希望能用到他。

言歸正傳，話說這么重要的備份工作，在MyCat上又是什么情況呢?可能了解一些基本原理的人都比較清楚，Xtrabackup、mysqldump等也都是可以用的，但備份完了之后呢，可能心里還是感覺沒底，因為這樣的工具，只能對一個MySQL節(jié)點做備份，如果分10個分片(10個MySQL節(jié)點)的話，可以通過備份十次即可完成，但需要注意的是，備份了十次產(chǎn)生了十個備份集，而并不是一個備份集，這十個備份集之間是完完全全沒有關(guān)系的，此時我可能就提出一個比較極端的問題來：

如果哪天(當(dāng)然我們都不希望有這樣的一天)，整個機(jī)房掛了，當(dāng)然假如“幸運”的是，有備份，那在這種情況下，如何恢復(fù)一個可用的數(shù)據(jù)一致及完整的集群快照呢?

這個時候可能會有人很快地說，將十個備份集都恢復(fù)了啟動了即可。但問題是這十個沒有關(guān)系，備份時間又不是同一時刻完成的，同一個表的十個分片，***數(shù)據(jù)有的是8點的，有的是9點的，或者有的甚至是昨天的。這樣恢復(fù)出來的表，能用么?基于這樣的表產(chǎn)生的查詢結(jié)果，靠譜么?可想而知。

當(dāng)然可能也有人會說，我們的數(shù)據(jù)不需要一致快照，或者更有甚者只需要備份元數(shù)據(jù)路由表或者配置文件即可，那這樣就沒問題了，如果MyCat只是定位于用來存儲Zabbix監(jiān)控數(shù)據(jù)，或者日志數(shù)據(jù)，可以丟失不要的數(shù)據(jù)，一文不值的數(shù)據(jù)，那我覺得沒毛病。

或許有人還會說，我們的機(jī)房不會掛，或者我們的存儲本來就是跨機(jī)房的，掛了的話直接切到另外的機(jī)房就行了，那此時又有問題了，如果切換的時候，有復(fù)制延遲，丟失了部分?jǐn)?shù)據(jù)，那整個集群又會出問題，因為只要有一個分片的數(shù)據(jù)出問題，整個集群就有問題了?；蛘吡硪粋€問題就是，假設(shè)你的機(jī)房真的不會掛，但我們經(jīng)常會遇到的需求是，我要取前幾天某時刻的數(shù)據(jù)，那此時還是需要通過備份然后恢復(fù)一個快照，這個時候還有何話可說，你告訴我究竟如何做到?

可能還會有人有疑問，他會說我們是邏輯備份啊，這樣備份出來的是整個庫或者表的一致性快照，這不就解決問題了么?我很同意這位同學(xué)的看法，說得對極了，是可以很***地解決一致性問題，但只要熟悉一點點MySQL的人都知道，類似mysqldump這樣的邏輯備份工具，是何其慢?現(xiàn)在都用分布式存儲了，那肯定是數(shù)據(jù)量非常大，這個時候還在使用這樣的邏輯備份?你是想干哈?即使備份完成了，那有沒有試過邏輯數(shù)據(jù)的恢復(fù)?幾個G的數(shù)據(jù)要恢復(fù)多久，你算過沒有?想想都頭疼。一條不歸路。。。

如果已經(jīng)在使用MyCat了，發(fā)現(xiàn)他的風(fēng)險確實太大了，我如何能下掉呢?

這個問題非常好，說明你已經(jīng)在思考做為一個數(shù)據(jù)負(fù)責(zé)人，如何保證數(shù)據(jù)的可靠性和避免風(fēng)險的問題了，MyCat風(fēng)險確實高，但如果已經(jīng)上了“賊船”并且想下掉的話，此時我可能想問一下(做一回事后諸葛亮)，上這個架構(gòu)的時候為什么不多考慮一下呢?公司的數(shù)據(jù)就是金錢，你這樣想上就上，想下就下，來回折騰，能升值么?萬一數(shù)據(jù)寫亂了，這個時候可沒有人賠你錢，還不如上云呢。

不過既然上了，那咱就聊聊如何下掉的問題，我目前感覺最靠譜最穩(wěn)妥的辦法，貌似只有一個，步驟如下：

先停業(yè)務(wù)，將所有的寫業(yè)務(wù)都停止(也不用找深夜時間了，因為12小時根本搞不完)。

通過上面所講的mysqldump做邏輯備份，將所有的庫導(dǎo)出來，生成.sql文件。

然后找一個靠譜的MySQL架構(gòu)(真正的分布式數(shù)據(jù)庫，或者磁盤足夠大的話可以不采用分布式，采用Share Nothing的方案即可，也許你需要的并不是分布式，只是被忽悠了)，將.sql文件導(dǎo)入進(jìn)去。

然后就將讀業(yè)務(wù)遷移到新的數(shù)據(jù)庫架構(gòu)上面去。

將寫業(yè)務(wù)也遷移到新的數(shù)據(jù)庫架構(gòu)上面去，然后啟動他們，這個時候應(yīng)該是可以提供正常的數(shù)據(jù)庫服務(wù)了。

我們可以注意一下這個過程，從第1步，到第5步，需要多少時間?這個當(dāng)然是硬時間，是要移動數(shù)據(jù)的，邏輯備份和恢復(fù)都那么慢，我覺得時間的單位可以用天來統(tǒng)計了。

這個時候負(fù)責(zé)人就可以想想，我用MyCat是圖什么啊，業(yè)務(wù)的免戰(zhàn)牌掛了好幾天，只是為了彌補(bǔ)當(dāng)年的一個錯誤決定，追悔莫及。

當(dāng)然也許有些人也會有其它辦法，但因為各個分片都是相互獨立的，還是存在上面的所說的在不停止業(yè)務(wù)的情況下的“一致性快照”的問題。

***我想說的是，對公司的數(shù)據(jù)，一定要慎之又慎，要時刻保持負(fù)責(zé)的態(tài)度，折騰數(shù)據(jù)真的不能升值啊。

MyCat的配置復(fù)雜嗎?上手容易么?

我們只需要看一個圖片就行了。你能想象這是它的配置文件么?看了之后我估計你也沒有任何使用它的欲望了，很多人在使用之后，是這樣評價的： 

配置文件如下： 

竟然是一個XML文件，這個產(chǎn)品經(jīng)理當(dāng)時是如何想的?后面也沒有想著做個優(yōu)化?

***一個問題，現(xiàn)在做分庫分表做得好的有哪些?

還有哪些?一個都沒有，這是一條不歸路啊。因為說白了，他是一種偽分布式方案，基礎(chǔ)是不好的，上層就做不好，所以永遠(yuǎn)是在補(bǔ)各種坑，走得很累，累人累己。現(xiàn)在可以回過頭來想一想，為什么一些很強(qiáng)大知名的公司做的中間件產(chǎn)品，并沒有做這些事情，比如ProxySQL、Maxscale、MySQL Router等，為什么呢?難道他們的技術(shù)不好?或者是沒有這樣的需求?我還是覺得，需求是有的，人與人、業(yè)務(wù)與業(yè)務(wù)的需求，是一樣的，但解決方法可能就不一樣了，他們可能早就認(rèn)為，這是一條錯誤的道路，所以就不會去選擇走，而MyCat這種方案，可能就要回過頭來想想未來的路了。

互聯(lián)網(wǎng)處理大規(guī)模在線訪問數(shù)據(jù)的做法

解耦思想充斥著互聯(lián)網(wǎng)技術(shù)棧的方方面面，為什么這樣做?我想應(yīng)該是大家都不想拖泥帶水，也不想牽一發(fā)而動全身罷了。而在MySQL數(shù)據(jù)庫層面，使用了重量級的中間層之后，你會發(fā)現(xiàn)，大一統(tǒng)看起來是很不錯，但這樣牽一發(fā)很可能動全身，這其實并不是好事情。

MySQL這種數(shù)據(jù)庫是在互聯(lián)網(wǎng)領(lǐng)域興起并被大規(guī)模使用的，在比如賬務(wù)、訂單、計費等等關(guān)鍵業(yè)務(wù)上使用的也不在少數(shù)。在大型互聯(lián)網(wǎng)公司，MySQL的使用一定是分庫分表的，通過各種垂直切分和水平切分，把一個數(shù)據(jù)庫變成一堆數(shù)據(jù)庫，也就是所說的數(shù)據(jù)庫集群。但是很少看到在使用的MySQL的時候會在上面架設(shè)一層重量級的所謂分布式的中間層，這樣導(dǎo)致的就是緊耦合了，與互聯(lián)網(wǎng)的高效聯(lián)運相違背，互聯(lián)網(wǎng)的數(shù)據(jù)庫集群都應(yīng)該是物理上離散的，每一個實例可以自由的控制和遷移，也就是所謂的解耦。

解耦的好處可以讓你自由處理每一個獨立的實例或者集群，方便根據(jù)實際情況應(yīng)對業(yè)務(wù)帶來的變數(shù)，該升級的升級，該縮容的縮容，為每一個業(yè)務(wù)或者每一個業(yè)務(wù)的數(shù)據(jù)庫定義不同的維護(hù)等級，靈活掌握，隨機(jī)而變。

解耦的好處可以提升數(shù)據(jù)庫的絕對性能，數(shù)據(jù)從業(yè)務(wù)到磁盤，或者從磁盤到業(yè)務(wù)，經(jīng)歷的路徑越短，其效率也就越高。很多使用MySQL的做法就是用一個簡單的中間層分發(fā)SQL，這樣的中間層功能清晰、結(jié)構(gòu)簡單、靈活高效，一般不會損失太多性能，這就像MySQL出品的MySQL Router，MariaDB出品的Maxscale，Percona的ProxySQL，還有國內(nèi)的正火的極數(shù)云舟的Arkproxy，他們的行為，都為選擇使用中間層去實現(xiàn)數(shù)據(jù)架構(gòu)指明了一個方向。

解耦的好處可以讓你的數(shù)據(jù)庫只干數(shù)據(jù)庫最擅長的事情，它能保證你的數(shù)據(jù)安全存儲，它能保證你的數(shù)據(jù)高效存取，它能保證你數(shù)據(jù)并發(fā)處理，它能保證你的數(shù)據(jù)靈活接入，這還不夠嗎?

綜上所述，我們再次確信一個真理，MySQL因簡單而高效，因高效而流行，不要舍本逐末，聽信忽悠，誤入歧途。

當(dāng)然如果不想在業(yè)務(wù)層做分庫分表來適配MySQL數(shù)據(jù)庫的架構(gòu)，而想通過對業(yè)務(wù)透明的分布式數(shù)據(jù)庫來提供業(yè)務(wù)服務(wù)的話，我推薦真正意義的分布式數(shù)據(jù)庫解決方案，他能解決的是強(qiáng)大的存儲擴(kuò)展能力、分布式運算、對業(yè)務(wù)讀寫透明以及友好的故障轉(zhuǎn)移等問題，這是他們的優(yōu)勢，也是他們的初衷。

真正意義的分布式解決方案

真分布式方案，其實已經(jīng)不用太多說了，達(dá)到上面所述的需求即可。并且目前也有比較成熟的方案，比較有代表性的產(chǎn)品有Google的Spanner&F1、以及國產(chǎn)數(shù)據(jù)庫SequoiaDB、TiDB等等。關(guān)于巨杉數(shù)據(jù)庫，之前寫了一篇文章，有興趣的同學(xué)可以看看《【原創(chuàng)首發(fā)】兼容MySQL的開源分布式數(shù)據(jù)庫SequoiaDB在去哪兒網(wǎng)的實踐》

對比之下，這種分布式數(shù)據(jù)庫對業(yè)務(wù)無侵入，MySQL數(shù)據(jù)實現(xiàn)了云存儲特征，100%兼容MySQL，擴(kuò)展性非常好，天然支持分布式事務(wù)、數(shù)據(jù)節(jié)點及路由節(jié)點延遲非常小，通過一致性算法來保證了數(shù)據(jù)的強(qiáng)一致性，如此種種，都是立足于一個正確的基點之上，來建立起高樓大廈，勢必將基于MyCat的偽分布式數(shù)據(jù)庫解決方案推入無人問津的深淵，直至淘汰與消亡。

總結(jié)

使用MyCat的用戶其實還是挺多的，現(xiàn)在在了解業(yè)界市場的情況下，我也是比較能理解他們，因為需求有，但真的是沒有解決方案，選擇使用，實則無奈之舉，畢竟他是開源的，罵歸罵，也無怨言，因為免費嘛，有的用還有什么可言語的呢?我也推薦大家去試用一下，只有知道痛了，才會感覺現(xiàn)在有新的方案出現(xiàn)的美好。

本文所述的關(guān)于MyCat的一系列問題，主要目的是考慮到為了讓業(yè)內(nèi)同學(xué)不要繼續(xù)采坑，所以做了一些總結(jié)，所述內(nèi)容限于本人目前對MyCat的理解與認(rèn)識，如果有紕漏或者不足的地方，歡迎私信指正或者給予補(bǔ)充，感謝。