大型網(wǎng)站架構(gòu)不得不考慮的10個問題

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

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

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

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

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

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

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

3、文件存貯的問題

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

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

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

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

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

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

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

索引和更新是一對天生的冤家，問題A，D，E這些是咱們在做架構(gòu)的時分不得不考慮的問題，而且也或許是花費時刻最多的問題，

6、分布式處理

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

7、Ajax的利害剖析

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

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

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

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

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

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

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