大型網(wǎng)站面臨的高負(fù)載和高并發(fā)問題，對(duì)于大型網(wǎng)站來說，所采用的技術(shù)更是涉及面非常廣，從硬件到軟件、編程語言、數(shù)據(jù)庫、WebServer、防火墻等 各個(gè)領(lǐng)域都有了很高的要求，已經(jīng)不是原來簡(jiǎn)單的html靜態(tài)網(wǎng)站所能比擬的。下面和池州網(wǎng)站制作的小編一起簡(jiǎn)單的看看其需要考慮的的問題及其技術(shù)分析；
1、海量數(shù)據(jù)的處理
眾所周知，對(duì)于一些相對(duì)小的站點(diǎn)來說，數(shù)據(jù)量并不是很大，select和update就可以解決我們面對(duì)的問題，本身負(fù)載量不是很大，最多再加 幾個(gè)索引就可以搞定。對(duì)于大型網(wǎng)站，每天的數(shù)據(jù)量可能就上百萬，如果一個(gè)設(shè)計(jì)不好的多對(duì)多關(guān)系，在前期是沒有任何問題的，但是隨著用戶的增長(zhǎng)，數(shù)據(jù)量會(huì)是 幾何級(jí)的增長(zhǎng)的。在這個(gè)時(shí)候我們對(duì)于一個(gè)表的select和update的時(shí)候(還不說多表聯(lián)合查詢)的成本的非常高的。
2、數(shù)據(jù)并發(fā)的處理
在一些時(shí)候，2.0的CTO都有個(gè)尚方寶劍，就是緩存。對(duì)于緩存，在高并發(fā)高處理的時(shí)候也是個(gè)大問題。在整個(gè)應(yīng)用程序下，緩存是全局共享的，然 而在我們進(jìn)行修改的時(shí)候就，如果兩個(gè)或者多個(gè)請(qǐng)求同時(shí)對(duì)緩存有更新的要求的情況下，應(yīng)用程序會(huì)直接的死掉。這個(gè)時(shí)候，就需要一個(gè)好的數(shù)據(jù)并發(fā)處理策略以及 緩存策略。
另外，就是數(shù)據(jù)庫的死鎖問題，也許平時(shí)我們感覺不到，死鎖在高并發(fā)的情況下的出現(xiàn)的概率是非常高的，磁盤緩存就是一個(gè)大問題。
3、文件存貯的問題
對(duì)于一些支持文件上傳的2.0的站點(diǎn)，在慶幸硬盤容量越來越大的時(shí)候我們更多的應(yīng)該考慮的是文件應(yīng)該如何被存儲(chǔ)并且被有效的索引。常見的方案是 對(duì)文件按照日期和類型進(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ù)庫，里面布滿了多對(duì)多關(guān)系，還能用GUID來替換INDENTIFY COLUMN 但是，多對(duì)多關(guān)系充斥的2.0時(shí)代，第三范式是第一個(gè)應(yīng)該被拋棄的。必須有效的把多表聯(lián)合查詢降到最低。
網(wǎng)站相關(guān)的技術(shù)經(jīng)過這些年的發(fā)展，已經(jīng)細(xì)分到很細(xì)的方方面面，更多網(wǎng)站建設(shè)相關(guān)信息資訊，請(qǐng)關(guān)注池州網(wǎng)站制作：http://www.eqm8.com。
