大型網站架構不得不考慮的10個問題

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

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

1、海量數據的處理

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

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

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

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

3、文件存貯的問題

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

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

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

4、數據聯系的處理

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

5、數據索引的問題

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

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

6、分布式處理

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

7、Ajax的利害剖析

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

8、數據安全性的剖析

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

9、數據同步和集群的處理的問題

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

10、數據同享的途徑以及OPENAPI趨勢

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