大數據量、高並發量網站解決方案
隨著中國大型IT企業信息化速度的加快，大部分應用的數據量和訪問量都急劇增加
，大型企業網站正面臨性能和高數據訪問量的壓力，而且對存儲、安全以及信息檢索等
等方面都提出了更高的要求……
本文中，我想通過幾個國外大型IT企業及網站的成功案例，從Web技術人員角度探討
如何積極地應對國內大型網站即將面臨的擴展（主要是技術方面，而較少涉及管理及營
銷等方面）矛盾。
一、 國外大型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公司成立開始，它就一直遵循兩條“黃金原則”：建設虛擬社區，給網民以家
的感覺；保證網站穩定安全地運行。
二、 國內大型網站開發時的幾點建議
從本節開始，我們將結合國內外大型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技術必將影響到網絡世界的幾乎每一個角落
。因此，如何積聚技術人員進行技術攻關並進一步加強安全防範也成為一個日益嚴峻的
問題，宜盡早納入到公司的議事日程。
四、 總結
中國電子商務真正理性發展的一個標誌，是大量的傳統企業實實在在地開始用互聯
網來處理商務、做生意，而現在這樣的浪潮已經開始。北京發行集團，聯合SINA、6688
.com等單位共同推出的網上虛擬書店—新新書店就是這樣的一個標誌。
隨著網絡帶寬日漸提升，隨著網絡理念和WEB 2.0技術的斷深入人心，各種B2B、B2C、C
2C等電子商務模式很可能以立體交叉方式整合到各種大型商務網站中來。因此，作為公
司的技術人員，作為臨危救駕的“白衣騎士”，如何應對海量存儲、海量訪問問題，海
量信息檢索的問題，日益嚴峻的安全問題，等等，已經刻不容緩。
大數據量、高並發量網站解決方案