這裏的大(dà)型網站(zhàn)架構隻包括高(gāo)互動性高(gāo)交互性的數(shù)據型大(dà)型網站(zhàn)，基于大(dà)家(jiā)衆所周知的原因，我們就不談新聞類和(hé)一些(xiē)依靠HTML靜态化就可(kě)以實現的架構了，我們以高(gāo)負載高(gāo)數(shù)據交換高(gāo)數(shù)據流動性的網站(zhàn)為(wèi)例，比如海內(nèi)，開(kāi)心網等類似的web2.0系列架構。我們這裏不討(tǎo)論是PHP還(hái)是JSP或者.NET環境，我們從架構的方面去看問題，實現語言方面并不是問題，語言的優勢在于實現而不是好壞，不論你(nǐ)選擇任何語言，架構都是必須要面對的。

這裏討(tǎo)論一下大(dà)型網站(zhàn)需要注意和(hé)考慮的問題

1、海量數(shù)據的處理(lǐ)

衆所周知，對于一些(xiē)相對小(xiǎo)的站(zhàn)點來(lái)說，數(shù)據量并不是很(hěn)大(dà)，select和(hé)update就可(kě)以解決我們面對的問題，本身負載量不是很(hěn)大(dà)，最多(duō)再加幾個(gè)索引就可(kě)以搞定。對于大(dà)型網站(zhàn)，每天的數(shù)據量可(kě)能就上(shàng)百萬，如果一個(gè)設計(jì)不好的多(duō)對多(duō)關系，在前期是沒有(yǒu)任何問題的，但(dàn)是随着用戶的增長，數(shù)據量會(huì)是幾何級的增長的。在這個(gè)時(shí)候我們對于一個(gè)表的select和(hé)update的時(shí)候(還(hái)不說多(duō)表聯合查詢)的成本的非常高(gāo)的。

2、數(shù)據并發的處理(lǐ)

在一些(xiē)時(shí)候，2.0的CTO都有(yǒu)個(gè)尚方寶劍，就是緩存。對于緩存，在高(gāo)并發高(gāo)處理(lǐ)的時(shí)候也是個(gè)大(dà)問題。在整個(gè)應用程序下，緩存是全局共享的，然而在我們進行(xíng)修改的時(shí)候就，如果兩個(gè)或者多(duō)個(gè)請(qǐng)求同時(shí)對緩存有(yǒu)更新的要求的情況下，應用程序會(huì)直接的死掉。這個(gè)時(shí)候，就需要一個(gè)好的數(shù)據并發處理(lǐ)策略以及緩存策略。

另外，就是數(shù)據庫的死鎖問題，也許平時(shí)我們感覺不到，死鎖在高(gāo)并發的情況下的出現的概率是非常高(gāo)的，磁盤緩存就是一個(gè)大(dà)問題。

3、文件存貯的問題

對于一些(xiē)支持文件上(shàng)傳的2.0的站(zhàn)點，在慶幸硬盤容量越來(lái)越大(dà)的時(shí)候我們更多(duō)的應該考慮的是文件應該如何被存儲并且被有(yǒu)效的索引。常見的方案是對文件按照日期和(hé)類型進行(xíng)存貯。但(dàn)是當文件量是海量的數(shù)據的情況下，如果一塊硬盤存貯了500個(gè)G的瑣碎文件，那(nà)麽維護的時(shí)候和(hé)使用的時(shí)候磁盤的Io就是一個(gè)巨大(dà)的問題，哪怕你(nǐ)的帶寬足夠，但(dàn)是你(nǐ)的磁盤也未必響應過來(lái)。如果這個(gè)時(shí)候還(hái)涉及上(shàng)傳，磁盤很(hěn)容易就over了。

也許用raid和(hé)專用存貯服務器(qì)能解決眼下的問題，但(dàn)是還(hái)有(yǒu)個(gè)問題就是各地的訪問問題，也許我們的服務器(qì)在北京，可(kě)能在雲南或者新疆的訪問速度如何解決?如果做(zuò)分布式，那(nà)麽我們的文件索引以及架構該如何規劃。

所以我們不得(de)不承認，文件存貯是個(gè)很(hěn)不容易的問題

4、數(shù)據關系的處理(lǐ)

我們可(kě)以很(hěn)容易的規劃出一個(gè)符合第三範式的數(shù)據庫，裏面布滿了多(duō)對多(duō)關系，還(hái)能用GUID來(lái)替換INDENTIFY COLUMN 但(dàn)是，多(duō)對多(duō)關系充斥的2.0時(shí)代，第三範式是第一個(gè)應該被抛棄的。必須有(yǒu)效的把多(duō)表聯合查詢降到最低(dī)。

5、數(shù)據索引的問題

衆所周知，索引是提高(gāo)數(shù)據庫效率查詢的最方面最廉價最容易實現的方案。但(dàn)是，在高(gāo)UPDATE的情況下，update和(hé)delete付出的成本會(huì)高(gāo)的無法想想，筆者遇到過一個(gè)情況，在更新一個(gè)聚焦索引的時(shí)候需要10分鍾來(lái)完成，那(nà)麽對于站(zhàn)點來(lái)說，這些(xiē)基本上(shàng)是不可(kě)忍受的。

索引和(hé)更新是一對天生(shēng)的冤家(jiā)，問題A，D，E這些(xiē)是我們在做(zuò)架構的時(shí)候不得(de)不考慮的問題，并且也可(kě)能是花(huā)費時(shí)間(jiān)最多(duō)的問題。

6、分布式處理(lǐ)

對于2.0網站(zhàn)由于其高(gāo)互動性，CDN實現的效果基本上(shàng)為(wèi)0，內(nèi)容是實時(shí)更新的，我們常規的處理(lǐ)。為(wèi)了保證各地的訪問速度，我們就需要面對一個(gè)絕大(dà)的問題，就是如何有(yǒu)效的實現數(shù)據同步和(hé)更新，實現各地服務器(qì)的實時(shí)通(tōng)訊有(yǒu)是一個(gè)不得(de)不需要考慮的問題。

7、Ajax的利弊分析

成也AJAX，敗也AJAX，AJAX成為(wèi)了主流趨勢，突然發現基于XMLHTTP的post和(hé)get是如此的容易。客戶端get或者post 到服務器(qì)數(shù)據，服務器(qì)接到數(shù)據請(qǐng)求之後返回來(lái)，這是一個(gè)很(hěn)正常的AJAX請(qǐng)求。但(dàn)是在AJAX處理(lǐ)的時(shí)候，如果我們使用一個(gè)抓包工具的話(huà)，對數(shù)據返回和(hé)處理(lǐ)是一目了然。對于一些(xiē)計(jì)算(suàn)量大(dà)的AJAX請(qǐng)求的話(huà)，我們可(kě)以構造一個(gè)發包機，很(hěn)容易就可(kě)以把一個(gè)webserver幹掉。

8、數(shù)據安全性的分析

對于HTTP協議來(lái)說，數(shù)據包都是明(míng)文傳輸的，也許我們可(kě)以說我們可(kě)以用加密啊，但(dàn)是對于G問題來(lái)說的話(huà)，加密的過程就可(kě)能是明(míng)文了(比如我們知道(dào)的QQ，可(kě)以很(hěn)容易的判斷他的加密，并有(yǒu)效的寫一個(gè)跟他一樣的加密和(hé)解密方法出來(lái)的)。當你(nǐ)站(zhàn)點流量不是很(hěn)大(dà)的時(shí)候沒有(yǒu)人(rén)會(huì)在乎你(nǐ)，但(dàn)是當你(nǐ)流量上(shàng)來(lái)之後，那(nà)麽所謂的外挂，所謂的群發就會(huì)接踵而來(lái)(從qq一開(kāi)始的群發可(kě)見端倪)。也許我們可(kě)以很(hěn)的意的說，我們可(kě)以采用更高(gāo)級别的判斷甚至HTTPS來(lái)實現，注意，當你(nǐ)做(zuò)這些(xiē)處理(lǐ)的時(shí)候付出的将是海量的database，io以及CPU的成本。對于一些(xiē)群發，基本上(shàng)是不可(kě)能的。筆者已經可(kě)以實現對于百度空(kōng)間(jiān)和(hé)qq空(kōng)間(jiān)的群發了。大(dà)家(jiā)願意試試，實際上(shàng)并不是很(hěn)難。

9、數(shù)據同步和(hé)集群的處理(lǐ)的問題

當我們的一台databaseserver不堪重負的時(shí)候，這個(gè)時(shí)候我們就需要做(zuò)基于數(shù)據庫的負載和(hé)集群了。而這個(gè)時(shí)候可(kě)能是最讓人(rén)困擾的的問題了，數(shù)據基于網絡傳輸根據數(shù)據庫的設計(jì)的不同，數(shù)據延遲是很(hěn)可(kě)怕的問題，也是不可(kě)避免的問題，這樣的話(huà)，我們就需要通(tōng)過另外的手段來(lái)保證在這延遲的幾秒(miǎo)或者更長的幾分鍾時(shí)間(jiān)內(nèi)，實現有(yǒu)效的交互。比如數(shù)據散列，分割，內(nèi)容處理(lǐ)等等問題。

10、數(shù)據共享的渠道(dào)以及OPENAPI趨勢

Openapi已經成為(wèi)一個(gè)不可(kě)避免的趨勢，從google，facebook，myspace到海內(nèi)校(xiào)內(nèi)，都在考慮這個(gè)問題，它可(kě)以更有(yǒu)效的留住用戶并激發用戶的更多(duō)的興趣以及讓更多(duō)的人(rén)幫助你(nǐ)做(zuò)最有(yǒu)效的開(kāi)發。這個(gè)時(shí)候一個(gè)有(yǒu)效的數(shù)據共享平台，數(shù)據開(kāi)放平台就成為(wèi)必不可(kě)少(shǎo)的途徑了，而在開(kāi)放的接口的情況保證數(shù)據的安全性和(hé)性能，又是一個(gè)我們必須要認真思考的問題了。