大型網站架構不得不考慮的10個問題

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

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

1、海量資料的處理

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

2、資料併發的處理

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

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

3、檔案存貯的問題

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

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

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

4、資料關係的處理

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

5、資料索引的問題

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

索引和更新是一對天生的冤家，問題A，D，E這些是我們在做架構的時候不得不考慮的問題，並且也可能是花費時間最多的問題，

6、分散式處理

對於2.0網站由於其高互動性，CDN實現的效果基本上為0，內容是實時更新的，我們常規的處理。為了保證各地的訪問速度，我們就需要面對一個絕大的問題，就是如何有效的實現資料同步和更新，實現各地伺服器的實時通訊有是一個不得不需要考慮的問題。

7、Ajax的利弊分析

成也AJAX，敗也AJAX，AJAX成為了主流趨勢，突然發現基於XMLHTTP的post和get是如此的容易。客戶端get或者post 到伺服器資料，伺服器接到資料請求之後返回來，這是一個很正常的AJAX請求。但是在AJAX處理的時候，如果我們使用一個抓包工具的話，對資料返回和處理是一目瞭然。對於一些計算量大的AJAX請求的話，我們可以構造一個發包機，很容易就可以把一個webserver幹掉。

8、資料安全性的分析

對於HTTP協議來說，資料包都是明文傳輸的，也許我們可以說我們可以用加密啊，但是對於G問題來說的話，加密的過程就可能是明文了(比如我們知道的QQ，可以很容易的判斷他的加密，並有效的寫一個跟他一樣的加密和解密方法出來的)。當你站點流量不是很大的時候沒有人會在乎你，但是當你流量上來之後，那麼所謂的外掛，所謂的群發就會接踵而來(從qq一開始的群發可見端倪)。也許我們可以很的意的說，我們可以採用更高階別的判斷甚至HTTPS來實現，注意，當你做這些處理的時候付出的將是海量的database，io以及CPU的成本。對於一些群發，基本上是不可能的。筆者已經可以實現對於百度空間和qq空間的群發了。大家願意試試，實際上並不是很難。

9、資料同步和叢集的處理的問題

當我們的一臺databaseserver不堪重負的時候，這個時候我們就需要做基於資料庫的負載和叢集了。而這個時候可能是最讓人困擾的的問題了，資料基於網路傳輸根據資料庫的設計的不同，資料延遲是很可怕的問題，也是不可避免的問題，這樣的話，我們就需要通過另外的手段來保證在這延遲的幾秒或者更長的幾分鐘時間內，實現有效的互動。比如資料雜湊，分割，內容處理等等問題

10、資料共享的渠道以及OPENAPI趨勢

Openapi已經成為一個不可避免的趨勢，從google，facebook，myspace到海內校內，都在考慮這個問題，它可以更有效的留住使用者並激發使用者的更多的興趣以及讓更多的人幫助你做最有效的開發。這個時候一個有效的資料共享平臺，資料開放平臺就成為必不可少的途徑了，而在開放的介面的情況保證資料的安全性和效能，又是一個我們必須要認真思考的問題了。