隨着中國大型IT企業信息化速度的加快，大部分應用的數據量和訪問量都急劇增長html
，大型企業網站正面臨性能和高數據訪問量的壓力，並且對存儲、安全以及信息檢索等web
等方面都提出了更高的要求……算法
本文中，我想經過幾個國外大型IT企業及網站的成功案例，從Web技術人員角度探討數據庫
如何積極地應對國內大型網站即將面臨的擴展（主要是技術方面，而較少涉及管理及營編程
銷等方面）矛盾。緩存
1、 國外大型IT網站的成功之道安全
(一) MySpace服務器
今天，MySpace已經成爲全球衆口皆碑的社區網站之王。儘管一流和營銷和管理經驗網絡
天然是每一個IT企業取得成功的首要因素，可是本節中咱們卻拋棄這一點，而主要着眼於架構
探討在數次面臨系統擴張的緊急關頭MySpace是如何從技術方面採起應對策略的。
第一代架構—添置更多的Web服務器
MySpace最初的系統很小，只有兩臺Web服務器（分擔處理用戶請求的工做量）和一
個數據庫服務器（全部數據都存儲在這一個地方）。那時使用的是Dell雙CPU、4G內存的
系統。在早期階段，MySpace基本是經過添置更多Web服務器來對付用戶暴增問題的。但
到在2004年早期，在MySpace用戶數增加到五十萬後，其數據庫服務器已經開始疲於奔命
了。
第二代架構—增長數據庫服務器
與增長Web服務器不一樣，增長數據庫並沒那麼簡單。若是一個站點由多個數據庫支持
，設計者必須考慮的是，如何在保證數據一致性的前提下讓多個數據庫分擔壓力。
MySpace運行在三個SQL Server數據庫服務器上—一個爲主，全部的新數據都向它提
交，而後由它複製到其它兩個；另兩個數據庫服務器全力向用戶供給數據，用以在博客
和我的資料欄顯示。這種方式在一段時間內效果很好——只要增長數據庫服務器，加大
硬盤，就能夠應對用戶數和訪問量的增長。
這一次的數據庫架構按照垂直分割模式設計，不一樣的數據庫服務於站點的不一樣功能
，如登陸、用戶資料和博客。垂直分割策略利於多個數據庫分擔訪問壓力，當用戶要求
增長新功能時，MySpace只須要投入新的數據庫加以支持。在帳戶到達二百萬後，MySpa
ce還從存儲設備與數據庫服務器直接交互的方式切換到SAN（存儲區域網絡）—用高帶寬
、專門設計的網絡將大量磁盤存儲設備鏈接在一塊兒，而數據庫鏈接到SAN。這項措施極大
提高了系統性能、正常運行時間和可靠性。然而，當用戶繼續增長到三百萬後，垂直分
割策略也變得難以維持下去。
第三代架構—轉到分佈式計算架構
幾經折騰，最終，MySpace將目光移到分佈式計算架構——它在物理上分佈的衆多服
務器，總體必須邏輯上等同於單臺機器。拿數據庫來講，就不能再像過去那樣將應用拆
分，再以不一樣數據庫分別支持，而必須將整個站點看做一個應用。如今，數據庫模型裏
只有一個用戶表，支持博客、我的資料和其餘核心功能的數據都存儲在相同數據庫。
既然全部的核心數據邏輯上都組織到一個數據庫，那麼MySpace必須找到新的辦法以
分擔負荷——顯然，運行在普通硬件上的單個數據庫服務器是無能爲力的。此次，再也不
按站點功能和應用分割數據庫，MySpace開始將它的用戶按每百萬一組分割，而後將各組
的所有數據分別存入獨立的SQL Server實例。目前，MySpace的每臺數據庫服務器實際運
行兩個SQL Server實例，也就是說每臺服務器服務大約二百萬用戶。據MySpace的技術人
員說，之後還能夠按照這種模式以更小粒度劃分架構，從而優化負荷分擔。
第四代架構—求助於微軟方案
2005年早期，帳戶達到九百萬，MySpace開始用微軟的C#編寫ASP.NET程序。在收到
必定成效後，MySpace開始大規模遷移到ASP.NET。
帳戶達到一千萬時，MySpace再次遭遇存儲瓶頸問題。SAN的引入解決了早期一些性
能問題，但站點目前的要求已經開始週期性超越SAN的I/O容量——即它從磁盤存儲系統
讀寫數據的極限速度。
第五代架構—增長數據緩存層並轉到支持64位處理器的SQL Server 2005
2005年春天，MySpace帳戶達到一千七百萬，MySpace又啓用了新的策略以減輕存儲
系統壓力，即增長數據緩存層——位於Web服務器和數據庫服務器之間，其惟一職能是在
內存中創建被頻繁請求數據對象的副本，如此一來，不訪問數據庫也能夠向Web應用供給
數據。
2005年中期，服務帳戶數達到兩千六百萬時，MySpace由於咱們對內存的渴求而切換
到了還處於beta測試的支持64位處理器的SQL Server 2005。升級到SQL Server 2005和
64位Windows Server 2003後，MySpace每臺服務器配備了32G內存，後於2006年再次將配
置標準提高到64G。
事實上，MySpace的Web服務器和數據庫仍然常常發生超負荷，其用戶頻繁遭遇「意
外錯誤」和「站點離線維護」等告示，他們不得不在論壇抱怨不停……
MySpace正是在這樣不斷重構站點軟件、數據庫和存儲系統中，才一步步走到今天。
事實上，MySpace已經成功解決了不少系統擴展性問題，其中存在至關的經驗值得咱們借
鑑。MySpace系統架構到目前爲止保持了相對穩定，但其技術人員仍然在爲SQL Server支
持的同時鏈接數等方面繼續攻堅，儘量把事情作到最好。
(二) Amazon
亞馬遜書店無疑是電子商務發展的里程碑。2000年到如今，世界網絡業腥風血雨。
Amazon曾經成爲網絡泡沫的頭號表明。現在，當這個「最大的泡沫」用幾經易改的數字
把本身變成了堅實的IT巨人。
歷覽Amazon發展過程，其成功經驗在於，它創造性地進行了電子商務中每一環節的探索
，包括系統平臺的建設，程序編寫、網站設立、配送系統等等方面。用Amazon當家人貝
索斯的話說就是，「在現實世界的商店最有力的武器就是地段，地段，地段，而對於我
們來講最重要的三件事就是技術，技術，技術。」
(三) eBay
eBay是世界聞名的拍賣網站，eBay公司通訊部主管凱文?帕斯格拉夫認爲，「eBay成
功的最重要緣由在於公司管理和服務。」
其成功的奧祕能夠列舉爲如下幾點：
①敢爲天下先—在網絡尚不普及的時代，eBay率先進入網絡拍賣領域；
②依託虛擬商場所產生的特有的「零庫存」是eBay公司取得成功的另外一個重要緣由。該
公司的核心業務沒有任何庫存風險，全部的商品都是由客戶提供，它只須要負責提供虛
擬的拍賣平臺—網絡和軟件。因此，eBay公司的財務報表上不會出現「庫存費用」和「
保管費用」等。
③自eBay公司成立開始，它就一直遵循兩條「黃金原則」：建設虛擬社區，給網民以家
的感受；保證網站穩定安全地運行。
2、 國內大型網站開發時的幾點建議
從本節開始，咱們將結合國內外大型IT網站在技術擴展方面的沉痛教訓和成功經驗
，探討在現在剛剛開始的Web 2.0時代如何應對國內網站即將面臨的數據訪問量增長（甚
至是急劇膨脹）的問題，並提出一些供參考的策略和建議。
(四) 搭建科學的系統架構
構建大型的商業網站絕對不可能像構建普通的小型網站同樣一蹴而就，須要從嚴格
的軟件工程管理的角度進行認真規劃，有步驟有邏輯地進行開發。對於大型網站來講，
所採用的技術涉及面極其普遍，從硬件到軟件、編程語言、數據庫、Web服務器、防火牆
等各個領域都有了很高的要求，已經不是原來簡單的html靜態網站所能比擬的。以著名
的Yahoo!爲例，他們的每個大型網站工程都須要大量相應專業人員的參與。
(五) 頁面靜態化
可不要小看純靜態化的HTML頁面！其實在不少狀況下，HTML每每意味着「效率最高
、消耗最小」，因此咱們儘量使咱們的網站上的頁面採用靜態頁面來實現。可是，對
於大量內容而且頻繁更新的網站，咱們沒法所有手動實現，所以能夠開發相應的自動化
更新工具，例如咱們常見的信息發佈系統CMS。像咱們常常訪問的各個門戶站點的新聞頻
道，甚至他們的其餘頻道，都是經過信息發佈系統來管理和實現的。信息發佈系統能夠
實現最簡單的信息錄入自動生成靜態頁面，還能具有頻道管理、權限管理、自動抓取等
功能，對於一個大型網站來講，擁有一套高效、可管理的CMS是必不可少的。
(六) 存儲問題
存儲也是一個大問題，一種是小文件的存儲，好比圖片這類；另外一種是大文件的存
儲，好比搜索引擎的索引。
你們知道，對於Web服務器來講，無論是Apache、IIS仍是其餘容器，圖片是最消耗資源
的，因而咱們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他
們都有獨立的圖片服務器，甚至不少臺圖片服務器。這樣的架構能夠下降提供頁面訪問
請求的服務器系統壓力，而且能夠保證系統不會由於圖片問題而崩潰，在應用服務器和
圖片服務器上，能夠進行不一樣的配置優化以保證更高的系統消耗和執行效率。
(七) 數據庫技術—集羣和庫表散列
對於大型網站而言，使用大型的數據庫服務器是必須的事情。可是，在面對大量訪
問的時候，數據庫的瓶頸仍然會顯現出來，這時一臺數據庫將很快沒法知足應用，因而
咱們須要藉助於數據庫集羣或者庫表散列技術。
在數據庫集羣方面，不少數據庫廠商都有本身的解決方案，Oracle、Sybase、SQL
Server等都有很好的方案，經常使用的MySQL提供的Master/Slave也是相似的方案。所以，你
使用了什麼樣的數據庫，就參考相應的解決方案來實施便可。
上面提到的數據庫集羣因爲在架構、成本、擴張性方面都會受到所採用數據庫類型
的限制，因而咱們須要從應用程序的角度來考慮改善系統架構，其中，庫表散列是經常使用
而且最有效的解決方案。咱們在應用程序中安裝業務和應用或者功能模塊將數據庫進行
分離，不一樣的模塊對應不一樣的數據庫或者表，再按照必定的策略對某個頁面或者功能進
行更小的數據庫散列，好比用戶表，按照用戶ID進行表散列，這樣就可以低成本的提高
系統的性能而且有很好的擴展性。在這一方面一個現成的例子就是搜狐。它的論壇就是
採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，而後對帖子、
用戶按照板塊和ID進行散列數據庫和表，最終能夠在配置文件中進行簡單的配置便能讓
系統隨時增長一臺低成本的數據庫進來補充系統性能。
(八) 緩存策略
這絕對不單指低級的緩存技術相關的編程，應從整個架構角度着眼，深刻研究Web服
務器、數據庫服務器的各層級的緩衝策略，最後纔是低級的緩衝技術的編程。不一樣的We
b服務器、數據庫服務器及Web編程語言都有本身不一樣的緩衝策略。例如數據庫存儲方面
，SQL Serve 2005中的主動式緩存機制，Oracle數據的cache group技術，Hibernate的
緩存包括Session的緩存和SessionFactory的緩存；Web服務器方面，Apache提供了本身
的緩存模塊，也可使用外加的Squid模塊進行緩存，這兩種方式都可以有效的提升Apa
che的訪問響應能力，IIS緩衝器技術；至於web開發語言，所用緩存技術更存在很大不一樣
，例如ASP.NET 2.0中提出了兩種緩存應用程序數據和緩存服務頁輸出的策略，這兩種緩
存技術相互獨立但不相互排斥，PHP有Pear的Cache模塊，等等。
(九) 鏡像
鏡像是大型網站常採用的提升性能和數據安全性的方式，鏡像的技術能夠解決不一樣
網絡接入商和地域帶來的用戶訪問速度差別。在鏡像的細節技術方面，這裏不闡述太深
，有不少專業的現成的解決架構和產品可選。也有廉價的經過軟件實現的思路，好比Li
nux上的rsync等工具。
(十) 負載均衡
負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。
負載均衡技術發展了多年，有不少專業的服務提供商和產品能夠選擇，基於LAMP解決方
案的Lighttped+Squid是至關不錯的解決負載均衡和加速系統的有效方式。
(十一) 硬件四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將
整個區間段的業務流分配到合適的應用服務器進行處理。第四層交換功能就象是虛IP，
指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其
他協議。這些業務在物理服務器基礎上，須要複雜的載量平衡算法。在IP世界，業務類
型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址
、TCP和UDP端口共同決定。
在硬件四層交換產品領域，有一些知名的產品能夠選擇，好比Alteon、F5等，這些
產品很昂貴，可是物有所值，可以提供很是優秀的性能和很靈活的管理能力。Yahoo中國
當初接近2000臺服務器使用了三四臺Alteon就搞定了。
(十二) 軟件四層交換
你們知道了硬件四層交換機的原理後，基於OSI模型來實現的軟件四層交換也就應運
而生，這樣的解決方案實現的原理一致，不過性能稍差。可是知足必定量的壓力仍是遊
刃有餘的。
一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣
，這種思路在不少大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很
強的擴張性，隨時往架構裏面增減節點都很是容易。
(十三) 軟件投資問題
據報導，目前國內除了一些上市企業和特別大知名大公司之外，不多有企業在成本
中考慮正版軟件的購置費用。這種思惟極有可能給中國互聯網帶來噩夢。若是一些公司
真正面臨軟件資金方面的困難，徹底能夠考慮使用開源世界的LAMP解決方案（Linux＋A
pache＋MySQL＋Perl、PHP或者Python Web編程語言）；不然，隨着我國加入WTO範圍的
不斷擴大，盜版打擊必然愈來愈嚴。所以，「苟且偷生」必將自作自受。
另外，隨着網絡帶寬日漸提高，WEB 2.0技術必將影響到網絡世界的幾乎每個角落
。所以，如何積聚技術人員進行技術攻關並進一步增強安全防範也成爲一個日益嚴峻的
問題，宜儘早歸入到公司的議事日程。
4、 總結
中國電子商務真正理性發展的一個標誌，是大量的傳統企業實實在在地開始用互聯
網來處理商務、作生意，而如今這樣的浪潮已經開始。北京發行集團，聯合SINA、6688
.com等單位共同推出的網上虛擬書店—新新書店就是這樣的一個標誌。
隨着網絡帶寬日漸提高，隨着網絡理念和WEB 2.0技術的斷深刻人心，各類B2B、B2C、C
2C等電子商務模式極可能以立體交叉方式整合到各類大型商務網站中來。所以，做爲公
司的技術人員，做爲臨危救駕的「白衣騎士」，如何應對海量存儲、海量訪問問題，海
量信息檢索的問題，日益嚴峻的安全問題，等等，已經刻不容緩。