引子

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

成都創(chuàng)新互聯(lián)是一家專業(yè)提供耒陽企業(yè)網(wǎng)站建設(shè),專注與做網(wǎng)站、網(wǎng)站設(shè)計(jì)、H5開發(fā)、小程序制作等業(yè)務(wù)。10年已為耒陽眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)的建站公司優(yōu)惠進(jìn)行中。

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

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

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

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

分布式解決方案需求

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

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

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

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

• 元數(shù)據(jù)變更透明性
  元數(shù)據(jù)變更，在任何數(shù)據(jù)庫中都是存在的，在單點(diǎn)情況下，改表操作我們有多種友好的方法來實(shí)現(xiàn)，但到了分布式環(huán)境下，可能這種操作就成為了問題，因?yàn)閿?shù)據(jù)的分片導(dǎo)致了元數(shù)據(jù)的變更需要多點(diǎn)修改，進(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界，一個(gè)存在很久的話題，就是：哪個(gè)中間件實(shí)現(xiàn)的分庫分表方案比較好?。?br/>當(dāng)然對(duì)于同一個(gè)問題，不同人有不同的理解，也都具有兩面性的特征，有人說好，也有人說不好，我們首先看一下這種方案是如何實(shí)現(xiàn)的。

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

最后一個(gè)問題，現(xiàn)在做分庫分表做得好的有哪些？

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

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

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

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

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

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

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

綜上所述，我們?cè)俅未_信一個(gè)真理，MySQL因簡(jiǎn)單而高效，因高效而流行，不要舍本逐末，聽信忽悠，誤入歧途。

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

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

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

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

總結(jié)

使用MyCat的用戶其實(shí)還是挺多的，現(xiàn)在在了解業(yè)界市場(chǎng)的情況下，我也是比較能理解他們，因?yàn)樾枨笥校娴氖菦]有解決方案，選擇使用，實(shí)則無奈之舉，畢竟他是開源的，罵歸罵，也無怨言，因?yàn)槊赓M(fèi)嘛，有的用還有什么可言語的呢？我也推薦大家去試用一下，只有知道痛了，才會(huì)感覺現(xiàn)在有新的方案出現(xiàn)的美好。

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

【作者介紹】

王竹峰：去哪兒網(wǎng)數(shù)據(jù)庫總監(jiān)，中國(guó)計(jì)算機(jī)行業(yè)協(xié)會(huì)開源數(shù)據(jù)庫專業(yè)委員會(huì)常務(wù)理事。擅長(zhǎng)數(shù)據(jù)庫開發(fā)、數(shù)據(jù)庫管理及維護(hù)，一直致力于MySQL數(shù)據(jù)庫源碼的研究與探索，對(duì)數(shù)據(jù)庫原理及實(shí)現(xiàn)有深刻的理解。曾就職于達(dá)夢(mèng)數(shù)據(jù)庫，從事多年數(shù)據(jù)庫內(nèi)核開發(fā)工作，后轉(zhuǎn)戰(zhàn)人人網(wǎng)，任職高級(jí)數(shù)據(jù)庫工程師，目前在去哪兒網(wǎng)負(fù)責(zé)MySQL源碼研究與運(yùn)維、數(shù)據(jù)庫管理和自動(dòng)化運(yùn)維平臺(tái)設(shè)計(jì)開發(fā)及實(shí)踐工作，是Inception開源項(xiàng)目及《MySQL運(yùn)維內(nèi)參》的作者，也是國(guó)內(nèi)少數(shù)幾個(gè)MySQL方向的Oracle ACE之一。