大規(guī)模MySQL運(yùn)維陷阱之基于MyCat的偽分布式架構(gòu)

2024-07-24 12:31:29

字體：大中小

供稿：網(wǎng)友

分布式數(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)致的就是存儲瓶頸，因?yàn)镸ySQL數(shù)據(jù)庫，實(shí)質(zhì)上，還是一個(gè)單機(jī)版本的數(shù)據(jù)庫，而只要是單機(jī)，就必然會遇到的一個(gè)問題就是存儲問題，因?yàn)榇鎯κ怯残枨?，而CPU和內(nèi)存如果不夠的話，只是性能不好，并不會直接否定方案或者架構(gòu)。

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

增大磁盤
這種方式，應(yīng)該是最直接，最簡單的方案了，因?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è)量級吧？其實(shí)我個(gè)人認(rèn)為，這個(gè)已經(jīng)是不能接受的量了，最合適的最好保持在1T以下即可。超過這個(gè)就要想辦法了。當(dāng)然這個(gè)數(shù)據(jù)量不宜達(dá)到這個(gè)大小的原因，可能會有人考慮到這是性能的問題，其實(shí)不然，或者性能問題很小，因?yàn)镮nnoDB采用的是B+樹的存儲方案，小表最壞情況下沒有查到數(shù)據(jù)是要找3層，也就是3個(gè)頁面的IO，而大表需要的是4個(gè)頁面的IO，影響不大。
數(shù)據(jù)壓縮
為了減少數(shù)據(jù)對磁盤空間的占用，我們通常也會將數(shù)據(jù)做壓縮處理，通過一個(gè)語句即可搞定，是InnoDB原生支持的一種方式，一般情況下，會將數(shù)據(jù)占用減少到原來的三分之一到一半不等，效果還是足夠明顯的，不過這樣處理之后的數(shù)據(jù)，在性能上會有所下降，對于響應(yīng)要求比較高的業(yè)務(wù)，可能需要謹(jǐn)慎考慮一下，但這種方式，可能還是治標(biāo)不治本，在數(shù)據(jù)量繼續(xù)增長的情況下，過段時(shí)間之后，依然面臨相同的問題，這種情況下，就不能繼續(xù)使用這種方式來實(shí)現(xiàn)了。
數(shù)據(jù)分片
數(shù)據(jù)分片的解決方案，現(xiàn)在業(yè)內(nèi)也用得很多，這種方案已經(jīng)超出了MySQL本身，包括HBase、Redis等也都在使用這種方案，應(yīng)該說這種方案是最具擴(kuò)展性的，并且可以稱得上是無限擴(kuò)展，而上面兩種方案，根本談不上擴(kuò)展性。所以這種方案在業(yè)內(nèi)成為主流，并且這種方案才能稱得上是分布式存儲，具體的實(shí)現(xiàn)也層出不窮，當(dāng)然也存在優(yōu)秀的分布式解決方案，也存在一些“偽”分布式方案了。
分布式解決方案需求
擴(kuò)展性
使用分布式，其實(shí)最主要的就是擴(kuò)展性，如果空間不足了，可以很方便容易的擴(kuò)展節(jié)點(diǎn)個(gè)數(shù)，并且將數(shù)據(jù)做新的平衡處理。這個(gè)過程要不影響業(yè)務(wù)使用，對業(yè)務(wù)透明。
支持事務(wù)
分布式數(shù)據(jù)庫，對于業(yè)務(wù)本身，使用方面與單機(jī)區(qū)別不大，也就是對業(yè)務(wù)透明，因?yàn)槭褂肕ySQL是支持事務(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ù)庫，其實(shí)基本上是對性能的要求比較低的業(yè)務(wù)才會這樣選擇，即使是這樣，還是性能越高，越多人才會選擇這樣的分布式數(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)的分庫分表方案比較好啊？
當(dāng)然對于同一個(gè)問題，不同人有不同的理解，也都具有兩面性的特征，有人說好，也有人說不好，我們首先看一下這種方案是如何實(shí)現(xiàn)的。
大規(guī)模MySQL運(yùn)維陷阱之基于MyCat的偽分布式架構(gòu)

MyCat究竟做了什么事情？

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

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

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

（編輯：武林網(wǎng)）

上一篇：Haproxy+Keepalived+MySQL達(dá)成讀均衡負(fù)載

下一篇：Mysql導(dǎo)入導(dǎo)出幾種方式+查看修改數(shù)據(jù)庫字符集辦法