看了一些人的所謂大型項(xiàng)目的方法,我感覺都是沒有說到點(diǎn)子上，有點(diǎn)難受。
我也說說自己的看法.我個人認(rèn)為,很難衡量所謂項(xiàng)目是否大型,
即便很簡單的應(yīng)用在高負(fù)載和高增長情況下都是一個挑戰(zhàn).因此,按照我的想法,姑且說是高負(fù)載
高并發(fā)或者高增長情況下,需要考慮的問題.這些問題,很多是和程序開發(fā)無關(guān),而是和整個系統(tǒng)的
架構(gòu)密切相關(guān)的.

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

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

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

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

• 緩存

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

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

可能上面說緩存的時候，有人第一想的是頁面靜態(tài)化，所謂的靜態(tài)html，我認(rèn)為這是常識，不屬于要點(diǎn)了。頁面的靜態(tài)化隨之帶來的是靜態(tài)服務(wù)的
負(fù)載均衡和加速。我認(rèn)為Lighttped+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也有很多的話題要討論，這里不贅述。

• 存儲

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

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