大型網站架構必須要面對的問題

2010年的大型網站,面對的問題已經不再是內容的集中廣播式展示的問題了,而是越來越多的用戶交互式應用及以因為這些應用產生的海量個性化數據。比如以用戶為中心大型電子商務網站、SNS社會化網絡、SocialGame以及其他新興的Web2.0模式的大型網站及應用。所以這里只討論高度交互性海量數據的大型網站,而不討論新聞類和一些依靠HTML靜態化就可以實現的Web1.0時代的網站架構。比如海內,開心網等類似的web2.0系列架構。我們這里也不討論站點是PHP、J2EE、.NET還是ROR、Python 等基礎運行環境。不管采用什么語言或基礎運行環境,架構都是我們所必須要面對的。

1、海量數據的處理
眾所周知,對于普通的小型網站來說,數據量并不算大,單一數據庫表的讀和寫就可以解決數據訪問的所有問題了。由于本身負載量不是很大,最多再加幾個索引,在性能上就可以 簡單的起到優化作用了。但是,對于大型網站來說,每天的數據量可能就上百萬,如果一個或者多個設計不好的多對多關系,是會存在巨大問題的。在網站上線的早期 ,用戶量少的時候,復雜的應用看起來可能沒有任何問題,但是隨著用戶的增長,數據量會是幾何級的增長的。在這個時候我們對于一個表的select和update的時候 的成本的非常昂貴的,更不用說多表聯合查詢等性能殺手了。所以海量數據的處理,對于大型交互類站點來說,是一個很大的問題,也是首先要解決的問題。因此,讀寫分離,分布式數據存儲是新一帶網站(高度交互和大型應用類站點)的CTO和決策層所不得不首要考慮的問題。

2、數據的并發和緩存
在某些時候,Web2.0和高度交互類站點的CTO都有個尚方寶劍,就是緩存。對于緩存,在高并發高處理的時候也是個大問題。在整個應用程序下,緩存是全局共享的,然而 當有多個用戶或者進程同時對同一個資源或者列表進行更新操作的時候,應用程序可能會出現沖突,或者直接崩潰。這個時候,就需要一個好的數據并發處理策略以及緩存策略。 另外,就是數據庫的死鎖問題,也許平時我們感覺不到,死鎖在高并發的情況下的出現的概率是非常高的,磁盤緩存這是就是一個大問題。 還有緩存的命中率也是一個值得注意的問題,如果緩存機制本身造成的命中率偏低,緩存不但不會提升性能,而且還有可能使網站系統付出高昂的代價。

3、海量文件存貯的問題
對于支持多種文件上傳和分享的網站管理者來說,在慶幸硬盤容量越來越大的時候,我們更多的應該考慮的是文件應該如何被存儲并且被有效的索引。常見的方案是對文件按照日期和類型進行存貯。但是當 用戶量巨大時,文件的數量和需要的總體存儲容量都將是海量的數據。在這種情況下,如果一塊硬盤存貯了500個G的瑣碎文件,那么維護和使用的時候磁盤的IO就是一個巨大的問題 。即便你有足夠的帶寬,但是你的磁盤也未必能響應過來。因為問題不是出在網絡傳輸上。如果這個時候還涉及上傳,磁盤很容易就會崩潰了。也許用raid和專用存貯服務器能解決 一時的問題,但是當同時上傳的用戶足夠多時,又會出現新問題。這就需要做出能順利橫向擴展的分布式文件系統了。另外一個問題就是各地的訪問問題,也許您的服務器在北京,可 是在廣州或者西安的訪問速度如何解決?如果做區域的分布式,那么您的文件索引以及架構該如何規劃又是必須面對的問題了。 所以對我們來說,海量文件存貯是個很不容易的問題。

4、數據關系的處理
我們可以很容易的規劃和設計出一個符合第三范式的數據庫,里面布滿了多對多關系,還能用GUID來替換INDENTIFY COLUMN。但是,多對多關系 在高度交互的Web2.0時代需要有合理的解決模式,第三范式在這種情況是第一個應該被完全拋棄的。必須有效的把多表聯合查詢降到最低。數據關系優化,是必須認真對待的。

5、數據索引的問題
技術人員都知道,索引是提高數據庫效率查詢的最方面最廉價也最容易實現的方式。但是,在高數據寫入和更新的情況下,update和delete付出的成本會高 得超出您的想象。有項目經驗的資深技術人士都會遇到類似的情況,在更新一個聚焦索引的時候需要幾分鐘甚至更長時間來完成,那么對于一個網站來說,這基本上是用戶不能忍受的。 索引和更新是一對天生的矛與盾,在做架構的時候,我們是需要認真設計這一塊的,這也是數據結構優化的一個重要問題所在。

6、分布式處理
對于2.0網站由于其高互動性,CDN那種用于解決Web1.0訪問性能問題的實現效果基本上無用武之地,因為內容是實時更新的。但是,我們仍然要要保證各地的訪問速度, 那么,我們必須要面對一個的同樣的問題,如何有效的實現數據同步和更新。實現各地服務器的數據的實時通訊又有是一個不得不考慮的問題。

7、數據安全性的分析
對于HTTP協議來說,數據包都是明文傳輸的,也許有人說我們可以用加密的,但是加密是否有效,以及加密解密的成本又如何規劃呢。當你站點流量不是很大的時候沒有人會在乎你,但是當你流量上來之后,那么所謂的外掛,所謂的群發就會接踵而來(從qq和各種網游的現狀就能看出來這些問題)。也許我們可以很的意的說,我們可以采用更高級別的判斷甚至HTTPS來實現,注意,當你做這些處理的時候付出的將是海量的 數據時,IO、加密解密以及CPU的成本將會是非常高昂的。所以,數據安全對于高度交互的站點的技術團隊來說。又是一個棘手的問題。

8、數據同步和集群的處理的問題
當我們的一臺數據庫服務器不堪重負的時候,我們就需要做基于數據庫的負載和集群了。數據是基于網絡傳輸的,數據以一種格式化的形式存儲在某個庫或者某個數據表中,而不管是數據 網絡傳輸的延遲 ,還是訪問數據庫或者表的數據時,或者是這個DBMS運行的基礎操作系統的IO瓶頸。這些性能問題,一個點,就足以破壞一整片。而這些問題又往往是不可避免的。因此,我們就需要通過 技術手段來保證在這延遲的幾秒或者更長的幾分鐘時間內,實現有效的交互。比如數據散列,分割,內容處理等等問題 。當然,還有高可用的問題。這些也都是我們需要考慮和面對的。

9、數據的全文檢索問題
這個問題對于一個數據量少、用戶少的的小型站點 可能幾局簡單的SQL就搞定了,但是對于數據量大,用戶群同樣大的大型站點來說,情況就復雜了。要不Google也不會吃香了的,他的技術含量就體現在搜索上了。全文檢索,搜索結果的緩存以及命中率,都是很有技術含量的問題,要提供給用戶更好的服務,就必須有更好的算法,Google的成功就證明了這一點。所以,您要提供一定數量級數據的搜索服務,就一定會面對全文檢索這個問題。

10、數據共享的渠道以及OpenAPI趨勢 OpenAPI已經成為一個不可避免的趨勢了,國外的facebook、google、myspace、yahoo等,國內的人人、海內、開心,都在考慮這個問題,它可以更有效的留住用戶 ,并且激用戶的參與度,給用戶提供更多興趣化的新工具,以及讓更多的外圍開發團隊和開發者幫助您的站點提供最有效的開發,五分鐘就是一個類似的典范。而這就一個有效的數據共享平臺,數據開放平臺就成為必不可少的途徑了, 并且在開放接口的情況下還要保證數據的安全性和性能,這又是一個富有挑戰性的問題了。

發表評論

電子郵件地址不會被公開。