對(duì)于Shared-storage以及Shared-nothing的技術(shù)請(qǐng)參考Oracle以及IBM網(wǎng)站上的相關(guān)資料。

第二節(jié) 目前數(shù)據(jù)庫(kù)應(yīng)用狀況
目前數(shù)據(jù)庫(kù)應(yīng)用狀況大致分為兩類，第一類是數(shù)據(jù)量在100G以下，數(shù)據(jù)庫(kù)訪問(wèn)頻繁，請(qǐng)求密集。主要是Web APP類型的應(yīng)用，例如：網(wǎng)站，論壇等。這些Web APP類型的應(yīng)用訪問(wèn)數(shù)據(jù)庫(kù)的特點(diǎn)是：訪問(wèn)頻繁，數(shù)據(jù)庫(kù)每秒鐘要接受幾千次以上的查詢，需要經(jīng)常追加數(shù)據(jù)，同時(shí)對(duì)數(shù)據(jù)的響應(yīng)速度要求比較高。另一類是用于科學(xué)計(jì)算、存儲(chǔ)歷史數(shù)據(jù)的應(yīng)用，數(shù)據(jù)量往往達(dá)到幾百G。這些應(yīng)用訪問(wèn)數(shù)據(jù)庫(kù)的特點(diǎn)是：多為查詢操作，數(shù)據(jù)都是分批、定時(shí)、集中倒入數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)的記錄非常多，積累了大量的數(shù)據(jù)，對(duì)數(shù)據(jù)庫(kù)的響應(yīng)速度沒(méi)有太高要求。

第三節(jié) 暴露出來(lái)的問(wèn)題
第一類應(yīng)用，由于訪問(wèn)比較頻繁，而且為了支持更多的訪問(wèn)，Web Server一般都使用了負(fù)載均衡的集群，但是對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)，由于無(wú)法實(shí)現(xiàn)集群操作，每秒鐘的請(qǐng)求不斷增加，隨著服務(wù)器負(fù)載的增加，響應(yīng)單個(gè)請(qǐng)求的速度越來(lái)越慢，如果庫(kù)文件比較大，出現(xiàn)寫操作的時(shí)候還會(huì)出現(xiàn)鎖表時(shí)間過(guò)長(zhǎng)等影響訪問(wèn)效率的事情。

第二類應(yīng)用，主要是數(shù)據(jù)文件太大，每次處理數(shù)據(jù)都需要大量的時(shí)間，如果寫錯(cuò)一個(gè)語(yǔ)句就需要花幾個(gè)小時(shí)來(lái)重做查詢。

第四節(jié) 如何解決
首先應(yīng)當(dāng)從硬件、軟件、程序、索引、SQL語(yǔ)句這幾個(gè)方面進(jìn)行優(yōu)化，如果仍然不能解決問(wèn)題，我們就要考慮數(shù)據(jù)庫(kù)系統(tǒng)的集群（并行處理）了。

對(duì)于第一類的應(yīng)用，在數(shù)據(jù)庫(kù)服務(wù)器正常運(yùn)行，負(fù)載不高的情況下，應(yīng)用對(duì)數(shù)據(jù)庫(kù)系統(tǒng)的狀況還是滿意的。但是數(shù)據(jù)庫(kù)系統(tǒng)負(fù)載過(guò)高之后，就會(huì)出現(xiàn)完成請(qǐng)求的時(shí)間加長(zhǎng)，達(dá)不到系統(tǒng)的要求時(shí)間。既然負(fù)載是由于過(guò)多的請(qǐng)求造成的，我們就采取分擔(dān)請(qǐng)求的方式，讓一部分的請(qǐng)求去訪問(wèn)另外一臺(tái)服務(wù)器，讓單臺(tái)服務(wù)器的負(fù)載降低，從而解決問(wèn)題。

對(duì)于第二類的應(yīng)用，就需要分布式計(jì)算的系統(tǒng)來(lái)解決了，一般的系統(tǒng)是無(wú)能為力了。

第五節(jié) 針對(duì)于"Linux+Apache+PHP+MySQL"的第一類應(yīng)用問(wèn)題的解決方式
一個(gè)實(shí)際案例的解決：
我在工作當(dāng)中遇到了這樣的問(wèn)題，我們的Web Server是Linux+Apache+Php的三臺(tái)機(jī)器組成的集群，MySQL運(yùn)行在SUN450，2G內(nèi)存的平臺(tái)上。由于WEB的訪問(wèn)量在高峰的時(shí)候幾乎滿負(fù)荷運(yùn)轉(zhuǎn)，LoadAvg(就是一分鐘之內(nèi)處于Running狀態(tài)的進(jìn)程數(shù)量)都在10-20之間，反映出來(lái)就是大量的請(qǐng)求都在訪問(wèn)數(shù)據(jù)庫(kù)的時(shí)候被掛住了，導(dǎo)致一個(gè)請(qǐng)求沒(méi)有完成，下一個(gè)請(qǐng)求又進(jìn)來(lái)，最后惡性循環(huán)。LoadAvg會(huì)在瞬間飆升至800以上。數(shù)據(jù)庫(kù)那邊就更糟糕了，LoadAvg達(dá)到300多，數(shù)據(jù)庫(kù)的線程非常多，CPU忙于切換線程狀態(tài)，這個(gè)時(shí)候除非Restart MySQL，否則怎么都不會(huì)好。在對(duì)SQL語(yǔ)句優(yōu)化完成后還是不能很好的解決問(wèn)題，我們?cè)黾恿艘慌_(tái)數(shù)據(jù)庫(kù)服務(wù)器，通過(guò)MySQL的數(shù)據(jù)同步機(jī)制，讓兩臺(tái)數(shù)據(jù)庫(kù)上的數(shù)據(jù)保持同步，修改了一部分只會(huì)發(fā)生讀取操作的php程序，讓這些程序連接另外一臺(tái)數(shù)據(jù)庫(kù)，算是把負(fù)載分離出去一部分，問(wèn)題得到了初步的解決。但是后來(lái)業(yè)務(wù)做大，我們又增加了多臺(tái)服務(wù)器，修改了很多程序，分離他們對(duì)數(shù)據(jù)庫(kù)的讀取操作，訪問(wèn)不同的服務(wù)器。

第六節(jié) MySQL-HA-Proxy方案的提出
通過(guò)修改程序的方式實(shí)現(xiàn)將系統(tǒng)的負(fù)載分離，是件很痛苦的事情，工程浩大，而且不能弄錯(cuò)，因?yàn)槌酥鞣?wù)器可以寫入、修改數(shù)據(jù)，而其它的服務(wù)器只能通過(guò)數(shù)據(jù)同步更新自身的數(shù)據(jù)，所以如果你對(duì)那些數(shù)據(jù)庫(kù)進(jìn)行了寫操作，結(jié)果將是災(zāi)難性的。

如果我們能夠有一個(gè)程序分揀SQL語(yǔ)句，根據(jù)他的類型（讀取/寫入），分別傳送給不同的服務(wù)器，然后再將結(jié)果返回。采用一種類似HTTP的PROXY的方式，這樣我們就不需要通過(guò)修改源程序的方式來(lái)分擔(dān)負(fù)載了，如果再能夠根據(jù)服務(wù)器的負(fù)載狀況，或者是表的狀態(tài)（可用/鎖定），來(lái)判斷應(yīng)該將這個(gè)請(qǐng)求分配到哪臺(tái)服務(wù)器，那就比我們修改源程序所能達(dá)到的效果還要好。

第七節(jié) MySQL Client 與 Server之間如何通信
四處尋找，也沒(méi)有找到一篇關(guān)于Mysql通訊協(xié)議的文章，看來(lái)只有分析Mysql的源程序了。于是找來(lái)mysql 3.23.49的代碼，打開sniffer工具。MySQL的通訊協(xié)議可能變更過(guò)多次，在3.23.49的版本里面，通訊協(xié)議的版本竟然是10。

簡(jiǎn)單的分析了一下通訊協(xié)議，現(xiàn)在規(guī)整如下，有些地方還不是很完善，由于我實(shí)在沒(méi)有太多的時(shí)間仔細(xì)研讀mysql的代碼，目前我只了解到了這些。

Server 對(duì) Client 請(qǐng)求的響應(yīng)數(shù)據(jù)格式：

當(dāng)FLAG=0 , 2的時(shí)候 CMD Code 與 Message 的定義

Client 對(duì) Server 提交數(shù)據(jù)的格式：

Command ID 與 Command Data 的說(shuō)明：

第八節(jié) Client 如何通過(guò) Server 的用戶認(rèn)證
協(xié)議分析完成了，我嘗試著讓它工作起來(lái)，可是認(rèn)證這個(gè)部分遇到了麻煩，Mysql Server在Client連接上它的時(shí)候，會(huì)首先返回給Client一個(gè)數(shù)據(jù)包，包含協(xié)議的版本號(hào)，版本信息，SessionID，一個(gè)8字節(jié)的Key，就是這個(gè)Key的原因。Client會(huì)使用這個(gè)Key來(lái)加密密碼，然后將用戶名，密碼，需要打開的數(shù)據(jù)庫(kù)等信息發(fā)送給Server，這樣就完成認(rèn)證了。我不知道Client是如何利用這個(gè)Key來(lái)加密的，所以我打算跳過(guò)密碼，我將Client的數(shù)據(jù)包重組，去掉Password的信息之后，我成功了，但是集群里面的Mysql用戶都是沒(méi)有密碼的，安全性多多少少有些問(wèn)題，不過(guò)這些服務(wù)器都是放在HA后面的，沒(méi)有外部的IP地址，應(yīng)該問(wèn)題不大，不過(guò)多多少少是個(gè)缺憾。

但是我總要知道用戶的密碼是否正確吧？怎么辦呢？使用一個(gè)專用的Mysql來(lái)完成密碼認(rèn)證。安裝一個(gè)最小化資源的Mysql Server用來(lái)做MysqlAuth（專用認(rèn)證服務(wù)器），當(dāng)Client連接后，就將MysqlAuth的第一個(gè)數(shù)據(jù)包返回給Client，這里面當(dāng)然就包含著Key，然后Client會(huì)使用這個(gè)Key，加密密碼之后，將認(rèn)證信息發(fā)回來(lái)，這個(gè)時(shí)候，MysqlHA系統(tǒng)就會(huì)將這個(gè)信息轉(zhuǎn)發(fā)給MysqlAuth，并且自己保留一份，如果認(rèn)證通過(guò)了，就把保留的那一份進(jìn)行重組，去掉密碼信息，然后用重組后的認(rèn)證信息去連接集群中的服務(wù)器。

第九節(jié) 系統(tǒng)的結(jié)構(gòu)與流程

            1 x Apache + PHP
1 x AB
1 x Mysql Proxy + Mysql Auth Server
2 x Mysql Real Server