一、 web2.0網(wǎng)站常用可用性功能模塊分析 二、 Flickr的幕后故事 三、 YouTube 的架構擴展 四、 mixi.jp：使用開(kāi)源軟件搭建的可擴展SNS網(wǎng)站 五、 Technorati的后臺數據庫架構 六、 通過(guò)了解MySpace的六次重構經(jīng)歷,來(lái)認識分布式系統到底該如何創(chuàng )建 七、 從LiveJournal后臺發(fā)展看大規模網(wǎng)站性能優(yōu)化方法 八、 說(shuō)說(shuō)大型高并發(fā)高負載網(wǎng)站的系統架構 http: 一、 web2.0網(wǎng)站常用可用性功能模塊分析Web 2.0網(wǎng)站是指將傳統的網(wǎng)站構架（平臺、內容源、用戶(hù)、傳播方式等）轉化到以用戶(hù)為核心的網(wǎng)站構架上來(lái)，包括一系列體現web2.0概念的元素、定位和創(chuàng )意。web2.0網(wǎng)站在構架上須體現兩大宗旨，即強大的后臺系統和簡(jiǎn)單的前臺頁(yè)面，也即提供良好的用戶(hù)體驗，體現以人為本，技術(shù)服務(wù)人類(lèi)的宗旨。 web2.0網(wǎng)站常用功能塊通常包括以下幾大項： 1. Tag標簽功能塊 Tag(中文叫做"標簽") 是一種新的組織和管理在線(xiàn)信息的方式。它不同于傳統的、針對文件本身的關(guān)鍵字檢索，而是一種模糊化、智能化的分類(lèi)。 網(wǎng)頁(yè)使用Tag標簽的好處： 為頁(yè)面設置一個(gè)或者多個(gè)Tag標簽可以引導讀者閱讀更多相關(guān)文章，為別人帶去流量同理也為自己帶來(lái)流量。 可以幫助讀者及時(shí)了解一些未知的概念和知識點(diǎn)，提高用戶(hù)體驗。 Tag是人的意志和趨向的體現，Tag可以幫助你找到興趣相投的人。 基于以上優(yōu)勢，Tag標簽代替了傳統的分類(lèi)法，成為web2.0網(wǎng)站使用率最高的功能塊（與其說(shuō)是功能塊倒不如說(shuō)是一種內容導航和內容組織形式）。 一句話(huà)：Tag標簽是一種更靈活的分類(lèi)方法，功能在于引導，特點(diǎn)是無(wú)處不在，體現智能性、模糊性和趨向性。 2. RSS訂閱功能塊 RSS是在線(xiàn)共享內容的一種簡(jiǎn)易方式（也叫聚合內容，Really Simple Syndication）。通常在時(shí)效性比較強的內容上使用RSS訂閱能更快速獲取信息，網(wǎng)站提供RSS輸出，有利于讓用戶(hù)獲取網(wǎng)站內容的最新更新。網(wǎng)絡(luò )用戶(hù)可以在客戶(hù)端借助于支持RSS的聚合工具軟件（例如SharpReader,NewzCrawler、FeedDemon），在不打開(kāi)網(wǎng)站內容頁(yè)面的情況下閱讀支持RSS輸出的網(wǎng)站內容。 RSS訂閱的方式： 訂閱到客戶(hù)端軟件如周伯通、遨游瀏覽器RSS閱讀、Foxmail RSS閱讀等，此方式使用者較多 訂閱到在線(xiàn)閱讀（聚合類(lèi)）門(mén)戶(hù)網(wǎng)站如Google Reader，Yahoo Reader，抓蝦、Gougou等，省去了安裝RSS閱讀器的麻煩 訂閱到在線(xiàn)單用戶(hù)聚合器如Lilina等，比較靈活 RSS訂閱功能的最大好處是定向投遞，也就是說(shuō)RSS機制更能體現用戶(hù)的意愿和個(gè)性，獲取信息的方式也最直接和簡(jiǎn)單，這是RSS訂閱功能備受青睞的一大主要原因。 3. 推薦和收藏功能塊 說(shuō)到推薦功能，不僅web2.0網(wǎng)站在大量使用，傳統的以cms平臺為代表的內容模式的網(wǎng)站也在大量使用，推薦功能主要是指向一些網(wǎng)摘或者聚合類(lèi)門(mén)戶(hù)網(wǎng)站推薦自己所瀏覽到的網(wǎng)頁(yè)。當然，一種變相的推薦就是閱讀者的自我收藏行為，在共享的模式下也能起到推薦的作用。 比較有名的推薦目標有以del.icio.us為代表的網(wǎng)摘類(lèi)網(wǎng)站包括國內比較有名氣的365key、和訊網(wǎng)摘、新浪vivi、天極網(wǎng)摘等。這里值得一提的是前段時(shí)間曾涌現了大批網(wǎng)摘類(lèi)網(wǎng)站，但他們堅持活下來(lái)的好像沒(méi)有幾個(gè)了，推薦使用前面提到的這幾個(gè)網(wǎng)摘門(mén)戶(hù)，人氣基本上是使最旺的。 4. 評論和留言功能塊 web2.0強調參與性，強調發(fā)揮用戶(hù)的主導作用，這里的參與性除了所謂的訂閱、推薦功能外更多地體現在用戶(hù)對內容的評價(jià)和態(tài)度，這就要靠評論功能塊來(lái)完成。一個(gè)典型的web2.0網(wǎng)站或者說(shuō)一個(gè)能體現人氣的web2.0網(wǎng)站都會(huì )花大量篇幅來(lái)體現用戶(hù)的觀(guān)點(diǎn)和視覺(jué)。這里尤其要提到web2.0中的帶頭老大web blog，評論功能已經(jīng)成為博客主人與瀏覽者交流的主要陣地，是體現網(wǎng)站人氣的最直觀(guān)因素。 評論功能塊應用在博客系統中實(shí)際上已經(jīng)和博客內容相分離，而更好的應用恰恰是一些以點(diǎn)評為主的web2.0網(wǎng)站比如豆瓣、點(diǎn)評網(wǎng)等，這里的評論功能塊直接制造了內容也極大地體現了網(wǎng)站的人氣，所以說(shuō)評論功能塊是web2.0網(wǎng)站最有力的武器。 5. 站內搜索功能塊 搜索是信息來(lái)源最直接的方式之一，無(wú)論你的網(wǎng)站是否打上web2.0的烙印，搜索對于一個(gè)體系龐大、內容豐富的大型網(wǎng)站都是非常必要的。Tag標簽在某種程度上起到搜索的作用，它能夠有效聚合以此Tag為關(guān)鍵詞的內容，但這種情況的前提是此Tag標簽對瀏覽者是可見(jiàn)的，也就是說(shuō)當Tag標簽擺在瀏覽者的眼前時(shí)才成立，而對于那些瀏覽者想要的信息卻沒(méi)有Tag標簽來(lái)引導時(shí)搜索就是達到此目的的最好方法。 對于web2.0網(wǎng)站，站內搜索以標題或者Tag為搜索域都能起到好的效果，但本人不建議使用內容搜索域，因為這不符合搜索的高效性原則。同時(shí)，具有突出關(guān)鍵詞的內容往往都可以用Tag標簽來(lái)引導，因此使用內容域來(lái)搜索實(shí)際上是一種浪費服務(wù)器資源的行為，而且搜索結果的準確性將大打折扣。 6. 群組功能塊 我為什么要把群組作為web2.0網(wǎng)站的功能塊來(lái)分析呢，因為群組是web2.0網(wǎng)站的一大特點(diǎn)，也是web2.0所要體現的服務(wù)宗旨所在。一個(gè)web2.0網(wǎng)站，博客也好、播客也好、點(diǎn)評也好，抑或是網(wǎng)摘、聚合門(mén)戶(hù)，他們都強調人的參與性。物以類(lèi)聚、人以群分，每個(gè)參與者都有自己的興趣趨向，web2.0網(wǎng)站的另一主要功能就是幫助這些人找到同樣興趣的人并形成一個(gè)活躍的群體，這是web2.0網(wǎng)站的根本。 總結：web2.0網(wǎng)站倡導的是集體創(chuàng )作、共享資源，靠的是人氣，體現的是參與性，一個(gè)沒(méi)有參與性的web2.0網(wǎng)站都不足以成為web2.0。以上提到的這幾個(gè)功能塊就是以吸引用戶(hù)參與和引導用戶(hù)參與為目的的，真正的web2.0不是什么深奧的東西，只有一點(diǎn)，那就是如何讓瀏覽者沸騰起來(lái)。 二、 Flickr的幕后故事我們都看到 Flickr 的成功，而又有多少"精英"們了解過(guò) Flickr 背后的過(guò)程是多么充滿(mǎn)艱險。 Flickr 是全 CGI 的動(dòng)態(tài)構架，并以一種 .gne 的腳本作為 CGI 程序語(yǔ)言。不管網(wǎng)站制作菜鳥(niǎo)還是高手都會(huì )疑惑：gne 是哪種程序語(yǔ)言？答案：gne 不是一種語(yǔ)言，Flickr 是以極為經(jīng)典的 PHP + MySQL 方式實(shí)現的，在被 Yahoo 收購服務(wù)器搬入美國之前，使用了 21 臺（69.90.111.101-121） Apache/PHP 做 Web、23 臺圖片服務(wù)器、另有 MySQL 服務(wù)器組成的數據庫集群的服務(wù)器數量未知?，F在估計使用的是 Yahoo 的負載均衡系統，對外只有一個(gè) Web 的 IP 和圖片服務(wù)器的 IP 了。 那為何 .php 的文件要改成 .gne 呢？以往有大型網(wǎng)站為向后兼容性考慮，隱藏以程序語(yǔ)言命名的腳本文件擴展名，比如 Baidu 隱藏了 .php（Google 的 http 服務(wù)器是自己寫(xiě)的，整合了腳本程序，個(gè)別頁(yè)面是 .py--Python）；還有一些網(wǎng)站是改成自己網(wǎng)站名相關(guān)的擴展名，如 MSN 的群組則是 .msnw，榕樹(shù)下是 .rs。 那 Flickr 的 gne 是什么意思？我在維基百科的 Flickr 條目上找到了答案(中文 Flickr 條目上沒(méi)有寫(xiě)明) 。原來(lái) GNE 是 Game NeverEnding 的縮寫(xiě)，Flickr 的開(kāi)發(fā)者 Ludicorp 在 2002-2004 年一直在開(kāi)發(fā)這套以 Game NerverEnding 為名稱(chēng)的大型多人在線(xiàn)角色扮演游戲--一套基于瀏覽器的 Web 游戲系統，個(gè)人以為應該就是當年九城的虛擬城市。但是開(kāi)發(fā)近 3 年后該計劃不得不破產(chǎn)，最終只發(fā)布了一個(gè) Beta 版，而 Ludicorp 將這套系統稍加移植，就有了 Flickr。呵呵，原來(lái) gne 是一個(gè)項目的名稱(chēng)。關(guān)于 GNE 的一些連接：http: 早期的 Flickr 想做成在類(lèi)似聊天室的地方讓網(wǎng)友分享、交流自己的照片，注重社區形式和保護照片不被外部引用（見(jiàn)徐子涵2004年的文章），可能是看到了 Hello 的模式吧。但是聰明的 Flickr 團隊不久就改變了策略，淡化了傳統的社區形式--如聊天室、而加強了現在使其功成名就的 Tag 組織形式，一種更自由更隨興更輕松好玩的大社區形式，或者叫它廣義社區吧，我隨便叫的，可能太學(xué)究，看著(zhù)別太在意就是了。另外，將原來(lái)照片只能在 Flash 內瀏覽的限制區除了，并大力推薦用戶(hù)將照片引用到自己的 Blog，這無(wú)疑對于挑戰傳統相冊系統有決定性意義。減少 Flash 后的網(wǎng)頁(yè)更多地引進(jìn)了新興的 Ajax 技術(shù)，使界面操作變得非常 Cool。 這就是 Flickr 的歷史，清晰地看到了他們對于優(yōu)秀產(chǎn)品的執著(zhù)。有了技術(shù)和經(jīng)驗積累，加上不斷堅持，總有一天時(shí)來(lái)運轉，你的產(chǎn)品會(huì )成為新潮流的里程碑。 還有一句話(huà)要告訴 Yupoo 等：把 Flickr 想成一個(gè)有 Tag 功能的在線(xiàn)相冊就已經(jīng)錯遠了；復制粘貼者們想當然將 Flickr 去其糟粕取其精華，結果無(wú)關(guān)緊要的拿來(lái)了，將令人激動(dòng)的優(yōu)點(diǎn)都去掉了，結果剩下什么？ 三、 YouTube 的架構擴展在西雅圖擴展性的技術(shù)研討會(huì )上，YouTube 的 Cuong Do 做了關(guān)于 YouTube Scalability 的報告。視頻內容在 Google Video 上有(地址)，可惜國內用戶(hù)看不到。 Kyle Cordes 對這個(gè)視頻中的內容做了介紹。里面有不少技術(shù)性的內容。值得分享一下。(Kyle Cordes 的介紹是本文的主要來(lái)源) 簡(jiǎn)單的說(shuō) YouTube 的數據流量, "一天的YouTube流量相當于發(fā)送750億封電子郵件.", 2006 年中就有消息說(shuō)每日 PV 超過(guò) 1 億,現在? 更夸張了,"每天有10億次下載以及6,5000次上傳", 真假姑且不論, 的確是超乎尋常的海量. 國內的互聯(lián)網(wǎng)應用,但從數據量來(lái)看,怕是只有 51.com 有這個(gè)規模. 但技術(shù)上和 YouTube 就沒(méi)法子比了. 1. Web 服務(wù)器http: YouTube 出于開(kāi)發(fā)速度的考慮，大部分代碼都是 Python 開(kāi)發(fā)的。Web 服務(wù)器有部分是 Apache， 用 FastCGI 模式。對于視頻內容則用 Lighttpd 。據我所知，MySpace 也有部分服務(wù)器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(國內用 Lighttpd 站點(diǎn)不多，豆瓣用的比較舒服。by Fenng) 2. 視頻 視頻的縮略圖(Thumbnails)給服務(wù)器帶來(lái)了很大的挑戰。每個(gè)視頻平均有4個(gè)縮略圖，而每個(gè) Web 頁(yè)面上更是有多個(gè)，每秒鐘因為這個(gè)帶來(lái)的磁盤(pán) IO 請求太大。YouTube 技術(shù)人員啟用了單獨的服務(wù)器群組來(lái)承擔這個(gè)壓力，并且針對 Cache 和 OS 做了部分優(yōu)化。另一方面，縮略圖請求的壓力導致 Lighttpd 性能下降。通過(guò) Hack Lighttpd 增加更多的 worker 線(xiàn)程很大程度解決了問(wèn)題。而最新的解決方案是起用了 Google 的 BigTable， 這下子從性能、容錯、緩存上都有更好表現?？慈思疫@收購的，好鋼用在了刀刃上。 出于冗余的考慮，每個(gè)視頻文件放在一組迷你 Cluster 上，所謂 "迷你 Cluster" 就是一組具有相同內容的服務(wù)器。最火的視頻放在 CDN 上，這樣自己的服務(wù)器只需要承擔一些"漏網(wǎng)"的隨即訪(fǎng)問(wèn)即可。YouTube 使用簡(jiǎn)單、廉價(jià)、通用的硬件，這一點(diǎn)和 Google 風(fēng)格倒是一致。至于維護手段，也都是常見(jiàn)的工具，如 rsync, SSH 等，只不過(guò)人家更手熟罷了。 3. 數據庫 YouTube 用 MySQL 存儲元數據--用戶(hù)信息、視頻信息什么的。數據庫服務(wù)器曾經(jīng)一度遇到 SWAP 顛簸的問(wèn)題，解決辦法是刪掉了 SWAP 分區! 管用。 最初的 DB 只有 10 塊硬盤(pán)，RAID 10 ，后來(lái)追加了一組 RAID 1。夠省的。這一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,參見(jiàn)這里). 在擴展性方面，路線(xiàn)也是和其他站點(diǎn)類(lèi)似，復制，分散 IO。最終的解決之道是"分區",這個(gè)不是數據庫層面的表分區，而是業(yè)務(wù)層面的分區(在用戶(hù)名字或者 ID 上做文章,應用程序控制查找機制) YouTube 也用 Memcached. 四、 mixi.jp：使用開(kāi)源軟件搭建的可擴展SNS網(wǎng)站Mixi目前是日本排名第三的網(wǎng)站，全球排名42，主要提供SNS服務(wù)：日記，群組，站內消息，評論，相冊等等，是日本最大的SNS網(wǎng)站。Mixi從2003年12月份開(kāi)始開(kāi)發(fā)，由現在它的CTO - Batara Kesuma一個(gè)人焊，焊了四個(gè)月，在2004年2月份開(kāi)始上線(xiàn)運行。兩個(gè)月后就注冊了1w用戶(hù)，日訪(fǎng)問(wèn)量60wPV。在隨后的一年里，用戶(hù)增長(cháng)到了21w，第二年，增長(cháng)到了200w。到今年四月份已經(jīng)增長(cháng)到370w注冊用戶(hù)，并且還在以每天1.5w人的注冊量增長(cháng)。這些用戶(hù)中70%是活躍用戶(hù)（活躍用戶(hù)：三天內至少登錄一次的用戶(hù)），平均每個(gè)用戶(hù)每周在線(xiàn)時(shí)間為將近3個(gè)半小時(shí)。 下面我們來(lái)看它的技術(shù)架構。Mixi采用開(kāi)源軟件作為架構的基礎：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前為止已經(jīng)有100多臺MySQL數據庫服務(wù)器，并且在以每月10多臺的速度增長(cháng)。Mixi的數據庫連接方式采用的是每次查詢(xún)都進(jìn)行連接，而不是持久連接。數據庫大多數是以InnoDB方式運行。Mixi解決擴展問(wèn)題主要依賴(lài)于對數據庫的切分。 首先進(jìn)行垂直切分，按照表的內容將不同的表劃分到不同的數據庫中。然后是水平切分，根據用戶(hù)的ID將不同用戶(hù)的內容再劃分的不同的數據庫中，這是比較通常的做法，也很管用。劃分的關(guān)鍵還是在于應用中的實(shí)現，需要將操作封裝在在數據層，而盡量不影響業(yè)務(wù)層。當然完全不改變邏輯層也不可能，這時(shí)候最能檢驗以前的設計是否到位，如果以前設計的不錯，那創(chuàng )建連接的時(shí)候傳個(gè)表名，用戶(hù)ID進(jìn)去差不多就解決問(wèn)題了，而以前如果sql代碼到處飛，或者數據層封裝的不太好的話(huà)那就累了。 這樣做了以后并不能從根本上解決問(wèn)題，尤其是對于像mixi這種SNS網(wǎng)站，頁(yè)面上往往需要引用大量的用戶(hù)信息，好友信息，圖片，文章信息，跨表，跨庫操作相當多。這個(gè)時(shí)候就需要發(fā)揮memcached的作用了，用大內存把這些不變的數據全都緩存起來(lái)，而當修改時(shí)就通知cache過(guò)期，這樣應用層基本上就可以解決大部分問(wèn)題了，只會(huì )有很小一部分請求穿透應用層，用到數據庫。Mixi的經(jīng)驗是平均每個(gè)頁(yè)面的加載時(shí)間在0.02秒左右（當然根據頁(yè)面大小情況不盡相似），可以說(shuō)明這種做法是行之有效的。Mixi一共在32臺機器上有緩存服務(wù)器，每個(gè)Cache Server 2G內存，這些Cache Server與App Server裝在一起。因為Cache Server對CPU消耗不大，而有了Cache Server的支援，App Server對內存要求也不是太高，所以可以和平共處，更有效的利用資源。 圖片的處理就顯得相對簡(jiǎn)單的多了。對于mixi而言，圖像主要有兩部分：一部分是經(jīng)常要使用到的，像用戶(hù)頭像，群組的頭像等等，大概有100多GB，它們被Squid和CDN所緩存，命中率相對比較高；另一部分是用戶(hù)上傳的大量照片，它們的個(gè)體訪(fǎng)問(wèn)量相對而言比較小，命中率也比較低，使用Cache不劃算，所以對于這些照片的策略是直接在用戶(hù)上傳的時(shí)候分發(fā)到到圖片存儲服務(wù)器上，在用戶(hù)訪(fǎng)問(wèn)的時(shí)候直接進(jìn)行訪(fǎng)問(wèn)，當然圖片的位置需要在數據庫中進(jìn)行記錄，不然找不到放在哪臺服務(wù)器上就郁悶了。 五、 Technorati的后臺數據庫架構Technorati (現在被阻尼了, 可能你訪(fǎng)問(wèn)不了)的 Dorion Carroll在 2006 MySQL 用戶(hù)會(huì )議上介紹了一些關(guān)于 Technorati 后臺數據庫架構的情況. 基本情況 目前處理著(zhù)大約 10Tb 核心數據, 分布在大約 20 臺機器上.通過(guò)復制, 多增加了 100Tb 數據, 分布在 200 臺機器上. 每天增長(cháng)的數據 1TB. 通過(guò) SOA 的運用, 物理與邏輯的訪(fǎng)問(wèn)相隔離, 似乎消除了數據庫的瓶頸. 值得一提的是, 該擴展過(guò)程始終是利用普通的硬件與開(kāi)源軟件來(lái)完成的. 畢竟 , Web 2.0 站點(diǎn)都不是燒錢(qián)的主. 從數據量來(lái)看，這絕對是一個(gè)相對比較大的 Web 2.0 應用. Tag 是 Technorati 最為重要的數據元素. 爆炸性的 Tag 增長(cháng)給 Technorati 帶來(lái)了不小的挑戰. 2005 年 1 月的時(shí)候, 只有兩臺數據庫服務(wù)器, 一主一從. 到了 06 年一月份, 已經(jīng)是一主一從, 6 臺 MyISAM 從數據庫用來(lái)對付查詢(xún), 3 臺 MyISAM 用作異步計算. 一些核心的處理方法: 1) 根據實(shí)體(tags/posttags))進(jìn)行分區 衡量數據訪(fǎng)問(wèn)方法，讀和寫(xiě)的平衡.然后通過(guò)不同的維度進(jìn)行分區．( Technorati 數據更新不會(huì )很多, 否則會(huì )成為數據庫災難) 2) 合理利用 InnoDB 與 MyISAM InnoDB 用于數據完整性/寫(xiě)性能要求比較高的應用. MyISAM 適合進(jìn)行 OLAP 運算. 物盡其用. 3) MySQL 復制 復制數據到從主數據庫到輔數據庫上,平衡分布查詢(xún)與異步計算, 另外一個(gè)功能是提供冗余． 如圖: 六、 通過(guò)了解MySpace的六次重構經(jīng)歷,來(lái)認識分布式系統到底該如何創(chuàng )建. 在每個(gè)里程碑，站點(diǎn)負擔都會(huì )超過(guò)底層系統部分組件的最大載荷，特別是數據庫和存儲系統。接著(zhù)，功能出現問(wèn)題，用戶(hù)失聲尖叫。最后，技術(shù)團隊必須為此修訂系統策略。 雖然自2005年早期，站點(diǎn)賬戶(hù)數超過(guò)7百萬(wàn)后，系統架構到目前為止保持了相對穩定，但MySpace仍然在為SQL Server支持的同時(shí)連接數等方面繼續攻堅，Benedetto說(shuō)，"我們已經(jīng)盡可能把事情做到最好"。 1. 里程碑一：50萬(wàn)賬戶(hù) 按Benedetto 的說(shuō)法，MySpace最初的系統很小，只有兩臺Web服務(wù)器和一個(gè)數據庫服務(wù)器。那時(shí)使用的是Dell雙CPU、4G內存的系統。 單個(gè)數據庫就意味著(zhù)所有數據都存儲在一個(gè)地方，再由兩臺Web服務(wù)器分擔處理用戶(hù)請求的工作量。但就像MySpace后來(lái)的幾次底層系統修訂時(shí)的情況一樣，三服務(wù)器架構很快不堪重負。此后一個(gè)時(shí)期內，MySpace基本是通過(guò)添置更多Web服務(wù)器來(lái)對付用戶(hù)暴增問(wèn)題的。 但到在2004年早期，MySpace用戶(hù)數增長(cháng)到50萬(wàn)后，數據庫服務(wù)器也已開(kāi)始汗流浹背。 但和Web服務(wù)器不同，增加數據庫可沒(méi)那么簡(jiǎn)單。如果一個(gè)站點(diǎn)由多個(gè)數據庫支持，設計者必須考慮的是，如何在保證數據一致性的前提下，讓多個(gè)數據庫分擔壓力。 在第二代架構中，MySpace運行在3個(gè)SQL Server數據庫服務(wù)器上--一個(gè)為主，所有的新數據都向它提交，然后由它復制到其他兩個(gè)；另兩個(gè)全力向用戶(hù)供給數據，用以在博客和個(gè)人資料欄顯示。這種方式在一段時(shí)間內效果很好--只要增加數據庫服務(wù)器，加大硬盤(pán)，就可以應對用戶(hù)數和訪(fǎng)問(wèn)量的增加。 2. 里程碑二：1-2百萬(wàn)賬戶(hù) MySpace注冊數到達1百萬(wàn)至2百萬(wàn)區間后，數據庫服務(wù)器開(kāi)始受制于I/O容量--即它們存取數據的速度。而當時(shí)才是2004年中，距離上次數據庫系統調整不過(guò)數月。用戶(hù)的提交請求被阻塞，就像千人樂(lè )迷要擠進(jìn)只能容納幾百人的夜總會(huì )，站點(diǎn)開(kāi)始遭遇"主要矛盾"，Benedetto說(shuō)，這意味著(zhù)MySpace永遠都會(huì )輕度落后于用戶(hù)需求。 "有人花5分鐘都無(wú)法完成留言，因此用戶(hù)總是抱怨說(shuō)網(wǎng)站已經(jīng)完蛋了。"他補充道。 這一次的數據庫架構按照垂直分割模式設計，不同的數據庫服務(wù)于站點(diǎn)的不同功能，如登錄、用戶(hù)資料和博客。于是，站點(diǎn)的擴展性問(wèn)題看似又可以告一段落了，可以歇一陣子。 垂直分割策略利于多個(gè)數據庫分擔訪(fǎng)問(wèn)壓力，當用戶(hù)要求增加新功能時(shí)，MySpace將投入新的數據庫予以支持它。賬戶(hù)到達2百萬(wàn)后，MySpace還從存儲設備與數據庫服務(wù)器直接交互的方式切換到SAN（Storage Area Network，存儲區域網(wǎng)絡(luò )）--用高帶寬、專(zhuān)門(mén)設計的網(wǎng)絡(luò )將大量磁盤(pán)存儲設備連接在一起，而數據庫連接到SAN。這項措施極大提升了系統性能、正常運行時(shí)間和可靠性，Benedetto說(shuō)。 3. 里程碑三：3百萬(wàn)賬戶(hù) 當用戶(hù)繼續增加到3百萬(wàn)后，垂直分割策略也開(kāi)始難以為繼。盡管站點(diǎn)的各個(gè)應用被設計得高度獨立，但有些信息必須共享。在這個(gè)架構里，每個(gè)數據庫必須有各自的用戶(hù)表副本--MySpace授權用戶(hù)的電子花名冊。這就意味著(zhù)一個(gè)用戶(hù)注冊時(shí)，該條賬戶(hù)記錄必須在9個(gè)不同數據庫上分別創(chuàng )建。但在個(gè)別情況下，如果其中某臺數據庫服務(wù)器臨時(shí)不可到達，對應事務(wù)就會(huì )失敗，從而造成賬戶(hù)非完全創(chuàng )建，最終導致此用戶(hù)的該項服務(wù)無(wú)效。 另外一個(gè)問(wèn)題是，個(gè)別應用如博客增長(cháng)太快，那么專(zhuān)門(mén)為它服務(wù)的數據庫就有巨大壓力。 2004年中，MySpace面臨Web開(kāi)發(fā)者稱(chēng)之為"向上擴展"對"向外擴展"（譯者注：Scale Up和Scale Out，也稱(chēng)硬件擴展和軟件擴展）的抉擇--要么擴展到更大更強、也更昂貴的服務(wù)器上，要么部署大量相對便宜的服務(wù)器來(lái)分擔數據庫壓力。一般來(lái)說(shuō)，大型站點(diǎn)傾向于向外擴展，因為這將讓它們得以保留通過(guò)增加服務(wù)器以提升系統能力的后路。 但成功地向外擴展架構必須解決復雜的分布式計算問(wèn)題，大型站點(diǎn)如Google、Yahoo和Amazon.com，都必須自行研發(fā)大量相關(guān)技術(shù)。以Google為例，它構建了自己的分布式文件系統。 另外，向外擴展策略還需要大量重寫(xiě)原來(lái)軟件，以保證系統能在分布式服務(wù)器上運行。"搞不好，開(kāi)發(fā)人員的所有工作都將白費"，Benedetto說(shuō)。 因此，MySpace首先將重點(diǎn)放在了向上擴展上，花費了大約1個(gè)半月時(shí)間研究升級到32CPU服務(wù)器以管理更大數據庫的問(wèn)題。Benedetto說(shuō)，"那時(shí)候，這個(gè)方案看似可能解決一切問(wèn)題。"如穩定性，更棒的是對現有軟件幾乎沒(méi)有改動(dòng)要求。 糟糕的是，高端服務(wù)器極其昂貴，是購置同樣處理能力和內存速度的多臺服務(wù)器總和的很多倍。而且，站點(diǎn)架構師預測，從長(cháng)期來(lái)看，即便是巨型數據庫，最后也會(huì )不堪重負，Benedetto說(shuō)，"換句話(huà)講，只要增長(cháng)趨勢存在，我們最后無(wú)論如何都要走上向外擴展的道路。" 因此，MySpace最終將目光移到分布式計算架構--它在物理上分布的眾多服務(wù)器，整體必須邏輯上等同于單臺機器。拿數據庫來(lái)說(shuō)，就不能再像過(guò)去那樣將應用拆分，再以不同數據庫分別支持，而必須將整個(gè)站點(diǎn)看作一個(gè)應用?，F在，數據庫模型里只有一個(gè)用戶(hù)表，支持博客、個(gè)人資料和其他核心功能的數據都存儲在相同數據庫。 既然所有的核心數據邏輯上都組織到一個(gè)數據庫，那么MySpace必須找到新的辦法以分擔負荷--顯然，運行在普通硬件上的單個(gè)數據庫服務(wù)器是無(wú)能為力的。這次，不再按站點(diǎn)功能和應用分割數據庫，MySpace開(kāi)始將它的用戶(hù)按每百萬(wàn)一組分割，然后將各組的全部數據分別存入獨立的SQL Server實(shí)例。目前，MySpace的每臺數據庫服務(wù)器實(shí)際運行兩個(gè)SQL Server實(shí)例，也就是說(shuō)每臺服務(wù)器服務(wù)大約2百萬(wàn)用戶(hù)。Benedetto指出，以后還可以按照這種模式以更小粒度劃分架構，從而優(yōu)化負荷分擔。 當然，還是有一個(gè)特殊數據庫保存了所有賬戶(hù)的名稱(chēng)和密碼。用戶(hù)登錄后，保存了他們其他數據的數據庫再接管服務(wù)。特殊數據庫的用戶(hù)表雖然龐大，但它只負責用戶(hù)登錄，功能單一，所以負荷還是比較容易控制的。 4. 里程碑四：9百萬(wàn)到1千7百萬(wàn)賬戶(hù) 2005年早期，賬戶(hù)達到9百萬(wàn)后，MySpace開(kāi)始用Microsoft的C#編寫(xiě)ASP.NET程序。C#是C語(yǔ)言的最新派生語(yǔ)言，吸收了C++和Java的優(yōu)點(diǎn)，依托于Microsoft .NET框架（Microsoft為軟件組件化和分布式計算而設計的模型架構）。ASP.NET則由編寫(xiě)Web站點(diǎn)腳本的ASP技術(shù)演化而來(lái)，是Microsoft目前主推的Web站點(diǎn)編程環(huán)境。 可以說(shuō)是立竿見(jiàn)影， MySpace馬上就發(fā)現ASP.NET程序運行更有效率，與ColdFusion相比，完成同樣任務(wù)需消耗的處理器能力更小。據技術(shù)總監Whitcomb說(shuō)，新代碼需要150臺服務(wù)器完成的工作，如果用ColdFusion則需要246臺。Benedetto還指出，性能上升的另一個(gè)原因可能是在變換軟件平臺，并用新語(yǔ)言重寫(xiě)代碼的過(guò)程中，程序員復審并優(yōu)化了一些功能流程。 最終，MySpace開(kāi)始大規模遷移到ASP.NET。即便剩余的少部分ColdFusion代碼，也從Cold-Fusion服務(wù)器搬到了ASP.NET，因為他們得到了BlueDragon.NET（喬治亞州阿爾法利塔New Atlanta Communications公司的產(chǎn)品，它能將ColdFusion代碼自動(dòng)重新編譯到Microsoft平臺）的幫助。 賬戶(hù)達到1千萬(wàn)時(shí)，MySpace再次遭遇存儲瓶頸問(wèn)題。SAN的引入解決了早期一些性能問(wèn)題，但站點(diǎn)目前的要求已經(jīng)開(kāi)始周期性超越SAN的I/O容量--即它從磁盤(pán)存儲系統讀寫(xiě)數據的極限速度。 原因之一是每數據庫1百萬(wàn)賬戶(hù)的分割策略，通常情況下的確可以將壓力均分到各臺服務(wù)器，但現實(shí)并非一成不變。比如第七臺賬戶(hù)數據庫上線(xiàn)后，僅僅7天就被塞滿(mǎn)了，主要原因是佛羅里達一個(gè)樂(lè )隊的歌迷瘋狂注冊。 某個(gè)數據庫可能因為任何原因，在任何時(shí)候遭遇主要負荷，這時(shí)，SAN中綁定到該數據庫的磁盤(pán)存儲設備簇就可能過(guò)載。"SAN讓磁盤(pán)I/O能力大幅提升了，但將它們綁定到特定數據庫的做法是錯誤的。"Benedetto說(shuō)。 最初，MySpace通過(guò)定期重新分配SAN中數據，以讓其更為均衡的方法基本解決了這個(gè)問(wèn)題，但這是一個(gè)人工過(guò)程，"大概需要兩個(gè)人全職工作。"Benedetto說(shuō)。 長(cháng)期解決方案是遷移到虛擬存儲體系上，這樣，整個(gè)SAN被當作一個(gè)巨型存儲池，不再要求每個(gè)磁盤(pán)為特定應用服務(wù)。MySpace目前采用了一種新型SAN設備--來(lái)自加利福尼亞州弗里蒙特的3PARdata。 在3PAR的系統里，仍能在邏輯上按容量劃分數據存儲，但它不再被綁定到特定磁盤(pán)或磁盤(pán)簇，而是散布于大量磁盤(pán)。這就使均分數據訪(fǎng)問(wèn)負荷成為可能。當數據庫需要寫(xiě)入一組數據時(shí)，任何空閑磁盤(pán)都可以馬上完成這項工作，而不再像以前那樣阻塞在可能已經(jīng)過(guò)載的磁盤(pán)陣列處。而且，因為多個(gè)磁盤(pán)都有數據副本，讀取數據時(shí)，也不會(huì )使SAN的任何組件過(guò)載。 當2005年春天賬戶(hù)數達到1千7百萬(wàn)時(shí)，MySpace又啟用了新的策略以減輕存儲系統壓力，即增加數據緩存層--位于Web服務(wù)器和數據庫服務(wù)器之間，其唯一職能是在內存中建立被頻繁請求數據對象的副本，如此一來(lái)，不訪(fǎng)問(wèn)數據庫也可以向Web應用供給數據。換句話(huà)說(shuō)，100個(gè)用戶(hù)請求同一份資料，以前需要查詢(xún)數據庫100次，而現在只需1次，其余都可從緩存數據中獲得。當然如果頁(yè)面變化，緩存的數據必須從內存擦除，然后重新從數據庫獲取--但在此之前，數據庫的壓力已經(jīng)大大減輕，整個(gè)站點(diǎn)的性能得到提升。 緩存區還為那些不需要記入數據庫的數據提供了驛站，比如為跟蹤用戶(hù)會(huì )話(huà)而創(chuàng )建的臨時(shí)文件--Benedetto坦言他需要在這方面補課，"我是數據庫存儲狂熱分子，因此我總是想著(zhù)將萬(wàn)事萬(wàn)物都存到數據庫。"但將像會(huì )話(huà)跟蹤這類(lèi)的數據也存到數據庫，站點(diǎn)將陷入泥沼。 增加緩存服務(wù)器是"一開(kāi)始就應該做的事情，但我們成長(cháng)太快，以致于沒(méi)有時(shí)間坐下來(lái)好好研究這件事情。"Benedetto補充道。 http: 5. 里程碑五：2千6百萬(wàn)賬戶(hù) 2005年中期，服務(wù)賬戶(hù)數達到2千6百萬(wàn)時(shí)，MySpace切換到了還處于beta測試的SQL Server 2005。轉換何太急？主流看法是2005版支持64位處理器。但Benedetto說(shuō)，"這不是主要原因，盡管這也很重要；主要還是因為我們對內存的渴求。"支持64位的數據庫可以管理更多內存。 更多內存就意味著(zhù)更高的性能和更大的容量。原來(lái)運行32位版本的SQL Server服務(wù)器，能同時(shí)使用的內存最多只有4G。切換到64位，就好像加粗了輸水管的直徑。升級到SQL Server 2005和64位Windows Server 2003后，MySpace每臺服務(wù)器配備了32G內存，后于2006年再次將配置標準提升到64G。 意外錯誤 如果沒(méi)有對系統架構的歷次修改與升級，MySpace根本不可能走到今天。但是，為什么系統還經(jīng)常吃撐著(zhù)了？很多用戶(hù)抱怨的"意外錯誤"是怎么引起的呢？ 原因之一是MySpace對Microsoft的Web技術(shù)的應用已經(jīng)進(jìn)入連Microsoft自己也才剛剛開(kāi)始探索的領(lǐng)域。比如11月，超出SQL Server最大同時(shí)連接數，MySpace系統崩潰。Benedetto說(shuō)，這類(lèi)可能引發(fā)系統崩潰的情況大概三天才會(huì )出現一次，但仍然過(guò)于頻繁了，以致惹人惱怒。一旦數據庫罷工，"無(wú)論這種情況什么時(shí)候發(fā)生，未緩存的數據都不能從SQL Server獲得，那么你就必然看到一個(gè)'意外錯誤'提示。"他解釋說(shuō)。 去年夏天，MySpace的Windows 2003多次自動(dòng)停止服務(wù)。后來(lái)發(fā)現是操作系統一個(gè)內置功能惹的禍--預防分布式拒絕服務(wù)攻擊（黑客使用很多客戶(hù)機向服務(wù)器發(fā)起大量連接請求，以致服務(wù)器癱瘓）。MySpace和其他很多頂級大站點(diǎn)一樣，肯定會(huì )經(jīng)常遭受攻擊，但它應該從網(wǎng)絡(luò )級而不是依靠Windows本身的功能來(lái)解決問(wèn)題--否則，大量MySpace合法用戶(hù)連接時(shí)也會(huì )引起服務(wù)器反擊。 "我們花了大約一個(gè)月時(shí)間尋找Windows 2003服務(wù)器自動(dòng)停止的原因。"Benedetto說(shuō)。最后，通過(guò)Microsoft的幫助，他們才知道該怎么通知服務(wù)器："別開(kāi)槍?zhuān)怯衍姟? 緊接著(zhù)是在去年7月某個(gè)周日晚上，MySpace總部所在地洛杉磯停電，造成整個(gè)系統停運12小時(shí)。大型Web站點(diǎn)通常要在地理上分布配置多個(gè)數據中心以預防單點(diǎn)故障。本來(lái)，MySpace還有其他兩個(gè)數據中心以應對突發(fā)事件，但Web服務(wù)器都依賴(lài)于部署在洛杉磯的SAN。沒(méi)有洛杉磯的SAN，Web服務(wù)器除了懇求你耐心等待，不能提供任何服務(wù)。 Benedetto說(shuō)，主數據中心的可靠性通過(guò)下列措施保證：可接入兩張不同電網(wǎng)，另有后備電源和一臺儲備有30天燃料的發(fā)電機。但在這次事故中，不僅兩張電網(wǎng)失效，而且在切換到備份電源的過(guò)程中，操作員燒掉了主動(dòng)力線(xiàn)路。 2007年中，MySpace在另兩個(gè)后備站點(diǎn)上也建設了SAN。這對分擔負荷大有幫助--正常情況下，每個(gè)SAN都能負擔三分之一的數據訪(fǎng)問(wèn)量。而在緊急情況下，任何一個(gè)站點(diǎn)都可以獨立支撐整個(gè)服務(wù)，Benedetto說(shuō)。 MySpace仍然在為提高穩定性?shī)^斗，雖然很多用戶(hù)表示了足夠信任且能原諒偶現的錯誤頁(yè)面。 "作為開(kāi)發(fā)人員，我憎惡Bug，它太氣人了。"Dan Tanner這個(gè)31歲的德克薩斯軟件工程師說(shuō)，他通過(guò)MySpace重新聯(lián)系到了高中和大學(xué)同學(xué)。"不過(guò)，MySpace對我們的用處很大，因此我們可以原諒偶發(fā)的故障和錯誤。" Tanner說(shuō)，如果站點(diǎn)某天出現故障甚至崩潰，恢復以后他還是會(huì )繼續使用。 這就是為什么Drew在論壇里咆哮時(shí)，大部分用戶(hù)都告訴他應該保持平靜，如果等幾分鐘，問(wèn)題就會(huì )解決的原因。Drew無(wú)法平靜，他寫(xiě)道，"我已經(jīng)兩次給MySpace發(fā)郵件，而它說(shuō)一小時(shí)前還是正常的，現在出了點(diǎn)問(wèn)題……完全是一堆廢話(huà)。"另一個(gè)用戶(hù)回復說(shuō)，"畢竟它是免費的。"Benedetto坦承100%的可靠性不是他的目標。"它不是銀行，而是一個(gè)免費的服務(wù)。"他說(shuō)。 換句話(huà)說(shuō)，MySpace的偶發(fā)故障可能造成某人最后更新的個(gè)人資料丟失，但并不意味著(zhù)網(wǎng)站弄丟了用戶(hù)的錢(qián)財。"關(guān)鍵是要認識到，與保證站點(diǎn)性能相比，丟失少許數據的故障是可接受的。"Benedetto說(shuō)。所以，MySpace甘冒丟失2分鐘到2小時(shí)內任意點(diǎn)數據的危險，在SQL Server配置里延長(cháng)了"checkpoint"操作--它將待更新數據永久記錄到磁盤(pán)--的間隔時(shí)間，因為這樣做可以加快數據庫的運行。 Benedetto說(shuō)，同樣，開(kāi)發(fā)人員還經(jīng)常在幾個(gè)小時(shí)內就完成構思、編碼、測試和發(fā)布全過(guò)程。這有引入Bug的風(fēng)險，但這樣做可以更快實(shí)現新功能。而且，因為進(jìn)行大規模真實(shí)測試不具可行性，他們的測試通常是在僅以部分活躍用戶(hù)為對象，且用戶(hù)對軟件新功能和改進(jìn)不知就里的情況下進(jìn)行的。因為事實(shí)上不可能做真實(shí)的加載測試，他們做的測試通常都是針對站點(diǎn)。 "我們犯過(guò)大量錯誤，"Benedetto說(shuō)，"但到頭來(lái)，我認為我們做對的還是比做錯的多。" 七、 從LiveJournal后臺發(fā)展看大規模網(wǎng)站性能優(yōu)化方法 LiveJournal是99年始于校園中的項目，幾個(gè)人出于愛(ài)好做了這樣一個(gè)應用，以實(shí)現以下功能： 博客，論壇 社會(huì )性網(wǎng)絡(luò )，找到朋友 聚合，把朋友的文章聚合在一起 LiveJournal采用了大量的開(kāi)源軟件，甚至它本身也是一個(gè)開(kāi)源軟件。 在上線(xiàn)后，LiveJournal實(shí)現了非?？焖俚脑鲩L(cháng)： 2004年4月份：280萬(wàn)注冊用戶(hù)。 2005年4月份：680萬(wàn)注冊用戶(hù)。 2005年8月份：790萬(wàn)注冊用戶(hù)。 達到了每秒鐘上千次的頁(yè)面請求及處理。 使用了大量MySQL服務(wù)器。 使用了大量通用組件。 二、LiveJournal架構現狀概況 三、從LiveJournal發(fā)展中學(xué)習 LiveJournal從1臺服務(wù)器發(fā)展到100臺服務(wù)器，這其中經(jīng)歷了無(wú)數的傷痛，但同時(shí)也摸索出了解決這些問(wèn)題的方法，通過(guò)對LiveJournal的學(xué)習，可以讓我們避免LJ曾經(jīng)犯過(guò)的錯誤，并且從一開(kāi)始就對系統進(jìn)行良好的設計，以避免后期的痛苦。 下面我們一步一步看LJ發(fā)展的腳步。 1、一臺服務(wù)器 一臺別人捐助的服務(wù)器，LJ最初就跑在上面，就像Google開(kāi)始時(shí)候用的破服務(wù)器一樣，值得我們尊敬。這個(gè)階段，LJ的人以驚人的速度熟悉的Unix的操作管理，服務(wù)器性能出現過(guò)問(wèn)題，不過(guò)還好，可以通過(guò)一些小修小改應付過(guò)去。在這個(gè)階段里L(fēng)J把CGI升級到了FastCGI。 最終問(wèn)題出現了，網(wǎng)站越來(lái)越慢，已經(jīng)無(wú)法通過(guò)優(yōu)過(guò)化來(lái)解決的地步，需要更多的服務(wù)器，這時(shí)LJ開(kāi)始提供付費服務(wù)，可能是想通過(guò)這些錢(qián)來(lái)購買(mǎi)新的服務(wù)器，以解決當時(shí)的困境。 毫無(wú)疑問(wèn)，當時(shí)LJ存在巨大的單點(diǎn)問(wèn)題，所有的東西都在那臺服務(wù)器的鐵皮盒子里裝著(zhù)。 2、兩臺服務(wù)器 用付費服務(wù)賺來(lái)的錢(qián)LJ買(mǎi)了兩臺服務(wù)器：一臺叫做Kenny的Dell 6U機器用于提供Web服務(wù)，一臺叫做Cartman的Dell 6U服務(wù)器用于提供數據庫服務(wù)。 LJ有了更大的磁盤(pán)，更多的計算資源。但同時(shí)網(wǎng)絡(luò )結構還是非常簡(jiǎn)單，每臺機器兩塊網(wǎng)卡，Cartman通過(guò)內網(wǎng)為Kenny提供MySQL數據庫服務(wù)。 暫時(shí)解決了負載的問(wèn)題，新的問(wèn)題又出現了： 原來(lái)的一個(gè)單點(diǎn)變成了兩個(gè)單點(diǎn)。 沒(méi)有冷備份或熱備份。 網(wǎng)站速度慢的問(wèn)題又開(kāi)始出現了，沒(méi)辦法，增長(cháng)太快了。 Web服務(wù)器上CPU達到上限，需要更多的Web服務(wù)器。 3、四臺服務(wù)器 又買(mǎi)了兩臺，Kyle和Stan，這次都是1U的，都用于提供Web服務(wù)。目前LJ一共有3臺Web服務(wù)器和一臺數據庫服務(wù)器。這時(shí)需要在3臺Web服務(wù)器上進(jìn)行負載均橫。 LJ把Kenny用于外部的網(wǎng)關(guān)，使用mod_backhand進(jìn)行負載均橫。 然后問(wèn)題又出現了： 單點(diǎn)故障。數據庫和用于做網(wǎng)關(guān)的Web服務(wù)器都是單點(diǎn)，一旦任何一臺機器出現問(wèn)題將導致所有服務(wù)不可用。雖然用于做網(wǎng)關(guān)的Web服務(wù)器可以通過(guò)保持心跳同步迅速切換，但還是無(wú)法解決數據庫的單點(diǎn)，LJ當時(shí)也沒(méi)做這個(gè)。 網(wǎng)站又變慢了，這次是因為IO和數據庫的問(wèn)題，問(wèn)題是怎么往應用里面添加數據庫呢？ 4、五臺服務(wù)器 又買(mǎi)了一臺數據庫服務(wù)器。在兩臺數據庫服務(wù)器上使用了數據庫同步(Mysql支持的Master-Slave模式)，寫(xiě)操作全部針對主數據庫（通過(guò)Binlog，主服務(wù)器上的寫(xiě)操作可以迅速同步到從服務(wù)器上），讀操作在兩個(gè)數據庫上同時(shí)進(jìn)行(也算是負載均橫的一種吧)。 實(shí)現同步時(shí)要注意幾個(gè)事項： 讀操作數據庫選擇算法處理，要選一個(gè)當前負載輕一點(diǎn)的數據庫。 在從數據庫服務(wù)器上只能進(jìn)行讀操作 準備好應對同步過(guò)程中的延遲，處理不好可能會(huì )導致數據庫同步的中斷。只需要對寫(xiě)操作進(jìn)行判斷即可，讀操作不存在同步問(wèn)題。 5、更多服務(wù)器 有錢(qián)了，當然要多買(mǎi)些服務(wù)器。部署后快了沒(méi)多久，又開(kāi)始慢了。這次有更多的Web服務(wù)器，更多的數據庫服務(wù)器，存在 IO與CPU爭用。于是采用了BIG-IP作為負載均衡解決方案。 6、現在我們在哪里： 現在服務(wù)器基本上夠了，但性能還是有問(wèn)題，原因出在架構上。 數據庫的架構是最大的問(wèn)題。由于增加的數據庫都是以Slave模式添加到應用內，這樣唯一的好處就是將讀操作分布到了多臺機器，但這樣帶來(lái)的后果就是寫(xiě)操作被大量分發(fā)，每臺機器都要執行，服務(wù)器越多，浪費就越大，隨著(zhù)寫(xiě)操作的增加，用于服務(wù)讀操作的資源越來(lái)越少。 由一臺分布到兩臺 最終效果 現在我們發(fā)現，我們并不需要把這些數據在如此多的服務(wù)器上都保留一份。服務(wù)器上已經(jīng)做了RAID，數據庫也進(jìn)行了備份，這么多的備份完全是對資源的浪費，屬于冗余極端過(guò)度。那為什么不把數據分布存儲呢？ 問(wèn)題發(fā)現了，開(kāi)始考慮如何解決?，F在要做的就是把不同用戶(hù)的數據分布到不同的服務(wù)器上進(jìn)行存儲，以實(shí)現數據的分布式存儲，讓每臺機器只為相對固定的用戶(hù)服務(wù)，以實(shí)現平行的架構和良好的可擴展性。 為了實(shí)現用戶(hù)分組，我們需要為每一個(gè)用戶(hù)分配一個(gè)組標記，用于標記此用戶(hù)的數據存放在哪一組數據庫服務(wù)器中。每組數據庫由一個(gè)master及幾個(gè)slave組成，并且slave的數量在2-3臺，以實(shí)現系統資源的最合理分配，既保證數據讀操作分布，又避免數據過(guò)度冗余以及同步操作對系統資源的過(guò)度消耗。 由一臺（一組）中心服務(wù)器提供用戶(hù)分組控制。所有用戶(hù)的分組信息都存儲在這臺機器上，所有針對用戶(hù)的操作需要先查詢(xún)這臺機器得到用戶(hù)的組號，然后再到相應的數據庫組中獲取數據。 這樣的用戶(hù)架構與目前LJ的架構已經(jīng)很相像了。 在具體的實(shí)現時(shí)需要注意幾個(gè)問(wèn)題： 在數據庫組內不要使用自增ID，以便于以后在數據庫組之間遷移用戶(hù)，以實(shí)現更合理的I/O，磁盤(pán)空間及負載分布。 將userid，postid存儲在全局服務(wù)器上，可以使用自增，數據庫組中的相應值必須以全局服務(wù)器上的值為準。全局服務(wù)器上使用事務(wù)型數據庫InnoDB。 在數據庫組之間遷移用戶(hù)時(shí)要萬(wàn)分小心，當遷移時(shí)用戶(hù)不能有寫(xiě)操作 7、現在我們在哪里 問(wèn)題： 一個(gè)全局主服務(wù)器，掛掉的話(huà)所有用戶(hù)注冊及寫(xiě)操作就掛掉。 每個(gè)數據庫組一個(gè)主服務(wù)器，掛掉的話(huà)這組用戶(hù)的寫(xiě)操作就掛掉。 數據庫組從服務(wù)器掛掉的話(huà)會(huì )導致其它服務(wù)器負載過(guò)大。 對于Master-Slave模式的單點(diǎn)問(wèn)題，LJ采取了Master-Master模式來(lái)解決。所謂Master-Master實(shí)際上是人工實(shí)現的，并不是由MySQL直接提供的，實(shí)際上也就是兩臺機器同時(shí)是Master，也同時(shí)是Slave，互相同步。 Master-Master實(shí)現時(shí)需要注意： 一個(gè)Master出錯后恢復同步，最好由服務(wù)器自動(dòng)完成。 數字分配，由于同時(shí)在兩臺機器上寫(xiě)，有些ID可能會(huì )沖突。 解決方案： 奇偶數分配ID，一臺機器上寫(xiě)奇數，一臺機器上寫(xiě)偶數 通過(guò)全局服務(wù)器進(jìn)行分配(LJ采用的做法)。 Master-Master模式還有一種用法，這種方法與前一種相比，仍然保持兩臺機器的同步，但只有一臺機器提供服務(wù)（讀和寫(xiě)），在每天晚上的時(shí)候進(jìn)行輪換，或者出現問(wèn)題的時(shí)候進(jìn)行切換。 問(wèn)題： 一個(gè)全局主服務(wù)器，掛掉的話(huà)所有用戶(hù)注冊及寫(xiě)操作就掛掉。 每個(gè)數據庫組一個(gè)主服務(wù)器，掛掉的話(huà)這組用戶(hù)的寫(xiě)操作就掛掉。 數據庫組從服務(wù)器掛掉的話(huà)會(huì )導致其它服務(wù)器負載過(guò)大。 對于Master-Slave模式的單點(diǎn)問(wèn)題，LJ采取了Master-Master模式來(lái)解決。所謂Master-Master實(shí)際上是人工實(shí)現的，并不是由MySQL直接提供的，實(shí)際上也就是兩臺機器同時(shí)是Master，也同時(shí)是Slave，互相同步。 Master-Master實(shí)現時(shí)需要注意： 一個(gè)Master出錯后恢復同步，最好由服務(wù)器自動(dòng)完成。 數字分配，由于同時(shí)在兩臺機器上寫(xiě)，有些ID可能會(huì )沖突。 解決方案： 奇偶數分配ID，一臺機器上寫(xiě)奇數，一臺機器上寫(xiě)偶數 通過(guò)全局服務(wù)器進(jìn)行分配(LJ采用的做法)。 Master-Master模式還有一種用法，這種方法與前一種相比，仍然保持兩臺機器的同步，但只有一臺機器提供服務(wù)（讀和寫(xiě)），在每天晚上的時(shí)候進(jìn)行輪換，或者出現問(wèn)題的時(shí)候進(jìn)行切換。 8、現在我們在哪里 現在插播一條廣告，MyISAM VS InnoDB。 使用InnoDB： 支持事務(wù) 需要做更多的配置，不過(guò)值得，可以更安全的存儲數據，以及得到更快的速度。 使用MyISAM： 記錄日志（LJ用它來(lái)記網(wǎng)絡(luò )訪(fǎng)問(wèn)日志） 存儲只讀靜態(tài)數據，足夠快。 并發(fā)性很差，無(wú)法同時(shí)讀寫(xiě)數據（添加數據可以） MySQL非正常關(guān)閉或死機時(shí)會(huì )導致索引錯誤，需要使用myisamchk修復，而且當訪(fǎng)問(wèn)量大時(shí)出現非常頻繁。 9、緩存 去年我寫(xiě)過(guò)一篇文章介紹memcached，它就是由LJ的團隊開(kāi)發(fā)的一款緩存工具，以key-value的方式將數據存儲到分布的內存中。LJ緩存的數據： 12臺獨立服務(wù)器（不是捐贈的） 28個(gè)實(shí)例 30GB總容量 90-93%的命中率（用過(guò)squid的人可能知道，squid內存加磁盤(pán)的命中率大概在70-80%） 如何建立緩存策略？ 想緩存所有的東西？那是不可能的，我們只需要緩存已經(jīng)或者可能導致系統瓶頸的地方，最大程度的提交系統運行效率。通過(guò)對MySQL的日志的分析我們可以找到緩存的對象。 緩存的缺點(diǎn)？ 沒(méi)有完美的事物，緩存也有缺點(diǎn)： 增大開(kāi)發(fā)量，需要針對緩存處理編寫(xiě)特殊的代碼。 管理難度增加，需要更多人參與系統維護。 當然大內存也需要錢(qián)。 10、Web訪(fǎng)問(wèn)負載均衡 在數據包級別使用BIG-IP，但BIG-IP并不知道我們內部的處理機制，無(wú)法判斷由哪臺服務(wù)器對這些請求進(jìn)行處理。反向代理并不能很好的起到作用，不是已經(jīng)夠快了，就是達不到我們想要的效果。 所以，LJ又開(kāi)發(fā)了Perlbal。特點(diǎn)： 快，小，可管理的http web 服務(wù)器/代理 可以在內部進(jìn)行轉發(fā) 使用Perl開(kāi)發(fā) 單線(xiàn)程，異步，基于事件，使用epoll , kqueue 支持Console管理與http遠程管理，支持動(dòng)態(tài)配置加載 多種模式：web服務(wù)器，反向代理，插件 支持插件：GIF/PNG互換？ 11、MogileFS LJ使用開(kāi)源的MogileFS作為分布式文件存儲系統。MogileFS使用非常簡(jiǎn)單，它的主要設計思想是： 文件屬于類(lèi)（類(lèi)是最小的復制單位） 跟蹤文件存儲位置 在不同主機上存儲 使用MySQL集群統一存儲分布信息 大容易廉價(jià)磁盤(pán) 到目前為止就這么多了，更多文檔可以在http: 八、 說(shuō)說(shuō)大型高并發(fā)高負載網(wǎng)站的系統架構 我在Cernet做過(guò)撥號接入平臺的搭建，而后在Yahoo3721負載搜索引擎前端平臺開(kāi)發(fā)，又在貓撲處理過(guò)大型社區貓撲大雜燴的架構升級等工作，同時(shí)自己接觸和開(kāi)發(fā)過(guò)不少大中型網(wǎng)站的模塊，因此在大型網(wǎng)站應對高負載和并發(fā)的解決方案上有一些積累和經(jīng)驗，可以和大家一起探討一下。 一個(gè)小型的網(wǎng)站，比如個(gè)人網(wǎng)站，可以使用最簡(jiǎn)單的html靜態(tài)頁(yè)面就實(shí)現了，配合一些圖片達到美化效果，所有的頁(yè)面均存放在一個(gè)目錄下，這樣的網(wǎng)站對系統架構、性能的要求都很簡(jiǎn)單，隨著(zhù)互聯(lián)網(wǎng)業(yè)務(wù)的不斷豐富，網(wǎng)站相關(guān)的技術(shù)經(jīng)過(guò)這些年的發(fā)展，已經(jīng)細分到很細的方方面面，尤其對于大型網(wǎng)站來(lái)說(shuō)，所采用的技術(shù)更是涉及面非常廣，從硬件到軟件、編程語(yǔ)言、數據庫、WebServer、防火墻等各個(gè)領(lǐng)域都有了很高的要求，已經(jīng)不是原來(lái)簡(jiǎn)單的html靜態(tài)網(wǎng)站所能比擬的。 大型網(wǎng)站，比如門(mén)戶(hù)網(wǎng)站。在面對大量用戶(hù)訪(fǎng)問(wèn)、高并發(fā)請求方面，基本的解決方案集中在這樣幾個(gè)環(huán)節：使用高性能的服務(wù)器、高性能的數據庫、高效率的編程語(yǔ)言、還有高性能的Web容器。但是除了這幾個(gè)方面，還沒(méi)法根本解決大型網(wǎng)站面臨的高負載和高并發(fā)問(wèn)題。 上面提供的幾個(gè)解決思路在一定程度上也意味著(zhù)更大的投入，并且這樣的解決思路具備瓶頸，沒(méi)有很好的擴展性，下面我從低成本、高性能和高擴張性的角度來(lái)說(shuō)說(shuō)我的一些經(jīng)驗。 http: 1、HTML靜態(tài)化 其實(shí)大家都知道，效率最高、消耗最小的就是純靜態(tài)化的html頁(yè)面，所以我們盡可能使我們的網(wǎng)站上的頁(yè)面采用靜態(tài)頁(yè)面來(lái)實(shí)現，這個(gè)最簡(jiǎn)單的方法其實(shí)也是最有效的方法。但是對于大量?jì)热莶⑶翌l繁更新的網(wǎng)站，我們無(wú)法全部手動(dòng)去挨個(gè)實(shí)現，于是出現了我們常見(jiàn)的信息發(fā)布系統CMS，像我們常訪(fǎng)問(wèn)的各個(gè)門(mén)戶(hù)站點(diǎn)的新聞頻道，甚至他們的其他頻道，都是通過(guò)信息發(fā)布系統來(lái)管理和實(shí)現的，信息發(fā)布系統可以實(shí)現最簡(jiǎn)單的信息錄入自動(dòng)生成靜態(tài)頁(yè)面，還能具備頻道管理、權限管理、自動(dòng)抓取等功能，對于一個(gè)大型網(wǎng)站來(lái)說(shuō)，擁有一套高效、可管理的CMS是必不可少的。 http: 除了門(mén)戶(hù)和信息發(fā)布類(lèi)型的網(wǎng)站，對于交互性要求很高的社區類(lèi)型網(wǎng)站來(lái)說(shuō)，盡可能的靜態(tài)化也是提高性能的必要手段，將社區內的帖子、文章進(jìn)行實(shí)時(shí)的靜態(tài)化，有更新的時(shí)候再重新靜態(tài)化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網(wǎng)易社區等也是如此。 同時(shí)，html靜態(tài)化也是某些緩存策略使用的手段，對于系統中頻繁使用數據庫查詢(xún)但是內容更新很小的應用，可以考慮使用html靜態(tài)化來(lái)實(shí)現，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進(jìn)行后臺管理并且存儲再數據庫中，這些信息其實(shí)大量被前臺程序調用，但是更新頻率很小，可以考慮將這部分內容進(jìn)行后臺更新的時(shí)候進(jìn)行靜態(tài)化，這樣避免了大量的數據庫訪(fǎng)問(wèn)請求。 2、圖片服務(wù)器分離 大家知道，對于Web服務(wù)器來(lái)說(shuō)，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁(yè)面進(jìn)行分離，這是基本上大型網(wǎng)站都會(huì )采用的策略，他們都有獨立的圖片服務(wù)器，甚至很多臺圖片服務(wù)器。這樣的架構可以降低提供頁(yè)面訪(fǎng)問(wèn)請求的服務(wù)器系統壓力，并且可以保證系統不會(huì )因為圖片問(wèn)題而崩潰，在應用服務(wù)器和圖片服務(wù)器上，可以進(jìn)行不同的配置優(yōu)化，比如apache在配置ContentType的時(shí)候可以盡量少支持，盡可能少的LoadModule，保證更高的系統消耗和執行效率。 3、數據庫集群和庫表散列 大型網(wǎng)站都有復雜的應用，這些應用必須使用數據庫，那么在面對大量訪(fǎng)問(wèn)的時(shí)候，數據庫的瓶頸很快就能顯現出來(lái)，這時(shí)一臺數據庫將很快無(wú)法滿(mǎn)足應用，于是我們需要使用數據庫集群或者庫表散列。 在數據庫集群方面，很多數據庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類(lèi)似的方案，您使用了什么樣的DB，就參考相應的解決方案來(lái)實(shí)施即可。 上面提到的數據庫集群由于在架構、成本、擴張性方面都會(huì )受到所采用DB類(lèi)型的限制，于是我們需要從應用程序的角度來(lái)考慮改善系統架構，庫表散列是常用并且最有效的解決方案。我們在應用程序中安裝業(yè)務(wù)和應用或者功能模塊將數據庫進(jìn)行分離，不同的模塊對應不同的數據庫或者表，再按照一定的策略對某個(gè)頁(yè)面或者功能進(jìn)行更小的數據庫散列，比如用戶(hù)表，按照用戶(hù)ID進(jìn)行表散列，這樣就能夠低成本的提升系統的性能并且有很好的擴展性。sohu的論壇就是采用了這樣的架構，將論壇的用戶(hù)、設置、帖子等信息進(jìn)行數據庫分離，然后對帖子、用戶(hù)按照板塊和ID進(jìn)行散列數據庫和表，最終可以在配置文件中進(jìn)行簡(jiǎn)單的配置便能讓系統隨時(shí)增加一臺低成本的數據庫進(jìn)來(lái)補充系統性能。 4、緩存 緩存一詞搞技術(shù)的都接觸過(guò)，很多地方用到緩存。網(wǎng)站架構和網(wǎng)站開(kāi)發(fā)中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在后面講述。 架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進(jìn)行緩存，這兩種方式均可以有效的提高Apache的訪(fǎng)問(wèn)響應能力 網(wǎng)站程序開(kāi)發(fā)方面的緩存，Linux上提供的Memory Cache是常用的緩存接口，可以在web開(kāi)發(fā)中使用，比如用Java開(kāi)發(fā)的時(shí)候就可以調用MemoryCache對一些數據進(jìn)行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語(yǔ)言開(kāi)發(fā)的時(shí)候，各種語(yǔ)言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。 5、鏡像 鏡像是大型網(wǎng)站常采用的提高性能和數據安全性的方式，鏡像的技術(shù)可以解決不同網(wǎng)絡(luò )接入商和地域帶來(lái)的用戶(hù)訪(fǎng)問(wèn)速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內搭建鏡像站點(diǎn)，數據進(jìn)行定時(shí)更新或者實(shí)時(shí)更新。在鏡像的細節技術(shù)方面，這里不闡述太深，有很多專(zhuān)業(yè)的現成的解決架構和產(chǎn)品可選。也有廉價(jià)的通過(guò)軟件實(shí)現的思路，比如Linux上的rsync等工具。 6、負載均衡 負載均衡將是大型網(wǎng)站解決高負荷訪(fǎng)問(wèn)和大量并發(fā)請求采用的終極解決辦法。 負載均衡技術(shù)發(fā)展了多年，有很多專(zhuān)業(yè)的服務(wù)提供商和產(chǎn)品可以選擇，我個(gè)人接觸過(guò)一些解決方法，其中有兩個(gè)架構可以給大家做參考。 硬件四層交換 第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業(yè)務(wù)流，將整個(gè)區間段的業(yè)務(wù)流分配到合適的應用服務(wù)器進(jìn)行處理?！〉谒膶咏粨Q功能就象是虛IP，指向物理服務(wù)器。它傳輸的業(yè)務(wù)服從的協(xié)議多種多樣，有HTTP、FTP、NFS、Telnet或其他協(xié)議。這些業(yè)務(wù)在物理服務(wù)器基礎上，需要復雜的載量平衡算法。在IP世界，業(yè)務(wù)類(lèi)型由終端TCP或UDP端口地址來(lái)決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。 在硬件四層交換產(chǎn)品領(lǐng)域，有一些知名的產(chǎn)品可以選擇，比如Alteon、F5等，這些產(chǎn)品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務(wù)器使用了三四臺Alteon就搞定了。 軟件四層交換 大家知道了硬件四層交換機的原理后，基于OSI模型來(lái)實(shí)現的軟件四層交換也就應運而生，這樣的解決方案實(shí)現的原理一致，不過(guò)性能稍差。但是滿(mǎn)足一定量的壓力還是游刃有余的，有人說(shuō)軟件實(shí)現方式其實(shí)更靈活，處理能力完全看你配置的熟悉能力。 軟件四層交換我們可以使用Linux上常用的LVS來(lái)解決，LVS就是Linux Virtual Server，他提供了基于心跳線(xiàn)heartbeat的實(shí)時(shí)災難應對解決方案，提高系統的魯棒性，同時(shí)可供了靈活的虛擬VIP配置和管理功能，可以同時(shí)滿(mǎn)足多種應用需求，這對于分布式的系統來(lái)說(shuō)必不可少。 一個(gè)典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網(wǎng)站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性，隨時(shí)往架構里面增減節點(diǎn)都非常容易。這樣的架構我準備空了專(zhuān)門(mén)詳細整理一下和大家探討。 對于大型網(wǎng)站來(lái)說(shuō)，前面提到的每個(gè)方法可能都會(huì )被同時(shí)使用到，我這里介紹得比較淺顯，具體實(shí)現過(guò)程中很多細節還需要大家慢慢熟悉和體會(huì )，有時(shí)一個(gè)很小的squid參數或者apache參數設置，對于系統性能的影響就會(huì )很大，希望大家一起討論，達到拋磚引玉之效。 本篇文章來(lái)源于 - http:
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
