作者：nightsailer
來源：http://www.phpchina.com/bbs/thread-15484-1-1.html

• 數(shù)據(jù)庫(kù)

 

沒錯(cuò),首先是數(shù)據(jù)庫(kù),這是大多數(shù)應(yīng)用所面臨的首個(gè)SPOF。尤其是Web2.0的應(yīng)用，數(shù)據(jù)庫(kù)的響應(yīng)是首先要解決的。
一般來說MySQL是最常用的，可能最初是一個(gè)mysql主機(jī)，當(dāng)數(shù)據(jù)增加到100萬(wàn)以上，
那么，MySQL的效能急劇下降。常用的優(yōu)化措施是M-S（主-從）方式進(jìn)行同步復(fù)制，將查詢和操作和分別在不同的
服務(wù)器上進(jìn)行操作。我推薦的是M-M-Slaves方式，2個(gè)主Mysql，多個(gè)Slaves，需要注意的是，雖然有2個(gè)Master，
但是同時(shí)只有1個(gè)是Active，我們可以在一定時(shí)候切換。之所以用2個(gè)M，是保證M不會(huì)又成為系統(tǒng)的SPOF。
Slaves可以進(jìn)一步負(fù)載均衡，可以結(jié)合LVS,從而將select操作適當(dāng)?shù)钠胶獾讲煌膕laves上。

以上架構(gòu)可以抗衡到一定量的負(fù)載，但是隨著用戶進(jìn)一步增加，你的用戶表數(shù)據(jù)超過1千萬(wàn)，這時(shí)那個(gè)M變成了
SPOF。你不能任意擴(kuò)充Slaves，否則復(fù)制同步的開銷將直線上升，怎么辦？我的方法是表分區(qū)，
從業(yè)務(wù)層面上進(jìn)行分區(qū)。最簡(jiǎn)單的，以用戶數(shù)據(jù)為例。根據(jù)一定的切分方式，比如id，切分到不同的數(shù)據(jù)庫(kù)集群去。
全局?jǐn)?shù)據(jù)庫(kù)用于meta數(shù)據(jù)的查詢。缺點(diǎn)是每次查詢，會(huì)增加一次，比如你要查一個(gè)用戶nightsailer,你首先要到
全局?jǐn)?shù)據(jù)庫(kù)群找到nightsailer對(duì)應(yīng)的cluster id，然后再到指定的cluster找到nightsailer的實(shí)際數(shù)據(jù)。
每個(gè)cluster可以用m-m方式，或者m-m-slaves方式。
這是一個(gè)可以擴(kuò)展的結(jié)構(gòu)，隨著負(fù)載的增加，你可以簡(jiǎn)單的增加新的mysql cluster進(jìn)去。

需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比較好的方法來監(jiān)控mysql主機(jī)的負(fù)載和服務(wù)的運(yùn)行狀態(tài)。如果你有30臺(tái)以上的mysql數(shù)據(jù)庫(kù)在跑就明白我的意思了。
4、不要使用持久性鏈接（不要用pconnect）,相反，使用sqlrelay這種第三方的數(shù)據(jù)庫(kù)鏈接池，或者干脆自己做，因?yàn)閜hp4中mysql的
鏈接池經(jīng)常出問題。

• 緩存

 

緩存是另一個(gè)大問題，我一般用memcached來做緩存集群，一般來說部署10臺(tái)左右就差不多（10g內(nèi)存池）。需要注意一點(diǎn)，千萬(wàn)不能用使用
swap，最好關(guān)閉linux的swap。

• 負(fù)載均衡/加速

 

可能上面說緩存的時(shí)候，有人第一想的是頁(yè)面靜態(tài)化，所謂的靜態(tài)html，我認(rèn)為這是常識(shí)，不屬于要點(diǎn)了。頁(yè)面的靜態(tài)化隨之帶來的是靜態(tài)服務(wù)的
負(fù)載均衡和加速。我認(rèn)為L(zhǎng)ighttped+Squid是最好的方式了。
LVS <------->lighttped====>squid(s) ====lighttpd

上面是我經(jīng)常用的。注意，我沒有用apache，除非特定的需求，否則我不部署apache，因?yàn)槲乙话阌胮hp-fastcgi配合lighttpd,
性能比apache+mod_php要強(qiáng)很多。

squid的使用可以解決文件的同步等等問題，但是需要注意，你要很好的監(jiān)控緩存的命中率，盡可能的提高的90%以上。
squid和lighttped也有很多的話題要討論，這里不贅述。

• 存儲(chǔ)

 

存儲(chǔ)也是一個(gè)大問題，一種是小文件的存儲(chǔ)，比如圖片這類。另一種是大文件的存儲(chǔ)，比如搜索引擎的索引，一般單文件都超過2g以上。
小文件的存儲(chǔ)最簡(jiǎn)單的方法是結(jié)合lighttpd來進(jìn)行分布。或者干脆使用Redhat的GFS，優(yōu)點(diǎn)是應(yīng)用透明，缺點(diǎn)是費(fèi)用較高。我是指
你購(gòu)買盤陣的問題。我的項(xiàng)目中，存儲(chǔ)量是2-10Tb，我采用了分布式存儲(chǔ)。這里要解決文件的復(fù)制和冗余。
這樣每個(gè)文件有不同的冗余，這方面可以參考google的gfs的論文。
大文件的存儲(chǔ)，可以參考nutch的方案，現(xiàn)在已經(jīng)獨(dú)立為hadoop子項(xiàng)目。(你可以google it)

其他：
此外，passport等也是考慮的，不過都屬于比較簡(jiǎn)單的了。

jwebee

我的個(gè)人網(wǎng)站