<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    常言笑的家

    Spring, Hibernate, Struts, Ajax, RoR

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

    這里的大型網站架構只包括高互動性高交互性的數據型大型網站,基于大家眾所周知的原因,我們就不談新聞類和一些依靠HTML靜態化就可以實現的架構 了,我們以高負載高數據交換高數據流動性的網站為例,比如海內,開心網等類似的web2.0系列架構。我們這里不討論是PHP還是JSP或者.NET環 境,我們從架構的方面去看問題,實現語言方面并不是問題,語言的優勢在于實現而不是好壞,不論你選擇任何語言,架構都是必須要面對的。

    這里討論一下大型網站需要注意和考慮的問題

    1、海量數據的處理

    眾所周知,對于一些相對小的站點來說,數據量并不是很大,select和update就可以解決我們面對的問題,本身負載量不是很大,最多再加幾個 索引就可以搞定。對于大型網站,每天的數據量可能就上百萬,如果一個設計不好的多對多關系,在前期是沒有任何問題的,但是隨著用戶的增長,數據量會是幾何 級的增長的。在這個時候我們對于一個表的select和update的時候(還不說多表聯合查詢)的成本的非常高的。

    2、數據并發的處理

    在一些時候,2.0的CTO都有個尚方寶劍,就是緩存。對于緩存,在高并發高處理的時候也是個大問題。在整個應用程序下,緩存是全局共享的,然而在 我們進行修改的時候就,如果兩個或者多個請求同時對緩存有更新的要求的情況下,應用程序會直接的死掉。這個時候,就需要一個好的數據并發處理策略以及緩存 策略。

    另外,就是數據庫的死鎖問題,也許平時我們感覺不到,死鎖在高并發的情況下的出現的概率是非常高的,磁盤緩存就是一個大問題。

    3、文件存貯的問題

    對于一些支持文件上傳的2.0的站點,在慶幸硬盤容量越來越大的時候我們更多的應該考慮的是文件應該如何被存儲并且被有效的索引。常見的方案是對文 件按照日期和類型進行存貯。但是當文件量是海量的數據的情況下,如果一塊硬盤存貯了500個G的瑣碎文件,那么維護的時候和使用的時候磁盤的Io就是一個 巨大的問題,哪怕你的帶寬足夠,但是你的磁盤也未必響應過來。如果這個時候還涉及上傳,磁盤很容易就over了。

    也許用raid和專用存貯服務器能解決眼下的問題,但是還有個問題就是各地的訪問問題,也許我們的服務器在北京,可能在云南或者新疆的訪問速度如何解決?如果做分布式,那么我們的文件索引以及架構該如何規劃。

    所以我們不得不承認,文件存貯是個很不容易的問題

    4、數據關系的處理

    我們可以很容易的規劃出一個符合第三范式的數據庫,里面布滿了多對多關系,還能用GUID來替換INDENTIFY COLUMN 但是,多對多關系充斥的2.0時代,第三范式是第一個應該被拋棄的。必須有效的把多表聯合查詢降到最低。

    5、數據索引的問題

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

    索引和更新是一對天生的冤家,問題A,D,E這些是我們在做架構的時候不得不考慮的問題,并且也可能是花費時間最多的問題,

    6、分布式處理

    對于2.0網站由于其高互動性,CDN實現的效果基本上為0,內容是實時更新的,我們常規的處理。為了保證各地的訪問速度,我們就需要面對一個絕大的問題,就是如何有效的實現數據同步和更新,實現各地服務器的實時通訊有是一個不得不需要考慮的問題。

    7、Ajax的利弊分析

    成也AJAX,敗也AJAX,AJAX成為了主流趨勢,突然發現基于XMLHTTP的post和get是如此的容易。客戶端get或者post 到服務器數據,服務器接到數據請求之后返回來,這是一個很正常的AJAX請求。但是在AJAX處理的時候,如果我們使用一個抓包工具的話,對數據返回和處 理是一目了然。對于一些計算量大的AJAX請求的話,我們可以構造一個發包機,很容易就可以把一個webserver干掉。

    8、數據安全性的分析

    對于HTTP協議來說,數據包都是明文傳輸的,也許我們可以說我們可以用加密啊,但是對于G問題來說的話,加密的過程就可能是明文了(比如我們知道 的QQ,可以很容易的判斷他的加密,并有效的寫一個跟他一樣的加密和解密方法出來的)。當你站點流量不是很大的時候沒有人會在乎你,但是當你流量上來之 后,那么所謂的外掛,所謂的群發就會接踵而來(從qq一開始的群發可見端倪)。也許我們可以很的意的說,我們可以采用更高級別的判斷甚至HTTPS來實 現,注意,當你做這些處理的時候付出的將是海量的database,io以及CPU的成本。對于一些群發,基本上是不可能的。筆者已經可以實現對于百度空 間和qq空間的群發了。大家愿意試試,實際上并不是很難。

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

    當我們的一臺databaseserver不堪重負的時候,這個時候我們就需要做基于數據庫的負載和集群了。而這個時候可能是最讓人困擾的的問題 了,數據基于網絡傳輸根據數據庫的設計的不同,數據延遲是很可怕的問題,也是不可避免的問題,這樣的話,我們就需要通過另外的手段來保證在這延遲的幾秒或 者更長的幾分鐘時間內,實現有效的交互。比如數據散列,分割,內容處理等等問題

    10、數據共享的渠道以及OPENAPI趨勢

    Openapi已經成為一個不可避免的趨勢,從google,facebook,myspace到海內校內,都在考慮這個問題,它可以更有效的留住 用戶并激發用戶的更多的興趣以及讓更多的人幫助你做最有效的開發。這個時候一個有效的數據共享平臺,數據開放平臺就成為必不可少的途徑了,而在開放的接口 的情況保證數據的安全性和性能,又是一個我們必須要認真思考的問題了。

    posted on 2012-06-28 13:26 常言笑 閱讀(287) 評論(0)  編輯  收藏 所屬分類: 技術總結

    My Links

    Blog Stats

    常用鏈接

    留言簿(5)

    隨筆分類

    隨筆檔案

    搜索

    積分與排名

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲性日韩精品国产一区二区| 成人免费毛片内射美女-百度| 免费成人av电影| 亚洲av无码av在线播放| 免费黄色网址入口| 亚洲精品无码专区| 性做久久久久免费观看| 最新亚洲人成无码网www电影| 免费看a级黄色片| AV激情亚洲男人的天堂国语| 国产成人免费高清在线观看| 国产成人精品久久亚洲高清不卡 | 在线看片免费人成视频播| 亚洲色欲久久久综合网| 免费日本一区二区| 亚洲国产精品白丝在线观看| 四虎国产精品免费久久| 亚洲变态另类一区二区三区| 日韩精品成人亚洲专区| 久久精品免费网站网| 亚洲伦另类中文字幕| 人妻视频一区二区三区免费| 国产精品亚洲一区二区三区| 九月婷婷亚洲综合在线| 久久青草国产免费观看| 亚洲av无码一区二区三区天堂古代 | 久久久久亚洲AV成人无码| 最近2019免费中文字幕视频三| 亚洲av永久综合在线观看尤物| 热99re久久免费视精品频软件| 曰韩无码AV片免费播放不卡 | 成年人免费网站在线观看| 精品一区二区三区免费毛片| 亚洲日韩乱码中文无码蜜桃臀网站| 外国成人网在线观看免费视频| 亚洲1区1区3区4区产品乱码芒果| 国产成人3p视频免费观看| a级男女仿爱免费视频| ww亚洲ww在线观看国产| 亚洲国产黄在线观看| 最近中文字幕无免费|