這兒的大型網(wǎng)站架構(gòu)只包括高互動(dòng)性高交互性的數(shù)據(jù)型大型網(wǎng)站，根據(jù)咱們眾所周知的原因，咱們就不談新聞?lì)惡鸵恍┮揽縃TML靜態(tài)化就能夠完成的架構(gòu)了，咱們以高負(fù)載高數(shù)據(jù)交換高數(shù)據(jù)流動(dòng)性的網(wǎng)站為例，比如國(guó)內(nèi)，開心網(wǎng)等相似的web2.0系列架構(gòu)。咱們這兒不評(píng)論是PHP仍是JSP或許.NET環(huán)境，咱們從架構(gòu)的方面去看問題，完成言語(yǔ)方面并不是問題，言語(yǔ)的優(yōu)勢(shì)在于完成而不是好壞，不論你選擇任何言語(yǔ)，架構(gòu)都是有必要要面臨的。

這兒評(píng)論一下大型網(wǎng)站需要留意和考慮的問題

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

眾所周知，關(guān)于一些相對(duì)小的站點(diǎn)來說，數(shù)據(jù)量并不是很大，select和update就能夠處理咱們面臨的問題，本身負(fù)載量不是很大，最多再加幾個(gè)索引就能夠搞定。關(guān)于大型網(wǎng)站，每天的數(shù)據(jù)量或許就上百萬(wàn)，假如一個(gè)規(guī)劃不好的多對(duì)多聯(lián)系，在前期是沒有任何問題的，可是隨著用戶的增加，數(shù)據(jù)量會(huì)是幾許級(jí)的增加的。在這個(gè)時(shí)分咱們關(guān)于一個(gè)表的select和update的時(shí)分(還不說多表聯(lián)合查詢)的成本的十分高的。

2、數(shù)據(jù)并發(fā)的處理

在一些時(shí)分，2.0的CTO都有個(gè)尚方寶劍，便是緩存。關(guān)于緩存，在高并發(fā)高處理的時(shí)分也是個(gè)大問題。在整個(gè)應(yīng)用程序下，緩存是大局同享的，然而在咱們進(jìn)行修正的時(shí)分就，假如兩個(gè)或許多個(gè)懇求同時(shí)對(duì)緩存有更新的要求的情況下，應(yīng)用程序會(huì)直接的死掉。這個(gè)時(shí)分，就需要一個(gè)好的數(shù)據(jù)并發(fā)處理策略以及緩存策略。

別的，便是數(shù)據(jù)庫(kù)的死鎖問題，或許平常咱們感覺不到，死鎖在高并發(fā)的情況下的呈現(xiàn)的概率是十分高的，磁盤緩存便是一個(gè)大問題。

3、文件存貯的問題

關(guān)于一些支撐文件上傳的2.0的站點(diǎn)，在慶幸硬盤容量越來越大的時(shí)分咱們更多的應(yīng)該考慮的是文件應(yīng)該怎么被存儲(chǔ)而且被有用的索引。常見的計(jì)劃是對(duì)文件依照日期和類型進(jìn)行存貯�？墒钱�(dāng)文件量是海量的數(shù)據(jù)的情況下，假如一塊硬盤存貯了500個(gè)G的瑣碎文件，那么維護(hù)的時(shí)分和使用的時(shí)分磁盤的Io便是一個(gè)巨大的問題，哪怕你的帶寬足夠，可是你的磁盤也未必呼應(yīng)過來。假如這個(gè)時(shí)分還涉及上傳，磁盤很簡(jiǎn)單就over了。

或許用raid和專用存貯服務(wù)器能處理眼下的問題，可是還有個(gè)問題便是各地的訪問問題，或許咱們的服務(wù)器在北京，或許在云南或許新疆的訪問速度怎么處理?假如做分布式，那么咱們的文件索引以及架構(gòu)該怎么規(guī)劃。

所以咱們不得不供認(rèn)，文件存貯是個(gè)很不簡(jiǎn)單的問題

4、數(shù)據(jù)聯(lián)系的處理

咱們能夠很簡(jiǎn)單的規(guī)劃出一個(gè)符合第三范式的數(shù)據(jù)庫(kù)，里邊布滿了多對(duì)多聯(lián)系，還能用GUID來替換INDENTIFY COLUMN 可是，多對(duì)多聯(lián)系充滿的2.0時(shí)代，第三范式是第一個(gè)應(yīng)該被拋棄的。有必要有用的把多表聯(lián)合查詢降到最低。

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

眾所周知，索引是提高數(shù)據(jù)庫(kù)效率查詢的最方面最廉價(jià)最簡(jiǎn)單完成的計(jì)劃。可是，在高UPDATE的情況下，update和delete付出的成本會(huì)高的無(wú)法想想，筆者遇到過一個(gè)情況，在更新一個(gè)聚焦索引的時(shí)分需要10分鐘來完成，那么關(guān)于站點(diǎn)來說，這些基本上是不可忍受的。

索引和更新是一對(duì)天生的冤家，問題A，D，E這些是咱們?cè)谧黾軜?gòu)的時(shí)分不得不考慮的問題，而且也或許是花費(fèi)時(shí)刻最多的問題，

6、分布式處理

關(guān)于2.0網(wǎng)站因?yàn)槠涓呋��?dòng)性，CDN完成的效果基本上為0，內(nèi)容是實(shí)時(shí)更新的，咱們常規(guī)的處理。為了確保各地的訪問速度，咱們就需要面臨一個(gè)絕大的問題，便是怎么有用的完成數(shù)據(jù)同步和更新，完成各地服務(wù)器的實(shí)時(shí)通訊有是一個(gè)不得不需要考慮的問題。

7、Ajax的利害剖析

成也AJAX，敗也AJAX，AJAX成為了干流趨勢(shì)，突然發(fā)現(xiàn)根據(jù)XMLHTTP的post和get是如此的簡(jiǎn)單。客戶端get或許post 到服務(wù)器數(shù)據(jù)，服務(wù)器接到數(shù)據(jù)懇求之后返回來，這是一個(gè)很正常的AJAX懇求�？墒窃贏JAX處理的時(shí)分，假如咱們使用一個(gè)抓包東西的話，對(duì)數(shù)據(jù)返回和處理是一望而知。關(guān)于一些計(jì)算量大的AJAX懇求的話，咱們能夠構(gòu)造一個(gè)發(fā)包機(jī)，很簡(jiǎn)單就能夠把一個(gè)webserver干掉。

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

關(guān)于HTTP協(xié)議來說，數(shù)據(jù)包都是明文傳輸?shù)�，或許咱們能夠說咱們能夠用加密啊，可是關(guān)于G問題來說的話，加密的進(jìn)程就或許是明文了(比如咱們知道的QQ，能夠很簡(jiǎn)單的判斷他的加密，并有用的寫一個(gè)跟他相同的加密和解密方法出來的)。當(dāng)你站點(diǎn)流量不是很大的時(shí)分沒有人會(huì)在乎你，可是當(dāng)你流量上來之后，那么所謂的外掛，所謂的群發(fā)就會(huì)接踵而來(從qq一開始的群發(fā)可見端倪)�；蛟S咱們能夠很的意的說，咱們能夠選用更高等級(jí)的判斷甚至HTTPS來完成，留意，當(dāng)你做這些處理的時(shí)分付出的將是海量的database，io以及CPU的成本。關(guān)于一些群發(fā)，基本上是不或許的。筆者已經(jīng)能夠完成關(guān)于百度空間和qq空間的群發(fā)了。咱們?cè)敢庠囋�，�?shí)際上并不是很難。

9、數(shù)據(jù)同步和集群的處理的問題

當(dāng)咱們的一臺(tái)databaseserver不堪重負(fù)的時(shí)分，這個(gè)時(shí)分咱們就需要做根據(jù)數(shù)據(jù)庫(kù)的負(fù)載和集群了。而這個(gè)時(shí)分或許是最讓人困擾的的問題了，數(shù)據(jù)根據(jù)網(wǎng)絡(luò)傳輸根據(jù)數(shù)據(jù)庫(kù)的規(guī)劃的不同，數(shù)據(jù)延遲是很可怕的問題，也是不可避免的問題，這樣的話，咱們就需要通過別的的手段來確保在這延遲的幾秒或許更長(zhǎng)的幾分鐘時(shí)刻內(nèi)，完成有用的交互。比如數(shù)據(jù)散列，切割，內(nèi)容處理等等問題

10、數(shù)據(jù)同享的途徑以及OPENAPI趨勢(shì)

Openapi已經(jīng)成為一個(gè)不可避免的趨勢(shì)，從google，facebook，myspace到國(guó)內(nèi)校內(nèi)，都在考慮這個(gè)問題，它能夠更有用的留住用戶并激起用戶的更多的興趣以及讓更多的人幫助你做最有用的開發(fā)。這個(gè)時(shí)分一個(gè)有用的數(shù)據(jù)同享渠道，數(shù)據(jù)敞開渠道就成為必不可少的途徑了，而在敞開的接口的情況確保數(shù)據(jù)的安全性和性能，又是一個(gè)咱們有必要要認(rèn)真思考的問題了