大型網站架構不得不考慮的幾點問題

前言：這兩天機器壞了，正在送修中，寫個系列的大型HTTP://www.aliyun.com/zixun/aggregation/11116.html">網站架構的文章， 希望對有志在互聯網做出一番事業的站長朋友們一些説明。

注意：這裡的大型網站架構只包括高互動性高交互性的資料型大型網站，基於大家眾所周知的原因，我們就不談新聞類和一些依靠HTML靜態化就可以實現的架構了，我們以高負載高資料交換高資料流程動性的網站為例，比如海內， 開心網等類似的web2.0系列架構。 我們這裡不討論是PHP還是JSP或者.NET環境，我們從架構的方面去看問題，實現語言方面並不是問題，語言的優勢在於實現而不是好壞，不論你選擇任何語言，架構都是必須要面對的。

文入正題：

首先討論一下大型網站需要注意和考慮的問題

A. 海量資料的處理。

眾所周知，對於一些相對小的網站來說，資料量並不是很大，select和update就可以解決我們面對的問題，本身負載量不是很大，最多再加幾個索引就可以搞定。 對於大型網站，每天的資料量可能就上百萬，如果一個設計不好的多對多關係，在前期是沒有任何問題的，但是隨著使用者的增長，資料量會是幾何級的增長的。 在這個時候我們對於一個表的select和update的時候(還不說多表聯集查詢)的成本的非常高的。

B. 資料併發的處理

在一些時候，2.0的CTO都 有個尚方寶劍，就是緩存。 對於緩存，在高併發高處理的時候也是個大問題。 在整個應用程式下，緩存是全域共用的，然而在我們進行修改的時候就，如果兩個或者 多個請求同時對緩存有更新的要求的情況下，應用程式會直接的死掉。 這個時候，就需要一個好的資料併發處理策略以及緩存策略。

另外，就是資料庫的鎖死問題，也許平時我們感覺不到，鎖死在高併發的情況下的出現的概率是非常高的，磁片緩存就是一個大問題。

C. 檔存貯的問題

對於一些支援檔上傳的2.0的網站，在慶倖硬碟容量越來越大的時候我們更多的應該考慮的是檔應該如何被存儲並且被有效的索引。 常見的方案是對檔按照日期和類型進行存貯。 但是當檔量 是海量的資料的情況下，如果一塊硬碟存貯了500個G的瑣碎檔，那麼維護的時候和使用的時候磁片的Io就是一個巨大的問題，哪怕你的頻寬足夠，但是你的磁片也未必回應過來。 如果這個時候還涉及上傳，磁片很容易就over了。

也許用raid和專用存貯伺服器能解決眼下的問題，但是還有個問題就是各地的訪問問題，也許我們的伺服器在北京，可能在雲南或者新疆的存取速度如何解決?如果做分散式，那麼我們的檔索引以及架構該如何規劃。

所以我們不得不承認，檔存貯是個很不容易的問題

D. 資料關係的處理

我們可以很容易的規劃出一個符合第三范式的資料庫，裡面佈滿了多對多關係，還能用GUID來替換INDENTIFY COLUMN 但是，多對多關係充斥的2.0時代，第三范式是第一個應該被拋棄的。 必須有效的把多表聯集查詢降到最低。

E. 資料索引的問題

眾所周知，索引是提高資料庫效率查詢的最方面最廉價最容易實現的方案。 但是，在高UPDATE的情況下，update和delete付出的成本會高的無法想想，筆者遇到過一個情況，在更新一個聚焦索引的時候需要10分鐘來完成，那麼對於網站來說，這些基本上是不可忍受的。