對于Shared-storage以及Shared-nothing的技術請參考Oracle以及IBM網(wǎng)站上的相關資料。

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

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

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

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

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

對于第二類的應用，就需要分布式計算的系統(tǒng)來解決了，一般的系統(tǒng)是無能為力了。

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

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

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

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

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

Server 對 Client 請求的響應數(shù)據(jù)格式：

當FLAG=0 , 2的時候 CMD Code 與 Message 的定義

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

Command ID 與 Command Data 的說明：

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

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

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

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