這里的大型網(wǎng)站架構(gòu)只包括高互動性高交互性的數(shù)據(jù)型大型網(wǎng)站，基于大家眾所周知的原因，我們就不談新聞類和一些依靠HTML靜態(tài)化就可以實(shí)現(xiàn)的架構(gòu) 了，我們以高負(fù)載高數(shù)據(jù)交換高數(shù)據(jù)流動性的網(wǎng)站為例，比如海內(nèi)，開心網(wǎng)等類似的web2.0系列架構(gòu)。我們這里不討論是PHP還是JSP或者.NET環(huán) 境，我們從架構(gòu)的方面去看問題，實(shí)現(xiàn)語言方面并不是問題，語言的優(yōu)勢在于實(shí)現(xiàn)而不是好壞，不論你選擇任何語言，架構(gòu)都是必須要面對的。
這里討論一下大型網(wǎng)站需要注意和考慮的問題
1、海量數(shù)據(jù)的處理
眾所周知，對于一些相對小的站點(diǎn)來說，數(shù)據(jù)量并不是很大，select和update就可以解決我們面對的問題，本身負(fù)載量不是很大，最多再加幾個(gè) 索引就可以搞定。對于大型網(wǎng)站，每天的數(shù)據(jù)量可能就上百萬，如果一個(gè)設(shè)計(jì)不好的多對多關(guān)系，在前期是沒有任何問題的，但是隨著用戶的增長，數(shù)據(jù)量會是幾何 級的增長的。在這個(gè)時(shí)候我們對于一個(gè)表的select和update的時(shí)候(還不說多表聯(lián)合查詢)的成本的非常高的。
2、數(shù)據(jù)并發(fā)的處理
在一些時(shí)候，2.0的CTO都有個(gè)尚方寶劍，就是緩存。對于緩存，在高并發(fā)高處理的時(shí)候也是個(gè)大問題。在整個(gè)應(yīng)用程序下，緩存是全局共享的，然而在 我們進(jìn)行修改的時(shí)候就，如果兩個(gè)或者多個(gè)請求同時(shí)對緩存有更新的要求的情況下，應(yīng)用程序會直接的死掉。這個(gè)時(shí)候，就需要一個(gè)好的數(shù)據(jù)并發(fā)處理策略以及緩存 策略。
另外，就是數(shù)據(jù)庫的死鎖問題，也許平時(shí)我們感覺不到，死鎖在高并發(fā)的情況下的出現(xiàn)的概率是非常高的，磁盤緩存就是一個(gè)大問題。
3、文件存貯的問題
對于一些支持文件上傳的2.0的站點(diǎn)，在慶幸硬盤容量越來越大的時(shí)候我們更多的應(yīng)該考慮的是文件應(yīng)該如何被存儲并且被有效的索引。常見的方案是對文 件按照日期和類型進(jìn)行存貯。但是當(dāng)文件量是海量的數(shù)據(jù)的情況下，如果一塊硬盤存貯了500個(gè)G的瑣碎文件，那么維護(hù)的時(shí)候和使用的時(shí)候磁盤的Io就是一個(gè) 巨大的問題，哪怕你的帶寬足夠，但是你的磁盤也未必響應(yīng)過來。如果這個(gè)時(shí)候還涉及上傳，磁盤很容易就over了。
也許用raid和專用存貯服務(wù)器能解決眼下的問題，但是還有個(gè)問題就是各地的訪問問題，也許我們的服務(wù)器在北京，可能在云南或者新疆的訪問速度如何解決?如果做分布式，那么我們的文件索引以及架構(gòu)該如何規(guī)劃。
所以我們不得不承認(rèn)，文件存貯是個(gè)很不容易的問題
4、數(shù)據(jù)關(guān)系的處理
我們可以很容易的規(guī)劃出一個(gè)符合第三范式的數(shù)據(jù)庫，里面布滿了多對多關(guān)系，還能用GUID來替換INDENTIFY COLUMN 但是，多對多關(guān)系充斥的2.0時(shí)代，第三范式是第一個(gè)應(yīng)該被拋棄的。必須有效的把多表聯(lián)合查詢降到最低。
5、數(shù)據(jù)索引的問題
眾所周知，索引是提高數(shù)據(jù)庫效率查詢的最方面最廉價(jià)最容易實(shí)現(xiàn)的方案。但是，在高UPDATE的情況下，update和delete付出的成本會高的無法想想，筆者遇到過一個(gè)情況，在更新一個(gè)聚焦索引的時(shí)候需要10分鐘來完成，那么對于站點(diǎn)來說，這些基本上是不可忍受的。
索引和更新是一對天生的冤家，問題A，D，E這些是我們在做架構(gòu)的時(shí)候不得不考慮的問題，并且也可能是花費(fèi)時(shí)間最多的問題，
6、分布式處理
對于2.0網(wǎng)站由于其高互動性，CDN實(shí)現(xiàn)的效果基本上為0，內(nèi)容是實(shí)時(shí)更新的，我們常規(guī)的處理。為了保證各地的訪問速度，我們就需要面對一個(gè)絕大的問題，就是如何有效的實(shí)現(xiàn)數(shù)據(jù)同步和更新，實(shí)現(xiàn)各地服務(wù)器的實(shí)時(shí)通訊有是一個(gè)不得不需要考慮的問題。
7、Ajax的利弊分析
成也AJAX，敗也AJAX，AJAX成為了主流趨勢，突然發(fā)現(xiàn)基于XMLHTTP的post和get是如此的容易。客戶端get或者post 到服務(wù)器數(shù)據(jù)，服務(wù)器接到數(shù)據(jù)請求之后返回來，這是一個(gè)很正常的AJAX請求。但是在AJAX處理的時(shí)候，如果我們使用一個(gè)抓包工具的話，對數(shù)據(jù)返回和處 理是一目了然。對于一些計(jì)算量大的AJAX請求的話，我們可以構(gòu)造一個(gè)發(fā)包機(jī)，很容易就可以把一個(gè)webserver干掉。
8、數(shù)據(jù)安全性的分析
對于HTTP協(xié)議來說，數(shù)據(jù)包都是明文傳輸?shù)模苍S我們可以說我們可以用加密啊，但是對于G問題來說的話，加密的過程就可能是明文了(比如我們知道 的QQ，可以很容易的判斷他的加密，并有效的寫一個(gè)跟他一樣的加密和解密方法出來的)。當(dāng)你站點(diǎn)流量不是很大的時(shí)候沒有人會在乎你，但是當(dāng)你流量上來之 后，那么所謂的外掛，所謂的群發(fā)就會接踵而來(從qq一開始的群發(fā)可見端倪)。也許我們可以很的意的說，我們可以采用更高級別的判斷甚至HTTPS來實(shí) 現(xiàn)，注意，當(dāng)你做這些處理的時(shí)候付出的將是海量的database，io以及CPU的成本。對于一些群發(fā)，基本上是不可能的。筆者已經(jīng)可以實(shí)現(xiàn)對于百度空 間和qq空間的群發(fā)了。大家愿意試試，實(shí)際上并不是很難。
9、數(shù)據(jù)同步和集群的處理的問題
當(dāng)我們的一臺databaseserver不堪重負(fù)的時(shí)候，這個(gè)時(shí)候我們就需要做基于數(shù)據(jù)庫的負(fù)載和集群了。而這個(gè)時(shí)候可能是最讓人困擾的的問題 了，數(shù)據(jù)基于網(wǎng)絡(luò)傳輸根據(jù)數(shù)據(jù)庫的設(shè)計(jì)的不同，數(shù)據(jù)延遲是很可怕的問題，也是不可避免的問題，這樣的話，我們就需要通過另外的手段來保證在這延遲的幾秒或 者更長的幾分鐘時(shí)間內(nèi)，實(shí)現(xiàn)有效的交互。比如數(shù)據(jù)散列，分割，內(nèi)容處理等等問題
10、數(shù)據(jù)共享的渠道以及OPENAPI趨勢
Openapi已經(jīng)成為一個(gè)不可避免的趨勢，從google，facebook，myspace到海內(nèi)校內(nèi)，都在考慮這個(gè)問題，它可以更有效的留住 用戶并激發(fā)用戶的更多的興趣以及讓更多的人幫助你做最有效的開發(fā)。這個(gè)時(shí)候一個(gè)有效的數(shù)據(jù)共享平臺，數(shù)據(jù)開放平臺就成為必不可少的途徑了，而在開放的接口 的情況保證數(shù)據(jù)的安全性和性能，又是一個(gè)我們必須要認(rèn)真思考的問題了。