開發大型高負載類網站應用的幾個要點

看了一些人的所謂大型項目的方法，我感覺都是沒有說到點子上，有點難受。

我也說說自己的看法.我個人認為，很難衡量所謂項目是否大型，即便很簡單的應用在高負載和高增長情況下都是一個挑戰.因此，按照我的想法，姑且說是高負載高並發或者高增長情況下，需要考慮的問題.這些問題，很多是和程序開發無關，而是和整個系統的架構密切相關的.

　　數據庫

　　沒錯，首先是數據庫，這是大多數應用所面臨的首個SPOF。尤其是Web2.0的應用，數據庫的響應是首先要解決的。

一般來說MySQL是最常用的，可能最初是一個mysql主機，當數據增加到100萬以上，那麼，MySQL的效能急劇下降。常用的優化措施是M-S（主-從）方式進行同步複製，將查詢和操作和分別在不同的服務器上進行操作。我推薦的是M-M-Slaves方式，2個主Mysql，多個Slaves，需要注意的是，雖然有2個Master，但是同時只有1個是Active，我們可以在一定時候切換。之所以用2個M，是保證M不會又成為系統的SPOF。Slaves可以進一步負載均衡，可以結合LVS，從而將select操作適當的平衡到不同的slaves上。

以上架構可以抗衡到一定量的負載，但是隨著用戶進一步增加，你的用戶表數據超過1千萬，這時那個M變成了SPOF。你不能任意擴充Slaves，否則複製同步的開銷將直線上升，怎麼辦？我的方法是表分區，從業務層面上進行分區。最簡單的，以用戶數據為例。

根據一定的切分方式，比如id，切分到不同的數據庫集群去。全局數據庫用於meta數據的查詢。缺點是每次查詢，會增加一次，比如你要查一個用戶nightsailer，你首先要到全局數據庫群找到nightsailer對應的cluster id，然後再到指定的cluster找到nightsailer的實際數據。

每個cluster可以用m-m方式，或者m-m-slaves方式。這是一個可以擴展的結構，隨著負載的增加，你可以簡單的增加新的mysql cluster進去。

需要注意的是：

1、禁用全部auto_increment的字段

2、id需要採用通用的算法集中分配

3、要具有比較好的方法來監控mysql主機的負載和服務的運行狀態。如果你有30台以上的mysql數據庫在跑就明白我的意思了。

4、不要使用持久性鏈接（不要用pconnect），相反，使用sqlrelay這種第三方的數據庫鏈接池，或者乾脆自己做，因為php4中mysql的鏈接池經常出問題。

緩存

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

負載均衡/加速

　　可能上面說緩存的時候，有人第一想的是頁面靜態化，所謂的靜態html，我認為這是常識，不屬於要點了。頁面的靜態化隨之帶來的是靜態服務的
負載均衡和加速。我認為Lighttped+Squid是最好的方式了。

LVS %26lt;-------%26gt;lighttped====%26gt;squid(s) ====lighttpd

上面是我經常用的。注意，我沒有用apache，除非特定的需求，否則我不部署apache，因為我一般用php-fastcgi配合lighttpd，性能比apache+mod_php要強很多。

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

存儲

存儲也是一個大問題，一種是小文件的存儲，比如圖片這類。另一種是大文件的存儲，比如搜索引擎的索引，一般單文件都超過2g以上。

小文件的存儲最簡單的方法是結合lighttpd來進行分佈。或者乾脆使用Redhat的GFS，優點是應用透明，缺點是費用較高。我是指你購買盤陣的問題。我的項目中，存儲量是2-10Tb，我採用了分佈式存儲。這裡要解決文件的複製和冗余。這樣每個文件有不同的冗余，這方面可以參考google的gfs的論文。大文件的存儲，可以參考nutch的方案，現在已經獨立為hadoop子項目。(你可以google it)

其他：

此外，passport等也是考慮的，不過都屬於比較簡單的了。拋磚引玉而已。