這兒的大型網(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)，開(kāi)心網(wǎng)等相似的web2.0系列架構(gòu)。咱們這兒不評(píng)論是PHP仍是JSP或許.NET環(huán)境，咱們從架構(gòu)的方面去看問(wèn)題，完成言語(yǔ)方面并不是問(wèn)題，言語(yǔ)的優(yōu)勢(shì)在于完成而不是好壞，不論你選擇任何言語(yǔ)，架構(gòu)都是有必要要面臨的。

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

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

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

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

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

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

3、文件存貯的問(wèn)題

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

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

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

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

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

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

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

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

6、分布式處理

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

7、Ajax的利害剖析

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

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

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

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

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

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

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