




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡(jiǎn)介
大型高并發(fā)高負(fù)載網(wǎng)站的系統(tǒng)架構(gòu)我在CERNET做過撥號(hào)接入平臺(tái)的搭建,而后在Yahoo&3721從事過搜索引擎前端開發(fā),又在MOP處理過大型社區(qū)貓撲大雜燴的架構(gòu)升級(jí)等工作,同時(shí)自己接觸和開發(fā)過不少大中型網(wǎng)站的模塊,因此在大型網(wǎng)站應(yīng)對(duì)高負(fù)載和并發(fā)的解決方案上有一些積累和經(jīng)驗(yàn),可以和大家一起探討一下。一個(gè)小型的網(wǎng)站,比如個(gè)人網(wǎng)站,可以使用最簡(jiǎn)單的html靜態(tài)頁(yè)面就實(shí)現(xiàn)了,配合一些圖片達(dá)到美化效果,所有的頁(yè)面均存放在一個(gè)目錄下,這樣的網(wǎng)站對(duì)系統(tǒng)架構(gòu)、性能的要求都很簡(jiǎn)單,隨著互聯(lián)網(wǎng)業(yè)務(wù)的不斷豐富,網(wǎng)站相關(guān)的技術(shù)經(jīng)過這些年的發(fā)展,已經(jīng)細(xì)分到很細(xì)的方方面面,尤其對(duì)于大型網(wǎng)站來說,所采用的技術(shù)更是涉及面非常廣,從硬件到軟件、編程語言、數(shù)據(jù)庫(kù)、WebServer、防火墻等各個(gè)領(lǐng)域都有了很高的要求,已經(jīng)不是原來簡(jiǎn)單的html靜態(tài)網(wǎng)站所能比擬的。大型網(wǎng)站,比如門戶網(wǎng)站。在面對(duì)大量用戶訪問、高并發(fā)請(qǐng)求方面,基本的解決方案集中在這樣幾個(gè)環(huán)節(jié):使用高性能的服務(wù)器、高性能的數(shù)據(jù)庫(kù)、高效率的編程語言、還有高性能的Web容器。但是除了這幾個(gè)方面,還沒法根本解決大型網(wǎng)站面臨的高負(fù)載和高并發(fā)問題。上面提供的幾個(gè)解決思路在一定程度上也意味著更大的投入,并且這樣的解決思路具備瓶頸,沒有很好的擴(kuò)展性,下面我從低成本、高性能和高擴(kuò)張性的角度來說說我的一些經(jīng)驗(yàn)。1、HTML靜態(tài)化其實(shí)大家都知道,效率最高、消耗最小的就是純靜態(tài)化的html頁(yè)面,所以我們盡可能使我們的網(wǎng)站上的頁(yè)面采用靜態(tài)頁(yè)面來實(shí)現(xiàn),這個(gè)最簡(jiǎn)單的方法其實(shí)也是最有效的方法。但是對(duì)于大量?jī)?nèi)容并且頻繁更新的網(wǎng)站,我們無法全部手動(dòng)去挨個(gè)實(shí)現(xiàn),于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng)CMS,像我們常訪問的各個(gè)門戶站點(diǎn)的新聞?lì)l道,甚至他們的其他頻道,都是通過信息發(fā)布系統(tǒng)來管理和實(shí)現(xiàn)的,信息發(fā)布系統(tǒng)可以實(shí)現(xiàn)最簡(jiǎn)單的信息錄入自動(dòng)生成靜態(tài)頁(yè)面,還能具備頻道管理、權(quán)限管理、自動(dòng)抓取等功能,對(duì)于一個(gè)大型網(wǎng)站來說,擁有一套高效、可管理的CMS是必不可少的。除了門戶和信息發(fā)布類型的網(wǎng)站,對(duì)于交互性要求很高的社區(qū)類型網(wǎng)站來說,盡可能的靜態(tài)化也是提高性能的必要手段,將社區(qū)內(nèi)的帖子、文章進(jìn)行實(shí)時(shí)的靜態(tài)化,有更新的時(shí)候再重新靜態(tài)化也是大量使用的策略,像Mop的大雜燴就是使用了這樣的策略,網(wǎng)易社區(qū)等也是如此。目前很多博客也都實(shí)現(xiàn)了靜態(tài)化,我使用的這個(gè)Blog程序WordPress還沒有靜態(tài)化,所以如果面對(duì)高負(fù)載訪問,-定不能承受同時(shí),html靜態(tài)化也是某些緩存策略使用的手段,對(duì)于系統(tǒng)中頻繁使用數(shù)據(jù)庫(kù)查詢但是內(nèi)容更新很小的應(yīng)用,可以考慮使用html靜態(tài)化來實(shí)現(xiàn),比如論壇中論壇的公用設(shè)置信息,這些信息目前的主流論壇都可以進(jìn)行后臺(tái)管理并且存儲(chǔ)再數(shù)據(jù)庫(kù)中,這些信息其實(shí)大量被前臺(tái)程序調(diào)用,但是更新頻率很小,可以考慮將這部分內(nèi)容進(jìn)行后臺(tái)更新的時(shí)候進(jìn)行靜態(tài)化,這樣避免了大量的數(shù)據(jù)庫(kù)訪問請(qǐng)求。在進(jìn)行html靜態(tài)化的時(shí)候可以使用一種折中的方法,就是前端使用動(dòng)態(tài)實(shí)現(xiàn),在一定的策略下進(jìn)行定時(shí)靜態(tài)化和定時(shí)判斷調(diào)用,這個(gè)能實(shí)現(xiàn)很多靈活性的操作,我開發(fā)的臺(tái)球網(wǎng)站故人居(就是使用了這樣的方法,我通過設(shè)定一些html靜態(tài)化的時(shí)間間隔來對(duì)動(dòng)態(tài)網(wǎng)站內(nèi)容進(jìn)行緩存,達(dá)到分擔(dān)大部分的壓力到靜態(tài)頁(yè)面上,可以應(yīng)用于中小型網(wǎng)站的架構(gòu)上。故人居網(wǎng)站的地址:http://www.8zone.0n順便提一下,有喜歡臺(tái)球的朋友多多支持我這個(gè)免費(fèi)網(wǎng)站:)2、圖片服務(wù)器分離大家知道,對(duì)于Web服務(wù)器來說,不管是Apache.IIS還是其他容器,圖片是最消耗資源的,于是我們有必要將圖片與頁(yè)面進(jìn)行分離,這是基本上大型網(wǎng)站都會(huì)采用的策略,他們都有獨(dú)立的圖片服務(wù)器,甚至很多臺(tái)圖片服務(wù)器。這樣的架構(gòu)可以降低提供頁(yè)面訪問請(qǐng)求的服務(wù)器系統(tǒng)壓力,并且可以保證系統(tǒng)不會(huì)因?yàn)閳D片問題而崩潰。在應(yīng)用服務(wù)器和圖片服務(wù)器上,可以進(jìn)行不同的配置優(yōu)化,比如Apache在配置ContentType的時(shí)候可以盡量少支持,盡可能少的LoadModule,保證更高的系統(tǒng)消耗和執(zhí)行效率。我的臺(tái)球網(wǎng)站故人居8也使用了圖片服務(wù)器架構(gòu)上的分離,目前是僅僅是架構(gòu)上分離,物理上沒有分離,由于沒有錢買更多的服務(wù)器:)大家可以看到故人居上的圖片連接都是類似或者的URL。另外,在處理靜態(tài)頁(yè)面或者圖片、js等訪問方面,可以考慮使用lighttp代替Apache,它提供了更輕量級(jí)和更高效的處理能力。3、數(shù)據(jù)庫(kù)集群和庫(kù)表散列大型網(wǎng)站都有復(fù)雜的應(yīng)用,這些應(yīng)用必須使用數(shù)據(jù)庫(kù),那么在面對(duì)大量訪問的時(shí)候,數(shù)據(jù)庫(kù)的瓶頸很快就能顯現(xiàn)出來,這時(shí)一臺(tái)數(shù)據(jù)庫(kù)將很快無法滿足應(yīng)用,于是我們需要使用數(shù)據(jù)庫(kù)集群或者庫(kù)表散列。在數(shù)據(jù)庫(kù)集群方面,很多數(shù)據(jù)庫(kù)都有自己的解決方案,OracleSybase等都有很好的方案,常用的MySQL提供的Master/Slav也是類似的方案,您使用了什么樣的DB,就參考相應(yīng)的解決方案來實(shí)施即可。上面提到的數(shù)據(jù)庫(kù)集群由于在架構(gòu)、成本、擴(kuò)張性方面都會(huì)受到所采用DB類型的限制,于是我們需要從應(yīng)用程序的角度來考慮改善系統(tǒng)架構(gòu),庫(kù)表散列是常用并且最有效的解決方案。我們?cè)趹?yīng)用程序中安裝業(yè)務(wù)和應(yīng)用或者功能模塊將數(shù)據(jù)庫(kù)進(jìn)行分離,不同的模塊對(duì)應(yīng)不同的數(shù)據(jù)庫(kù)或者表,再按照一定的策略對(duì)某個(gè)頁(yè)面或者功能進(jìn)行更小的數(shù)據(jù)庫(kù)散列,比如用戶表,按照用戶ID進(jìn)行表散列,這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴(kuò)展性。sohu的論壇就是采用了這樣的架構(gòu),將論壇的用戶、設(shè)置、帖子等信息進(jìn)行數(shù)據(jù)庫(kù)分離,然后對(duì)帖子、用戶按照板塊和ID進(jìn)行散列數(shù)據(jù)庫(kù)和表,最終可以在配置文件中進(jìn)行簡(jiǎn)單的配置便能讓系統(tǒng)隨時(shí)增加一臺(tái)低成本的數(shù)據(jù)庫(kù)進(jìn)來補(bǔ)充系統(tǒng)性能。4、緩存緩存一詞搞技術(shù)的都接觸過,很多地方用到緩存。網(wǎng)站架構(gòu)和網(wǎng)站開發(fā)中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級(jí)和分布式的緩存在后面講述。架構(gòu)方面的緩存,對(duì)Apache比較熟悉的人都能知道Apache提供了自己的mod_proxy緩存模塊,也可以使用外加的Squid進(jìn)行緩存,這兩種方式均可以有效的提高Apache的訪問響應(yīng)能力。網(wǎng)站程序開發(fā)方面的緩存,Linux上提供的Memcached是常用的緩存方案,不少web編程語言都提供memcache訪問接口,php、per、c和java都有,可以在web開發(fā)中使用,可以實(shí)時(shí)或者Cron的把數(shù)據(jù)、對(duì)象等內(nèi)容進(jìn)行緩存,策略非常靈活。一些大型社區(qū)使用了這樣的架構(gòu)。另外,在使用web語言開發(fā)的時(shí)候,各種語言基本都有自己的緩存模塊和方法,PHP有Pear的Cache模塊和eAccelerato加速和Cache模塊,還要知名的Apc、XCache(國(guó)人開發(fā)的,支持?。﹑hp緩存模塊,Java就更多了,.ne不是很熟悉,相信也肯定有。5、鏡像鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式,鏡像的技術(shù)可以解決不同網(wǎng)絡(luò)接入商和地域帶來的用戶訪問速度差異,比如ChinaNet和EduNet之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內(nèi)搭建鏡像站點(diǎn),數(shù)據(jù)進(jìn)行定時(shí)更新或者實(shí)時(shí)更新。在鏡像的細(xì)節(jié)技術(shù)方面,這里不闡述太深,有很多專業(yè)的現(xiàn)成的解決架構(gòu)和產(chǎn)品可選。也有廉價(jià)的通過軟件實(shí)現(xiàn)的思路,比如Linux上的rsync等工具。6、負(fù)載均衡負(fù)載均衡將是大型網(wǎng)站解決高負(fù)荷訪問和大量并發(fā)請(qǐng)求采用的終極解決辦法。負(fù)載均衡技術(shù)發(fā)展了多年,有很多專業(yè)的服務(wù)提供商和產(chǎn)品可以選擇,我個(gè)人接觸過一些解決方法,其中有兩個(gè)架構(gòu)可以給大家做參考。另外有關(guān)初級(jí)的負(fù)載均衡DNS輪循和較專業(yè)的CDN架構(gòu)就不多說了。6.1硬件四層交換第四層交換使用第三層和第四層信息包的報(bào)頭信息,根據(jù)應(yīng)用區(qū)間識(shí)別業(yè)務(wù)流,將整個(gè)區(qū)間段的業(yè)務(wù)流分配到合適的應(yīng)用服務(wù)器進(jìn)行處理。第四層交換功能就象是虛IP,指向物理服務(wù)器。它傳輸?shù)臉I(yè)務(wù)服從的協(xié)議多種多樣,有http、FTP、NFS、Telnet或其他協(xié)議。這些業(yè)務(wù)在物理服務(wù)器基礎(chǔ)上,需要復(fù)雜的載量平衡算法。在IP世界,業(yè)務(wù)類型由終端TCP或UDP端口地址來決定,在第四層交換中的應(yīng)用區(qū)間則由源端和終端IP地址、TCP和UDP端口共同決定。在硬件四層交換產(chǎn)品領(lǐng)域,有一些知名的產(chǎn)品可以選擇,比如AlteonF5等,這些產(chǎn)品很昂貴,但是物有所值,能夠提供非常優(yōu)秀的性能和很靈活的管理能力oYahoo中國(guó)當(dāng)初接近2000臺(tái)服務(wù)器使用了三四臺(tái)Alteor就搞定了。6.2軟件四層交換大家知道了硬件四層交換機(jī)的原理后,基于OSI模型來實(shí)現(xiàn)的軟件四層交換也就應(yīng)運(yùn)而生,這樣的解決方案實(shí)現(xiàn)的原理一致,不過性能稍差。但是滿足一定量的壓力還是游刃有余的,有人說軟件實(shí)現(xiàn)方式其實(shí)更靈活,處理能力完全看你配置的熟悉能力。軟件四層交換我們可以使用Linux上常用的LVS來解決,LVS就是LinuxVirtualSer,ver他提供了基于心跳線heartbeat實(shí)時(shí)災(zāi)難應(yīng)對(duì)解決方案,提高系統(tǒng)的魯棒性,同時(shí)可供了靈活的虛擬VIP配置和管理功能,可以同時(shí)滿足多種應(yīng)用需求,這對(duì)于分布式的系統(tǒng)來說必不可少。一個(gè)典型的使用負(fù)載均衡的策略就是,在軟件或者硬件四層交換的基礎(chǔ)上搭建squid集群,這種思路在很多大型網(wǎng)站包括搜索引擎上被采用,這樣的架構(gòu)低成本、高性能還有很強(qiáng)的擴(kuò)張性,隨時(shí)往架構(gòu)里面增減節(jié)點(diǎn)都非常容易。這樣的架構(gòu)我準(zhǔn)備空了專門詳細(xì)整理一下和大家探討??偨Y(jié):對(duì)于大型網(wǎng)站來說,前面提到的每個(gè)方法可能都會(huì)被同時(shí)使用到,Michael這里介紹得比較淺顯,具體實(shí)現(xiàn)過程中很多細(xì)節(jié)還需要大家慢慢熟悉和體會(huì),有時(shí)一個(gè)很小的squid#數(shù)或者apache參數(shù)設(shè)置,對(duì)于系統(tǒng)性能的影響就會(huì)很大,希望大家一起討論,達(dá)到拋磚引玉之效。使用開源軟件,設(shè)計(jì)高性能可擴(kuò)展互動(dòng)網(wǎng)站上次我們以LiveJournal例詳細(xì)分析了一個(gè)小網(wǎng)站在一步一步的發(fā)展成為大規(guī)模的網(wǎng)站中性能優(yōu)化的方案,以解決在發(fā)展中由于負(fù)載增長(zhǎng)而引起的性能問題,同時(shí)在設(shè)計(jì)網(wǎng)站架構(gòu)的時(shí)候就從根本上避免或者解決這些問題。今天我們來看一下在網(wǎng)站的設(shè)計(jì)上一些通常使用的解決大規(guī)模訪問,高負(fù)載的方法。我們將主要涉及到以下幾方面:1士土土LU十卜1、前端負(fù)載2、業(yè)務(wù)邏輯層3、數(shù)據(jù)層在LJ性能優(yōu)化文章中我們提到對(duì)服務(wù)器分組是解決負(fù)載問題,實(shí)現(xiàn)無限擴(kuò)展的解決方案。通常中我們會(huì)采用類似LDAP的方案來解決,這在郵件的服務(wù)器以及個(gè)人網(wǎng)站,博客的應(yīng)用中都有使用,在Windows下面有類似的ActiveDirecto解決方案。有的應(yīng)用(例如博客或者個(gè)人網(wǎng)頁(yè))會(huì)要求在二級(jí)域名解析的時(shí)候就將用戶定位到所屬的服務(wù)器群組,這個(gè)時(shí)候請(qǐng)求還沒到應(yīng)用上面,我們需要在DNS里解決這個(gè)問題。這個(gè)時(shí)候可以用到一款軟件binddl,z這是bind的一個(gè)插件,用于取代bind的文本解析配置文件。它支持包括LDAP,BDB在內(nèi)的多種數(shù)據(jù)存儲(chǔ)方式,可以比較好的解決這個(gè)問題。另外一種涉及到DNS的問題就是目前普遍存在的南北互聯(lián)互通的問題,通過bind9內(nèi)置的視圖功能可以根據(jù)不同的IP來源解析出不同的結(jié)果,從而將南方的用戶解析到南方的服務(wù)器,北方的用戶解析到北方的服務(wù)器。這個(gè)過程中會(huì)碰到兩個(gè)問題,一是取得南北IP的分布列表,二是保證南北服務(wù)器之間的通訊順暢。第一個(gè)問題有個(gè)笨辦法解決,從日志里取出所有的訪問者IP,寫一個(gè)腳本從南北的服務(wù)器分別Ping回去,然后分析結(jié)果,可以得到一個(gè)大致準(zhǔn)確的列表,當(dāng)然最好的辦法還是直到從運(yùn)營(yíng)商那里拿到這份列表(update參見這篇文章)。后一個(gè)問題解決辦法比較多,最好的辦法就是租用雙線機(jī)房,同一臺(tái)機(jī)器,雙IP,南北同時(shí)接入,差一些的辦法就是南北各自找機(jī)房,通過大量的測(cè)試找出中間通訊順暢的兩個(gè)機(jī)房,后一種通常來說成本較低,但效果較差,維護(hù)不便。另外DNS負(fù)載均衡也是廣泛使用的一種負(fù)載均衡方法,通過并列的多條A記錄將訪問隨即的分布到多臺(tái)前端服務(wù)器上,這種通常使用在靜態(tài)頁(yè)面居多的應(yīng)用上,幾大門戶內(nèi)容部分的前端很多都是用的這種方法。用戶被定位到正確的服務(wù)器群組后,應(yīng)用程序就接手用戶的請(qǐng)求,并開始沿著定義好的業(yè)務(wù)邏輯進(jìn)行處理。這些請(qǐng)求主要包括兩類靜態(tài)文件(圖片,js腳本,csSg),動(dòng)態(tài)請(qǐng)求。靜態(tài)請(qǐng)求一般使用squid進(jìn)行緩存處理,可以根據(jù)應(yīng)用的規(guī)模采用不同的緩存配置方案,可以是一級(jí)緩存,也可以是多級(jí)緩存,一般情況下cache的命中率可以達(dá)到70%左右,能夠比較有效的提升服務(wù)器處理能力。Apache的deflat模塊可以壓縮傳輸數(shù)據(jù),提高速度,2.0版本以后的cache模塊也內(nèi)置實(shí)現(xiàn)磁盤和內(nèi)存的緩存,而不必要一定做反向代理。動(dòng)態(tài)請(qǐng)求目前一般有兩種處理方式,一種是靜態(tài)化,在頁(yè)面發(fā)生變化時(shí)重新靜態(tài)頁(yè)面,現(xiàn)在大量的CMS,BBS都采用這種方案,加上cache,可以提供較快的訪問速度。這種通常是寫操作較少的應(yīng)用比較適合的解決方案。另一種解決辦法是動(dòng)態(tài)緩存,所有的訪問都仍然通過應(yīng)用處理,只是應(yīng)用處理的時(shí)候會(huì)更多的使用內(nèi)存,而不是數(shù)據(jù)庫(kù)。通常訪問數(shù)據(jù)庫(kù)的操作是極慢的,而訪問內(nèi)存的操作很快,至少是一個(gè)數(shù)量級(jí)的差距,使用memcached可以實(shí)現(xiàn)這一解決方案,做的好的memcache甚至可以達(dá)到90%以上的緩存命中率。10年前我用的還是2M的內(nèi)存,那時(shí)的一本雜事上曾經(jīng)風(fēng)趣的描述一對(duì)父子的對(duì)話:兒子:爸爸,我想要1G的內(nèi)存。爸爸:兒子,不行,即使是你過生日也不行。時(shí)至今日,大內(nèi)存的成本已經(jīng)完全可以承受。Google使用了大量的PC機(jī)建立集群用于數(shù)據(jù)處理,而我一直覺得,使用大內(nèi)存PC可以很低成本的解決前端甚至中間的負(fù)載問題。由于PC硬盤壽命比較短,速度比較慢,CPU也稍慢,用于做web前端既便宜,又能充分發(fā)揮大內(nèi)存的優(yōu)勢(shì),而且壞了的話只需要替換即可,不存在數(shù)據(jù)的遷移問題。下面就是應(yīng)用的設(shè)計(jì)。應(yīng)用在設(shè)計(jì)的時(shí)候應(yīng)當(dāng)盡量的設(shè)計(jì)成支持可擴(kuò)展的數(shù)據(jù)庫(kù)設(shè)計(jì),數(shù)據(jù)庫(kù)可以動(dòng)態(tài)的添加,同時(shí)支持內(nèi)存緩存,這樣的成本是最低的。另外一種應(yīng)用設(shè)計(jì)的方法是采用中間件,例如ICE。這種方案的優(yōu)點(diǎn)是前端應(yīng)用可以設(shè)計(jì)的相對(duì)簡(jiǎn)單,數(shù)據(jù)層對(duì)于前端應(yīng)用透明,由ICE提供,數(shù)據(jù)庫(kù)分布式的設(shè)計(jì)在后端實(shí)現(xiàn),使用ICE封裝后給前端應(yīng)用使用,這路設(shè)計(jì)對(duì)每一部分設(shè)計(jì)的要求較低,將業(yè)務(wù)更好的分層,但由于引入了中間件,分了更多層,實(shí)現(xiàn)起來成本也相對(duì)較高。在數(shù)據(jù)庫(kù)的設(shè)計(jì)上一方面可以使用集群,一方面進(jìn)行分組。同時(shí)在細(xì)節(jié)上將數(shù)據(jù)庫(kù)優(yōu)化的原則盡量應(yīng)用,數(shù)據(jù)庫(kù)結(jié)構(gòu)和數(shù)據(jù)層應(yīng)用在設(shè)計(jì)上盡量避免臨時(shí)表的創(chuàng)建、死鎖的產(chǎn)生。數(shù)據(jù)庫(kù)優(yōu)化的原則在網(wǎng)上比較常見,多google-下就能解決問題。在數(shù)據(jù)庫(kù)的選擇上可以根據(jù)自己的習(xí)慣選擇,OracleMySQL等,并非0甜己。就夠解決所有的問題,也并非MySQL就代表小應(yīng)用,合適的就是最好的。前面講的都是基于軟件的性能設(shè)計(jì)方案,實(shí)際上硬件的良好搭配使用也可以有效的降低時(shí)間成本,以及開發(fā)維護(hù)成本,只是在這里我們不再展開。網(wǎng)站架構(gòu)的設(shè)計(jì)是一個(gè)整體的工程,在設(shè)計(jì)的時(shí)候需要考慮到性能,可括展性,硬件成本,時(shí)間成本等等,如何根據(jù)業(yè)務(wù)的定位,資金,時(shí)間,人員的條件設(shè)計(jì)合適的方案是件比較困難的事情,但多想多實(shí)踐,終究會(huì)建立一套適合自己的網(wǎng)站設(shè)計(jì)理念,用于指導(dǎo)網(wǎng)站的設(shè)計(jì)工作,為網(wǎng)站的發(fā)展奠定良好的基礎(chǔ)。從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法于敦德2006-3-16一、LiveJourna發(fā)展歷程LiveJournal是99年始于校園中的項(xiàng)目,幾個(gè)人出于愛好做了這樣一個(gè)應(yīng)用,以實(shí)現(xiàn)以下功能:博客,論壇社會(huì)性網(wǎng)絡(luò),找到朋友聚合,把朋友的文章聚合在一起LiveJournal采用了大量的開源軟件,甚至它本身也是一個(gè)開源軟件。在上線后,LiveJournal實(shí)現(xiàn)了非??焖俚脑鲩L(zhǎng):2004年4月份:280萬注冊(cè)用戶。2005年4月份:680萬注冊(cè)用戶。2005年8月份:790萬注冊(cè)用戶。達(dá)到了每秒鐘上千次的頁(yè)面請(qǐng)求及處理。使用了大量MySQL服務(wù)器。使用了大量通用組件。二、LiveJourna架構(gòu)現(xiàn)狀概況netweb4web4三、從LiveJournal展中學(xué)習(xí)LiveJournal從1臺(tái)服務(wù)器發(fā)展到100臺(tái)服務(wù)器,這其中經(jīng)歷了無數(shù)的傷痛,但同時(shí)也摸索出了解決這些問題的方法,通過對(duì)LiveJournal的學(xué)習(xí),可以讓我們避免LJ曾經(jīng)犯過的錯(cuò)誤,并且從一開始就對(duì)系統(tǒng)進(jìn)行良好的設(shè)計(jì),以避免后期的痛苦。下面我們一步一步看LJ發(fā)展的腳步。1、一臺(tái)服務(wù)器一臺(tái)別人捐助的服務(wù)器,LJ最初就跑在上面,就像Google開始時(shí)候用的破服務(wù)器一樣,值得我們尊敬。這個(gè)階段,LJ的人以驚人的速度熟悉的Unix的操作管理,服務(wù)器性能出現(xiàn)過問題,不過還好,可以通過一些小修小改應(yīng)付過去。在這個(gè)階段里L(fēng)J把CGI升級(jí)到了FastCGI。最終問題出現(xiàn)了,網(wǎng)站越來越慢,已經(jīng)無法通過優(yōu)過化來解決的地步,需要更多的服務(wù)器,這時(shí)LJ開始提供付費(fèi)服務(wù),可能是想通過這些錢來購(gòu)買新的服務(wù)器,以解決當(dāng)時(shí)的困境。毫無疑問,當(dāng)時(shí)LJ存在巨大的單點(diǎn)問題,所有的東西都在那臺(tái)服務(wù)器的鐵皮盒子里裝著。
2、兩臺(tái)服務(wù)器用付費(fèi)服務(wù)賺來的錢LJ買了兩臺(tái)服務(wù)器:一臺(tái)叫做Kenny的Dell6U機(jī)器用于提供Web服務(wù),一臺(tái)叫做Cartman的Dell6U服務(wù)器用于提供數(shù)據(jù)庫(kù)服務(wù)。、有了更大的磁盤,更多的計(jì)算資源。但同時(shí)網(wǎng)絡(luò)結(jié)構(gòu)還是非常簡(jiǎn)單,每臺(tái)機(jī)器兩塊網(wǎng)卡,Cartman通過內(nèi)網(wǎng)為Kenny提供MySQL數(shù)據(jù)庫(kù)服務(wù)。暫時(shí)解決了負(fù)載的問題,新的問題又出現(xiàn)了:原來的一個(gè)單點(diǎn)變成了兩個(gè)單點(diǎn)。沒有冷備份或熱備份。網(wǎng)站速度慢的問題又開始出現(xiàn)了,沒辦法,增長(zhǎng)太快了。Web服務(wù)器上CPU達(dá)到上限,需要更多的Web服務(wù)器。3、四臺(tái)服務(wù)器又買了兩臺(tái),Kyle和Stan,這次都是1U的,都用于提供Web服務(wù)。目前LJ一共有3臺(tái)Web服務(wù)器和一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。這時(shí)需要在3臺(tái)Web服務(wù)器上進(jìn)行負(fù)載均橫。
單點(diǎn)故障。數(shù)據(jù)庫(kù)和用于做網(wǎng)關(guān)的Web服務(wù)器都是單點(diǎn),一旦任何一臺(tái)機(jī)器出現(xiàn)問題將導(dǎo)致所有服務(wù)不可用。雖然用于做網(wǎng)關(guān)的Web服務(wù)器可以通過保持心跳同步迅速切換,但還是無法解決數(shù)據(jù)庫(kù)的單點(diǎn),LJ當(dāng)時(shí)也沒做這個(gè)。網(wǎng)站又變慢了,這次是因?yàn)镮O和數(shù)據(jù)庫(kù)的問題,問題是怎么往應(yīng)用里面添加數(shù)據(jù)庫(kù)呢?4、五臺(tái)服務(wù)器又買了一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。在兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上使用了數(shù)據(jù)庫(kù)同步(Mysql支持的Master-Slave模式),寫操作全部針對(duì)主數(shù)據(jù)庫(kù)(通過Binlog,主服務(wù)器上的寫操作可以迅速同步到從服務(wù)器上),讀操作在兩個(gè)數(shù)據(jù)庫(kù)上同時(shí)進(jìn)行(也算是負(fù)載均橫的一種吧)。讀操作數(shù)據(jù)庫(kù)選擇算法處理,要選一個(gè)當(dāng)前負(fù)載輕一點(diǎn)的數(shù)據(jù)庫(kù)。在從數(shù)據(jù)庫(kù)服務(wù)器上只能進(jìn)行讀操作
準(zhǔn)備好應(yīng)對(duì)同步過程中的延遲,處理不好可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)同步的中斷。只需要對(duì)寫操作進(jìn)行判斷即可,讀操作不存在同步問題。5、更多服務(wù)器有錢了,當(dāng)然要多買些服務(wù)器。部署后快了沒多久,又開始慢了。這次有更多的Web服務(wù)器,更多的數(shù)據(jù)庫(kù)服務(wù)器,存在IO與CPU爭(zhēng)用。于是采用了BIG-IP作為負(fù)載均衡解決方案。6、現(xiàn)在我們?cè)谀睦?net.現(xiàn)在服務(wù)器基本上夠了,但性能還是有問題,原因出在架構(gòu)上。數(shù)據(jù)庫(kù)的架構(gòu)是最大的問題。由于增加的數(shù)據(jù)庫(kù)都是以Slave模式添加到應(yīng)用內(nèi),這樣唯一的好處就是將讀操作分布到了多臺(tái)機(jī)器,但這樣帶來的后果就是寫操作被大量分發(fā),每臺(tái)機(jī)器都要執(zhí)行,服務(wù)器越多,浪費(fèi)就越大,隨著寫操作的增加,用于服務(wù)讀操作的資源越來越少。w/1server500w/1server500ready's200writ攻&由一臺(tái)分布到兩臺(tái)最終效果現(xiàn)在我們發(fā)現(xiàn),我們并不需要把這些數(shù)據(jù)在如此多的服務(wù)器上都保留一份。服務(wù)器上已經(jīng)做了RAID,數(shù)據(jù)庫(kù)也進(jìn)行了備份,這么多的備份完全是對(duì)資源的浪費(fèi),屬于冗余極端過度。那為什么不把數(shù)據(jù)分布存儲(chǔ)呢?最終效果問題發(fā)現(xiàn)了,開始考慮如何解決?,F(xiàn)在要做的就是把不同用戶的數(shù)據(jù)分布到不同的服務(wù)器上進(jìn)行存儲(chǔ),以實(shí)現(xiàn)數(shù)據(jù)的分布式存儲(chǔ),讓每臺(tái)機(jī)器只為相對(duì)固定的用戶服務(wù),以實(shí)現(xiàn)平行的架構(gòu)和良好的可擴(kuò)展性。為了實(shí)現(xiàn)用戶分組,我們需要為每一個(gè)用戶分配一個(gè)組標(biāo)記,用于標(biāo)記此用戶的數(shù)據(jù)存放在哪一組數(shù)據(jù)庫(kù)服務(wù)器中。每組數(shù)據(jù)庫(kù)由一個(gè)master及幾個(gè)slave組成,并且slave的數(shù)量在2-3臺(tái),以實(shí)現(xiàn)系統(tǒng)資源的最合理分配,既保證數(shù)據(jù)讀操作分布,又避免數(shù)據(jù)過度冗余以及同步操作對(duì)系統(tǒng)資源的過度消耗。,almostresemblestoday'sarchitecture豈心球/豈*fnsnd!1*由一臺(tái)(一組)中心服務(wù)器提供用戶分組控制。所有用戶的分組信息都存儲(chǔ)在這臺(tái)機(jī)器上,所有針對(duì)用戶的操作需要先查詢這臺(tái)機(jī)器得到用戶的組號(hào),然后再到相應(yīng)的數(shù)據(jù)庫(kù)組中獲取數(shù)據(jù)。這樣的用戶架構(gòu)與目前LJ的架構(gòu)已經(jīng)很相像了。在具體的實(shí)現(xiàn)時(shí)需要注意幾個(gè)問題:在數(shù)據(jù)庫(kù)組內(nèi)不要使用自增ID,以便于以后在數(shù)據(jù)庫(kù)組之間遷移用戶,以實(shí)現(xiàn)更合理的I/O,磁盤空間及負(fù)載分布。將userid,postid存儲(chǔ)在全局服務(wù)器上,可以使用自增,數(shù)據(jù)庫(kù)組中的相應(yīng)值必須以全局服務(wù)器上的值為)隹。全局服務(wù)器上使用事務(wù)型數(shù)據(jù)庫(kù)InnoDB。在數(shù)據(jù)庫(kù)組之間遷移用戶時(shí)要萬分小心,當(dāng)遷移時(shí)用戶不能有寫操作。7、現(xiàn)在我們?cè)谀睦飊et.GlobalDatabase問題:GlobalDatabase一個(gè)全局主服務(wù)器,掛掉的話所有用戶注冊(cè)及寫操作就掛掉。每個(gè)數(shù)據(jù)庫(kù)組一個(gè)主服務(wù)器,掛掉的話這組用戶的寫操作就掛掉。數(shù)據(jù)庫(kù)組從服務(wù)器掛掉的話會(huì)導(dǎo)致其它服務(wù)器負(fù)載過大。對(duì)于Master-Slave模式的單點(diǎn)問題,LJ采取了Master-Master模式來解決。所謂Master-Master實(shí)際上是人工實(shí)現(xiàn)的,并不是由MySQL直接提供的,實(shí)際上也就是兩臺(tái)機(jī)器同時(shí)是Master,也同時(shí)是Slave,互相同步。Master-Master實(shí)現(xiàn)時(shí)需要注意:一個(gè)Master出錯(cuò)后恢復(fù)同步,最好由服務(wù)器自動(dòng)完成。
數(shù)字分配,由于同時(shí)在兩臺(tái)機(jī)器上寫,有些ID可能會(huì)沖突。解決方案:奇偶數(shù)分配ID,一臺(tái)機(jī)器上寫奇數(shù),一臺(tái)機(jī)器上寫偶數(shù)通過全局服務(wù)器進(jìn)行分配(LJ采用的做法)。Master-Master模式還有一種用法,這種方法與前一種相比,仍然保持兩臺(tái)機(jī)器的同步,但只有一臺(tái)機(jī)器提供服務(wù)(讀和寫),在每天晚上的時(shí)候進(jìn)行輪換,或者出現(xiàn)問題的時(shí)候進(jìn)行切換。8、現(xiàn)在我們?cè)谀睦飊et.06Cl衍ter之現(xiàn)在插播一條廣告,MyISAMVSInnoDB使用InnoDB支持事務(wù)需要做更多的配置,不過值得,可以更安全的存儲(chǔ)數(shù)據(jù),以及得到更快的速度。06Cl衍ter之使用MyISAM:記錄日志(LJ用它來記網(wǎng)絡(luò)訪問日志)存儲(chǔ)只讀靜態(tài)數(shù)據(jù),足夠快。并發(fā)性很差,無法同時(shí)讀寫數(shù)據(jù)(添加數(shù)據(jù)可以)MySQL非正常關(guān)閉或死機(jī)時(shí)會(huì)導(dǎo)致索引錯(cuò)誤,需要使用myisamchk修復(fù),而且當(dāng)訪問量大時(shí)出現(xiàn)非常頻繁。9、緩存去年我寫過一篇文章介紹memcached,它就是由LJ的團(tuán)隊(duì)開發(fā)的一款緩存工具,以key-value的方式將數(shù)據(jù)存儲(chǔ)到分布的內(nèi)存中。LJ緩存的數(shù)據(jù):12臺(tái)獨(dú)立服務(wù)器(不是捐贈(zèng)的)28個(gè)實(shí)例30GB總?cè)萘?0-93%的命中率(用過squid的人可能知道,squid內(nèi)存加磁盤的命中率大概在70-80%)如何建立緩存策略?想緩存所有的東西?那是不可能的,我們只需要緩存已經(jīng)或者可能導(dǎo)致系統(tǒng)瓶頸的地方,最大程度的提交系統(tǒng)運(yùn)行效率。通過對(duì)MySQL的日志的分析我們可以找到緩存的對(duì)象。緩存的缺點(diǎn)?沒有完美的事物,緩存也有缺點(diǎn):增大開發(fā)量,需要針對(duì)緩存處理編寫特殊的代碼。管理難度增加,需要更多人參與系統(tǒng)維護(hù)。當(dāng)然大內(nèi)存也需要錢。10、Web訪問負(fù)載均衡在數(shù)據(jù)包級(jí)別使用BIG-IP,但BIG-IP并不知道我們內(nèi)部的處理機(jī)制,無法判斷由哪臺(tái)服務(wù)器對(duì)這些請(qǐng)求進(jìn)行處理。反向代理并不能很好的起到作用,不是已經(jīng)夠快了,就是達(dá)不到我們想要的效果。所以,1丁又開發(fā)了Perlbal。特點(diǎn):快,小,可管理的httpweb服務(wù)器/代理可以在內(nèi)部進(jìn)行轉(zhuǎn)發(fā)使用Perl開發(fā)單線程,異步,基于事件,使用epoll,kqueue支持Console管理與http遠(yuǎn)程管理,支持動(dòng)態(tài)配置加載多種模式:web服務(wù)器,反向代理,插件支持插件:GIF/PNG互換?11、MogileFSLJ使用開源的MogileFS作為分布式文件存儲(chǔ)系統(tǒng)。MogileFS使用非常簡(jiǎn)單,它的主要設(shè)計(jì)思想是:文件屬于類(類是最小的復(fù)制單位)跟蹤文件存儲(chǔ)位置在不同主機(jī)上存儲(chǔ)使用MySQL集群統(tǒng)一存儲(chǔ)分布信息大容易廉價(jià)磁盤/words/找到。D到目前為止就這么多了,更多文檔可以在和LiveJ的同學(xué)們拿這個(gè)文檔參加了兩次MySQLCon,兩次OSCon,以及眾多的其它會(huì)議,無私的把他們的經(jīng)驗(yàn)分享出來,值得我們學(xué)習(xí)。在web2.0時(shí)代快速開發(fā)得到大家越來越多的重視,但良好的設(shè)計(jì)仍是每一個(gè)應(yīng)用的基礎(chǔ),希望web2.0們?cè)诔砷L(zhǎng)為Top500網(wǎng)站的路上,不要因?yàn)榧軜?gòu)阻礙了網(wǎng)站的發(fā)展。/words/找到。D大型Web2.0站點(diǎn)構(gòu)建技術(shù)初探大型Web2.0站點(diǎn)構(gòu)建技術(shù)初探一、web2.0網(wǎng)站常用可用性功能模塊分析二、Flickr的幕后故事三、YouTube的架構(gòu)擴(kuò)展四、mixi.jp:使用開源軟件搭建的可擴(kuò)展SNS網(wǎng)站五、Technorati的后臺(tái)數(shù)據(jù)庫(kù)架構(gòu)六、通過了解MySpace的六次重構(gòu)經(jīng)歷,來認(rèn)識(shí)分布式系統(tǒng)到底該如何創(chuàng)建七、從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法八、說說大型高并發(fā)高負(fù)載網(wǎng)站的系統(tǒng)架構(gòu)一、web2.0網(wǎng)站常用可用性功能模塊分析Web2.0網(wǎng)站是指將傳統(tǒng)的網(wǎng)站構(gòu)架(平臺(tái)、內(nèi)容源、用戶、傳播方式等)轉(zhuǎn)化到以用戶為核心的網(wǎng)站構(gòu)架上來,包括一系列體現(xiàn)web2.0概念的元素、定位和創(chuàng)意°web2.0網(wǎng)站在構(gòu)架上須體現(xiàn)兩大宗旨,即強(qiáng)大的后臺(tái)系統(tǒng)和簡(jiǎn)單的前臺(tái)頁(yè)面,也即提供良好的用戶體驗(yàn),體現(xiàn)以人為本,技術(shù)服務(wù)人類的宗旨。web2.0網(wǎng)站常用功能塊通常包括以下幾大項(xiàng):Tag標(biāo)簽功能塊Tag(中文叫做''標(biāo)簽”)是一種新的組織和管理在線信息的方式。它不同于傳統(tǒng)的、針對(duì)文件本身的關(guān)鍵字檢索,而是一種模糊化、智能化的分類。網(wǎng)頁(yè)使用Tag標(biāo)簽的好處:為頁(yè)面設(shè)置一個(gè)或者多個(gè)Tag標(biāo)簽可以引導(dǎo)讀者閱讀更多相關(guān)文章,為別人帶去流量同理也為自己帶來流量。可以幫助讀者及時(shí)了解一些未知的概念和知識(shí)點(diǎn),提高用戶體驗(yàn)。Tag是人的意志和趨向的體現(xiàn),Tag可以幫助你找到興趣相投的人?;谝陨蟽?yōu)勢(shì),Tag標(biāo)簽代替了傳統(tǒng)的分類法,成為web2.0網(wǎng)站使用率最高的功能塊(與其說是功能塊倒不如說是一種內(nèi)容導(dǎo)航和內(nèi)容組織形式)。一句話:Tag標(biāo)簽是一種更靈活的分類方法,功能在于引導(dǎo),特點(diǎn)是無處不在,體現(xiàn)智能性、模糊性和趨向性。RSS訂閱功能塊RSS是在線共享內(nèi)容的一種簡(jiǎn)易方式(也叫聚合內(nèi)容,ReallySimpleSyndication)。通常在時(shí)效性比較強(qiáng)的內(nèi)容上使用RSS訂閱能更快速獲取信息,網(wǎng)站提供RSS輸出,有利于讓用戶獲取網(wǎng)站內(nèi)容的最新更新。網(wǎng)絡(luò)用戶可以在客戶端借助于支持RSS的聚合工具軟件(例如SharpReader,NewzCrawler、FeedDemon),在不打開網(wǎng)站內(nèi)容頁(yè)面的情況下閱讀支持RSS輸出的網(wǎng)站內(nèi)容。RSS訂閱的方式:訂閱到客戶端軟件如周伯通、遨游瀏覽器RSS閱讀、FoxmailRSS閱讀等,此方式使用者較多訂閱到在線閱讀(聚合類)門戶網(wǎng)站如GoogleReader,YahooReader,抓蝦、Gougou等,省去了安裝RSS閱讀器的麻煩訂閱到在線單用戶聚合器如Lilina等,比較靈活RSS訂閱功能的最大好處是定向投遞,也就是說RSS機(jī)制更能體現(xiàn)用戶的意愿和個(gè)性,獲取信息的方式也最直接和簡(jiǎn)單,這是RSS訂閱功能備受青睞的一大主要原因。推薦和收藏功能塊說到推薦功能,不僅web2.0網(wǎng)站在大量使用,傳統(tǒng)的以cms平臺(tái)為代表的內(nèi)容模式的網(wǎng)站也在大量使用,推薦功能主要是指向一些網(wǎng)摘或者聚合類門戶網(wǎng)站推薦自己所瀏覽到的網(wǎng)頁(yè)。當(dāng)然,一種變相的推薦就是閱讀者的自我收藏行為,在共享的模式下也能起到推薦的作用。比較有名的推薦目標(biāo)有以del.icio.us為代表的網(wǎng)摘類網(wǎng)站包括國(guó)內(nèi)比較有名氣的365key、和訊網(wǎng)摘、新浪vivi天極網(wǎng)摘等。這里值得一提的是前段時(shí)間曾涌現(xiàn)了大批網(wǎng)摘類網(wǎng)站,但他們堅(jiān)持活下來的好像沒有幾個(gè)了,推薦使用前面提到的這幾個(gè)網(wǎng)摘門戶,人氣基本上是使最旺的。評(píng)論和留言功能塊web2.0強(qiáng)調(diào)參與性,強(qiáng)調(diào)發(fā)揮用戶的主導(dǎo)作用,這里的參與性除了所謂的訂閱、推薦功能外更多地體現(xiàn)在用戶對(duì)內(nèi)容的評(píng)價(jià)和態(tài)度,這就要靠評(píng)論功能塊來完成。一個(gè)典型的web2.0網(wǎng)站或者說一個(gè)能體現(xiàn)人氣的web2.0網(wǎng)站都會(huì)花大量篇幅來體現(xiàn)用戶的觀點(diǎn)和視覺。這里尤其要提到web2.0中的帶頭老大webblog,評(píng)論功能已經(jīng)成為博客主人與瀏覽者交流的主要陣地,是體現(xiàn)網(wǎng)站人氣的最直觀因素。評(píng)論功能塊應(yīng)用在博客系統(tǒng)中實(shí)際上已經(jīng)和博客內(nèi)容相分離,而更好的應(yīng)用恰恰是一些以點(diǎn)評(píng)為主的web2.0網(wǎng)站比如豆瓣、點(diǎn)評(píng)網(wǎng)等,這里的評(píng)論功能塊直接制造了內(nèi)容也極大地體現(xiàn)了網(wǎng)站的人氣,所以說評(píng)論功能塊是web2.0網(wǎng)站最有力的武器。站內(nèi)搜索功能塊搜索是信息來源最直接的方式之一,無論你的網(wǎng)站是否打上web2.0的烙印,搜索對(duì)于一個(gè)體系龐大、內(nèi)容豐富的大型網(wǎng)站都是非常必要的。Tag標(biāo)簽在某種程度上起到搜索的作用,它能夠有效聚合以此Tag為關(guān)鍵伺的內(nèi)容,但這種情況的前提是此Tag標(biāo)簽對(duì)瀏覽者是可見的,也就是說當(dāng)Tag標(biāo)簽擺在瀏覽者的眼前時(shí)才成立,而對(duì)于那些瀏覽者想要的信息卻沒有Tag標(biāo)簽來引導(dǎo)時(shí)搜索就是達(dá)到此目的的最好方法。對(duì)于web2.0網(wǎng)站,站內(nèi)搜索以標(biāo)題或者Tag為搜索域都能起到好的效果,但本人不建議使用內(nèi)容搜索域,因?yàn)檫@不符合搜索的高效性原則。同時(shí),具有突出關(guān)鍵伺的內(nèi)容往往都可以用Tag標(biāo)簽來引導(dǎo),因此使用內(nèi)容域來搜索實(shí)際上是一種浪費(fèi)服務(wù)器資源的行為,而且搜索結(jié)果的準(zhǔn)確性將大打折扣。群組功能塊我為什么要把群組作為web2.0網(wǎng)站的功能塊來分析呢,因?yàn)槿航M是web2.0網(wǎng)站的一大特點(diǎn),也是web2.0所要體現(xiàn)的服務(wù)宗旨所在。一個(gè)web2.0網(wǎng)站,博客也好、播客也好、點(diǎn)評(píng)也好,抑或是網(wǎng)摘、聚合門戶,他們都強(qiáng)調(diào)人的參與性。物以類聚、人以群分,每個(gè)參與者都有自己的興趣趨向,web2.0網(wǎng)站的另一主要功能就是幫助這些人找到同樣興趣的人并形成一個(gè)活躍的群體,這是web2.0網(wǎng)站的根本??偨Y(jié):web2.0網(wǎng)站倡導(dǎo)的是集體創(chuàng)作、共享資源,靠的是人氣,體現(xiàn)的是參與性,一個(gè)沒有參與性的web2.0網(wǎng)站都不足以成為web2.0。以上提到的這幾個(gè)功能塊就是以吸引用戶參與和引導(dǎo)用戶參與為目的的,真正的web2.0不是什么深?yuàn)W的東西,只有一點(diǎn),那就是如何讓瀏覽者沸騰起來。二、Flickr的幕后故事我們都看到Flickr的成功,而又有多少"精英”們了解過Flickr背后的過程是多么充滿艱險(xiǎn)。Flickr是全CGI的動(dòng)態(tài)構(gòu)架,并以一種.gne的腳本作為CGI程序語言。不管網(wǎng)站制作菜鳥還是高手都會(huì)疑惑:gne是哪種程序語言?答案:gne不是一種語言,F(xiàn)lickr是以極為經(jīng)典的PHP+MySQL方式實(shí)現(xiàn)的,在被Yahoo收購(gòu)服務(wù)器搬入美國(guó)之前,使用了21臺(tái)(01-121)Apache/PHP做Web、23臺(tái)圖片服務(wù)器、另有MySQL服務(wù)器組成的數(shù)據(jù)庫(kù)集群的服務(wù)器數(shù)量未知?,F(xiàn)在估計(jì)使用的是Yahoo的負(fù)載均衡系統(tǒng),對(duì)外只有一個(gè)Web的IP和圖片服務(wù)器的IP了。那為何.php的文件要改成.gne呢?以往有大型網(wǎng)站為向后兼容性考慮,隱藏以程序語言命名的腳本文件擴(kuò)展名,比如Baidu隱藏了.php(Google的http服務(wù)器是自己寫的,整合了腳本程序,個(gè)別頁(yè)面是.py--Python);還有一些網(wǎng)站是改成自己網(wǎng)站名相關(guān)的擴(kuò)展名,如MSN的群組則是.msnw,榕樹下是.rs。那Flickr的gne是什么意思?我在維基百科的Flickr條目上找到了答案(中文Flickr條目上沒有寫明)。原來GNE是GameNeverEnding的縮寫,F(xiàn)lickr的開發(fā)者Ludicorp在2002-2004年一直在開發(fā)這套以GameNerverEnding為名稱的大型多人在線角色扮演游戲-一套基于瀏覽器的Web游戲系統(tǒng),個(gè)人以為應(yīng)該就是當(dāng)年九城的虛擬城市。但是開發(fā)近3年后該計(jì)劃不得不破產(chǎn),最終只發(fā)布了一個(gè)Beta版,而Ludicorp將這套系統(tǒng)稍加移植,就有了Flickr呵呵,原來gne是一個(gè)項(xiàng)目的名稱。關(guān)于GNE的一些連接:http://del.icio.us/schee/gneo早期的Flickr想做成在類似聊天室的地方讓網(wǎng)友分享、交流自己的照片,注重社區(qū)形式和保護(hù)照片不被外部引用(見徐子涵2004年的文章),可能是看到了Hello的模式吧。但是聰明的Flickr團(tuán)隊(duì)不以就改變了策略,淡化了傳統(tǒng)的社區(qū)形式--如聊天室、而加強(qiáng)了現(xiàn)在使其功成名就的Tag組織形式,一種更自由更隨興更輕松好玩的大社區(qū)形式,或者叫它廣義社區(qū)吧,我隨便叫的,可能太學(xué)究,看著別太在意就是了。另外,將原來照片只能在Flash內(nèi)瀏覽的限制區(qū)除了,并大力推薦用戶將照片引用到自己的Blog,這無疑對(duì)于挑戰(zhàn)傳統(tǒng)相冊(cè)系統(tǒng)有決定性意義。減少Flash后的網(wǎng)頁(yè)更多地引進(jìn)了新興的Ajax技術(shù),使界面操作變得非常Cool。這就是Flickr的歷史,清晰地看到了他們對(duì)于優(yōu)秀產(chǎn)品的執(zhí)著。有了技術(shù)和經(jīng)驗(yàn)積累,加上不斷堅(jiān)持,總有一天時(shí)來運(yùn)轉(zhuǎn),你的產(chǎn)品會(huì)成為新潮流的里程碑。還有一句話要告訴Yupoo等:把Flickr想成一個(gè)有Tag功能的在線相冊(cè)就已經(jīng)錯(cuò)遠(yuǎn)了;復(fù)制粘貼者們想當(dāng)然將Flickr去其糟粕取其精華,結(jié)果無關(guān)緊要的拿來了,將令人激動(dòng)的優(yōu)點(diǎn)都去掉了,結(jié)果剩下什么?三、YouTube的架構(gòu)擴(kuò)展在西雅圖擴(kuò)展性的技術(shù)研討會(huì)上,YouTube的CuongDo做了關(guān)于YouTubeScalability的報(bào)告。視頻內(nèi)容在GoogleVideo上有(地址),可惜國(guó)內(nèi)用戶看不到。KyleCordes對(duì)這個(gè)視頻中的內(nèi)容做了介紹。里面有不少技術(shù)性的內(nèi)容。值得分享一下。(KyleCordes的介紹是本文的主要來源)簡(jiǎn)單的說YouTube的數(shù)據(jù)流量,一天的YouTube流量相當(dāng)于發(fā)送750億封電子郵件.",2006年中就有消息說每日PV超過1億,現(xiàn)在?更夸張了,〃每天有10億次下載以及6,5000次上傳",真假姑且不論,的確是超乎尋常的海量.國(guó)內(nèi)的互聯(lián)網(wǎng)應(yīng)用,但從數(shù)據(jù)量來看,怕是只有51.com有這個(gè)規(guī)模.但技術(shù)上和YouTube就沒法子比了.Web服務(wù)器YouTube出于開發(fā)速度的考慮,大部分代碼都是Python開發(fā)的。Web服務(wù)器有部分是Apache,用FastCGI模式。對(duì)于視頻內(nèi)容則用Lighttpd。據(jù)我所知,MySpace也有部分服務(wù)器用Lighttpd,但量不大。YouTube是Lighttpd最成功的案例。(國(guó)內(nèi)用Lighttpd站點(diǎn)不多,豆瓣用的比較舒服。byFenng)視頻視頻的縮略圖(Thumbnails)給服務(wù)器帶來了很大的挑戰(zhàn)。每個(gè)視頻平均有4個(gè)縮略圖,而每個(gè)Web頁(yè)面上更是有多個(gè),每秒鐘因?yàn)檫@個(gè)帶來的磁盤IO請(qǐng)求太大。YouTube技術(shù)人員啟用了單獨(dú)的服務(wù)器群組來承擔(dān)這個(gè)壓力,并且針對(duì)Cache和OS做了部分優(yōu)化。另一方面,縮略圖請(qǐng)求的壓力導(dǎo)致Lighttpd性能下降。通過HackLighttpd增加更多的worker線程很大程度解決了問題。而最新的解決方案是起用了Google的BigTable,這下子從性能、容錯(cuò)、緩存上都有更好表現(xiàn)。看人家這收購(gòu)的,好鋼用在了刀刃上。出于冗余的考慮,每個(gè)視頻文件放在一組迷你Cluster上,所謂"迷你Cluster"就是一組具有相同內(nèi)容的服務(wù)器。最火的視頻放在CDN上,這樣自己的服務(wù)器只需要承擔(dān)一些"漏網(wǎng)”的隨即訪問即可。YouTube使用簡(jiǎn)單、廉價(jià)、通用的硬件,這一點(diǎn)和Google風(fēng)格倒是一致。至于維護(hù)手段,也都是常見的工具,如rsync,SSH等,只不過人家更手熟罷了。數(shù)據(jù)庫(kù)YouTube用MySQL存儲(chǔ)元數(shù)據(jù)--用戶信息、視頻信息什么的。數(shù)據(jù)庫(kù)服務(wù)器曾經(jīng)一度遇到SWAP顛簸的問題,解決辦法是刪掉了SWAP分區(qū)!管用。最初的DB只有10塊硬盤,RAID10,后來追加了一組RAID1。夠省的。這一波Web2.0公司很少有用Oracle的(我知道的只有Bebo,參見這里).在擴(kuò)展性方面,路線也是和其他站點(diǎn)類似,復(fù)制,分散IO。最終的解決之道是"分區(qū)",這個(gè)不是數(shù)據(jù)庫(kù)層面的表分區(qū),而是業(yè)務(wù)層面的分區(qū)(在用戶名字或者ID上做文章,應(yīng)用程序控制查找機(jī)制)YouTube也用Memcached.很想了解一下國(guó)內(nèi)Web2.0網(wǎng)站的數(shù)據(jù)信息,有誰可以提供一點(diǎn)?四、mixi.jp:使用開源軟件搭建的可擴(kuò)展SNS網(wǎng)站Mixi目前是日本排名第三的網(wǎng)站,全球排名42,主要提供SNS服務(wù):日記,群組,站內(nèi)消息,評(píng)論,相冊(cè)等等,是日本最大的SNS網(wǎng)站°Mixi從2003年12月份開始開發(fā),由現(xiàn)在它的CTO-BataraKesuma一個(gè)人焊,焊了四個(gè)月,在2004年2月份開始上線運(yùn)行。兩個(gè)月后就注冊(cè)了1w用戶,日訪問量60wPV。在隨后的一年里,用戶增長(zhǎng)到了21w,第二年,增長(zhǎng)到了200w。到今年四月份已經(jīng)增長(zhǎng)到370w注冊(cè)用戶,并且還在以每天1.5w人的注冊(cè)量增長(zhǎng)。這些用戶中70%是活躍用戶(活躍用戶:三天內(nèi)至少登錄一次的用戶),平均每個(gè)用戶每周在線時(shí)間為將近3個(gè)半小時(shí)。下面我們來看它的技術(shù)架構(gòu)。Mixi采用開源軟件作為架構(gòu)的基礎(chǔ):Linux2.6,Apache2.0,MySQL,Perl5.8,memcached,Squid等等。到目前為止已經(jīng)有100多臺(tái)MySQL數(shù)據(jù)庫(kù)服務(wù)器,并且在以每月10多臺(tái)的速度增長(zhǎng)。Mix1的數(shù)據(jù)庫(kù)連接方式采用的是每次查詢都進(jìn)行連接,而不是持久連接。數(shù)據(jù)庫(kù)大多數(shù)是以InnoDB方式運(yùn)行。Mixi解決擴(kuò)展問題主要依賴于對(duì)數(shù)據(jù)庫(kù)的切分。首先進(jìn)行垂直切分,按照表的內(nèi)容將不同的表劃分到不同的數(shù)據(jù)庫(kù)中。然后是水平切分,根據(jù)用戶的ID將不同用戶的內(nèi)容再劃分的不同的數(shù)據(jù)庫(kù)中,這是比較通常的做法,也很管用。劃分的關(guān)鍵還是在于應(yīng)用中的實(shí)現(xiàn),需要將操作封裝在在數(shù)據(jù)層,而盡量不影響業(yè)務(wù)層。當(dāng)然完全不改變邏輯層也不可能,這時(shí)候最能檢驗(yàn)以前的設(shè)計(jì)是否到位,如果以前設(shè)計(jì)的不錯(cuò),那創(chuàng)建連接的時(shí)候傳個(gè)表名,用戶ID進(jìn)去差不多就解決問題了,而以前如果sql代碼到處飛,或者數(shù)據(jù)層封裝的不太好的話那就累了。這樣做了以后并不能從根本上解決問題,尤其是對(duì)于像mixi這種SNS網(wǎng)站,頁(yè)面上往往需要引用大量的用戶信息,好友信息,圖片,文章信息,跨表,跨庫(kù)操作相當(dāng)多。這個(gè)時(shí)候就需要發(fā)揮memcached的作用了,用大內(nèi)存把這些不變的數(shù)據(jù)全都緩存起來,而當(dāng)修改時(shí)就通知cache過期,這樣應(yīng)用層基本上就可以解決大部分問題了,只會(huì)有很小一部分請(qǐng)求穿透應(yīng)用層,用到數(shù)據(jù)庫(kù)。Mix1的經(jīng)驗(yàn)是平均每個(gè)頁(yè)面的加載時(shí)間在0.02秒左右(當(dāng)然根據(jù)頁(yè)面大小情)兄不盡相似),可以說明這種做法是行之有效的。Mixi-共在32臺(tái)機(jī)器上有緩存服務(wù)器,每個(gè)CacheServer2G內(nèi)存,這些CacheServer與AppServer裝在一起。因?yàn)镃acheServer對(duì)CPU消耗不大,而有了CacheServer的支援,AppServer對(duì)內(nèi)存要求也不是太高,所以可以和平共處,更有效的利用資源。圖片的處理就顯得相對(duì)簡(jiǎn)單的多了。對(duì)于mixi而言,圖像主要有兩部分:一部分是經(jīng)常要使用到的,像用戶頭像,群組的頭像等等,大概有100多GB,它們被Squid和CDN所緩存,命中率相對(duì)比較高;另一部分是用戶上傳的大量照片,它們的個(gè)體訪問量相對(duì)而言比較小,命中率也比較低,使用Cache不劃算,所以對(duì)于這些照片的策略是直接在用戶上傳的時(shí)候分發(fā)到到圖片存儲(chǔ)服務(wù)器上,在用戶訪問的時(shí)候直接進(jìn)行訪問,當(dāng)然圖片的位置需要在數(shù)據(jù)庫(kù)中進(jìn)行記錄,不然找不到放在哪臺(tái)服務(wù)器上就郁悶了。五、Technorati的后臺(tái)數(shù)據(jù)庫(kù)架構(gòu)Technorati現(xiàn)在被阻尼了,可能你訪問不了)的DorionCarroll在2006MySQL用戶會(huì)議上介紹了一些關(guān)于Technorati后臺(tái)數(shù)據(jù)庫(kù)架構(gòu)的情)兄.基本情況目前處理著大約10Tb核心數(shù)據(jù),分布在大約20臺(tái)機(jī)器上.通過復(fù)制,多增加了100Tb數(shù)據(jù),分布在200臺(tái)機(jī)器上.每天增長(zhǎng)的數(shù)據(jù)1TB.通過SOA的運(yùn)用,物理與邏輯的訪問相隔離,似乎消除了數(shù)據(jù)庫(kù)的瓶頸.值得一提的是,該擴(kuò)展過程始終是利用普通的硬件與開源軟件來完成的.畢竟,Web2.0站點(diǎn)都不是燒錢的主.從數(shù)據(jù)量來看,這絕對(duì)是一個(gè)相對(duì)比較大的Web2.0應(yīng)用.Tag是Technorati最為重要的數(shù)據(jù)元素.爆炸性的Tag增長(zhǎng)給Technorati帶來了不小的挑戰(zhàn).2005年1月的時(shí)候,只有兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器,一主一從.到了06年一月份,已經(jīng)是一主一從,6臺(tái)MylSAM從數(shù)據(jù)庫(kù)用來對(duì)付查詢,3臺(tái)MylSAM用作異步計(jì)算.一些核心的處理方法:1)根據(jù)實(shí)體(tags/posttags))進(jìn)行分區(qū)衡量數(shù)據(jù)訪問方法,讀和寫的平衡.然后通過不同的維度進(jìn)行分區(qū).(Technorati數(shù)據(jù)更新不會(huì)很多,否則會(huì)成為數(shù)據(jù)庫(kù)災(zāi)難)2)合理利用InnoDB與MylSAMInnoDB用于數(shù)據(jù)完整性/寫性能要求比較高的應(yīng)用.MylSAM適合進(jìn)行OLAP運(yùn)算.物盡其用.3)MySQL復(fù)制復(fù)制數(shù)據(jù)到從主數(shù)據(jù)庫(kù)到輔數(shù)據(jù)庫(kù)上,平衡分布查詢與異步計(jì)算,另外一個(gè)功能是提供冗余.如圖:六、通過了解MySpace的六次重構(gòu)經(jīng)歷,來認(rèn)識(shí)分布式系統(tǒng)到底該如何創(chuàng)建.在每個(gè)里程碑,站點(diǎn)負(fù)擔(dān)都會(huì)超過底層系統(tǒng)部分組件的最大載荷,特別是數(shù)據(jù)庫(kù)和存儲(chǔ)系統(tǒng)。接著,功能出現(xiàn)問題,用戶失聲尖叫。最后,技術(shù)團(tuán)隊(duì)必須為此修訂系統(tǒng)策略。雖然自2005年早期,站點(diǎn)賬戶數(shù)超過7百萬后,系統(tǒng)架構(gòu)到目前為止保持了相對(duì)穩(wěn)定,但MySpace仍然在為SQLServer支持的同時(shí)連接數(shù)等方面繼續(xù)攻堅(jiān),Benedetto說,"我們已經(jīng)盡可能把事情做到最好”。里程碑一:50萬賬戶按Benedetto的說法,MySpace最初的系統(tǒng)很小,只有兩臺(tái)Web服務(wù)器和一個(gè)數(shù)據(jù)庫(kù)服務(wù)器。那時(shí)使用的是Dell雙CPU、4G內(nèi)存的系統(tǒng)。單個(gè)數(shù)據(jù)庫(kù)就意味著所有數(shù)據(jù)都存儲(chǔ)在一個(gè)地方,再由兩臺(tái)Web服務(wù)器分擔(dān)處理用戶請(qǐng)求的工作量。但就像MySpace后來的幾次底層系統(tǒng)修訂時(shí)的情況一樣,三服務(wù)器架構(gòu)很快不堪重負(fù)。此后一個(gè)時(shí)期內(nèi),MySpace基本是通過添置更多Web服務(wù)器來對(duì)付用戶暴增問題的。但到在2004年早期,MySpace用戶數(shù)增長(zhǎng)到50萬后,數(shù)據(jù)庫(kù)服務(wù)器也已開始汗流泱背。但和Web服務(wù)器不同,增加數(shù)據(jù)庫(kù)可沒那么簡(jiǎn)單。如果一個(gè)站點(diǎn)由多個(gè)數(shù)據(jù)庫(kù)支持,設(shè)計(jì)者必須考慮的是,如何在保證數(shù)據(jù)一致性的前提下,讓多個(gè)數(shù)據(jù)庫(kù)分擔(dān)壓力。在第二代架構(gòu)中,MySpace運(yùn)行在3個(gè)SQLServer數(shù)據(jù)庫(kù)服務(wù)器上-一個(gè)為主,所有的新數(shù)據(jù)都向它提交,然后由它復(fù)制到其他兩個(gè);另兩個(gè)全力向用戶供給數(shù)據(jù),用以在博客和個(gè)人資料欄顯示。這種方式在一段時(shí)間內(nèi)效果很好--只要增加數(shù)據(jù)庫(kù)服務(wù)器,加大硬盤,就可以應(yīng)對(duì)用戶數(shù)和訪問量的增加。里程碑二:1-2百萬賬戶MySpace注冊(cè)數(shù)到達(dá)1百萬至2百萬區(qū)間后,數(shù)據(jù)庫(kù)服務(wù)器開始受制于I/O容量-■即它們存取數(shù)據(jù)的速度。而當(dāng)時(shí)才是2004年中,距離上次數(shù)據(jù)庫(kù)系統(tǒng)調(diào)整不過數(shù)月。用戶的提交請(qǐng)求被阻塞,就像千人樂迷要擠進(jìn)只能容納幾百人的夜總會(huì),站點(diǎn)開始遭遇''主要矛盾”,Benedetto說,這意味著MySpace永遠(yuǎn)都會(huì)輕度落后于用戶需求。"有人花5分鐘都無法完成留言,因此用戶總是抱怨說網(wǎng)站已經(jīng)完蛋了。"他補(bǔ)充道。這一次的數(shù)據(jù)庫(kù)架構(gòu)按照垂直分割模式設(shè)計(jì),不同的數(shù)據(jù)庫(kù)服務(wù)于站點(diǎn)的不同功能,如登錄、用戶資料和博客。于是,站點(diǎn)的擴(kuò)展性問題看似又可以告一段落了,可以歇一陣子。垂直分割策略利于多個(gè)數(shù)據(jù)庫(kù)分擔(dān)訪問壓力,當(dāng)用戶要求增加新功能時(shí),MySpace將投入新的數(shù)據(jù)庫(kù)予以支持它。賬戶到達(dá)2百萬后,MySpace還從存儲(chǔ)設(shè)備與數(shù)據(jù)庫(kù)服務(wù)器直接交互的方式切換到SAN(StorageAreaNetwork,存儲(chǔ)區(qū)域網(wǎng)絡(luò))--用高帶寬、專門設(shè)計(jì)的網(wǎng)絡(luò)將大量磁盤存儲(chǔ)設(shè)備連接在一起,而數(shù)據(jù)庫(kù)連接到SAN。這項(xiàng)措施極大提升了系統(tǒng)性能、正常運(yùn)行時(shí)間和可靠性,Benedetto說。里程碑三:3百萬賬戶當(dāng)用戶繼續(xù)增加到3百萬后,垂直分割策略也開始難以為繼。盡管站點(diǎn)的各個(gè)應(yīng)用被設(shè)計(jì)得高度獨(dú)立,但有些信息必須共享。在這個(gè)架構(gòu)里,每個(gè)數(shù)據(jù)庫(kù)必須有各自的用戶表副本--MySpace授權(quán)用戶的電子花名冊(cè)。這就意味著一個(gè)用戶注冊(cè)時(shí),該條賬戶記錄必須在9個(gè)不同數(shù)據(jù)庫(kù)上分別創(chuàng)建。但在個(gè)別情)兄下,如果其中某臺(tái)數(shù)據(jù)庫(kù)服務(wù)器臨時(shí)不可到達(dá),對(duì)應(yīng)事務(wù)就會(huì)失敗,從而造成賬戶非完全創(chuàng)建,最終導(dǎo)致此用戶的該項(xiàng)服務(wù)無效。另外一個(gè)問題是,個(gè)別應(yīng)用如博客增長(zhǎng)太快,那么專門為它服務(wù)的數(shù)據(jù)庫(kù)就有巨大壓力。2004年中,MySpace面臨Web開發(fā)者稱之為"向上擴(kuò)展"對(duì)"向外擴(kuò)展”(譯者注:ScaleUp和ScaleOut,也稱硬件擴(kuò)展和軟件擴(kuò)展)的抉擇一要么擴(kuò)展到更大更強(qiáng)、也更昂貴的服務(wù)器上,要么部署大量相對(duì)便宜的服務(wù)器來分擔(dān)數(shù)據(jù)庫(kù)壓力。一般來說,大型站點(diǎn)傾向于向外擴(kuò)展,因?yàn)檫@將讓它們得以保留通過增加服務(wù)器以提升系統(tǒng)能力的后路。但成功地向外擴(kuò)展架構(gòu)必須解決復(fù)雜的分布式計(jì)算問題,大型站點(diǎn)如Google、Yahoo和A,都必須自行研發(fā)大量相關(guān)技術(shù)。以Google為例,它構(gòu)建了自己的分布式文件系統(tǒng)。另外,向外擴(kuò)展策略還需要大量重寫原來軟件,以保證系統(tǒng)能在分布式服務(wù)器上運(yùn)行。"搞不好,開發(fā)人員的所有工作都將白費(fèi)”,Benedetto說。因此,MySpace首先將重點(diǎn)放在了向上擴(kuò)展上,花費(fèi)了大約1個(gè)半月時(shí)間研究升級(jí)到32CPU服務(wù)器以管理更大數(shù)據(jù)庫(kù)的問題。Benedetto說,”那時(shí)候,這個(gè)方案看似可能解決一切問題。”如穩(wěn)定性,更棒的是對(duì)現(xiàn)有軟件幾乎沒有改動(dòng)要求。糟糕的是,高端服務(wù)器極其昂貴,是購(gòu)置同樣處理能力和內(nèi)存速度的多臺(tái)服務(wù)器總和的很多倍。而且,站點(diǎn)架構(gòu)師預(yù)測(cè),從長(zhǎng)期來看,即便是巨型數(shù)據(jù)庫(kù),最后也會(huì)不堪重負(fù),Benedetto說,”換句話講,只要增長(zhǎng)趨勢(shì)存在,我們最后無論如何都要走上向外擴(kuò)展的道路?!币虼?,MySpace最終將目光移到分布式計(jì)算架構(gòu)一它在物理上分布的眾多服務(wù)器,整體必須邏輯上等同于單臺(tái)機(jī)器。拿數(shù)據(jù)庫(kù)來說,就不能再像過去那樣將應(yīng)用拆分,再以不同數(shù)據(jù)庫(kù)分別支持,而必須將整個(gè)站點(diǎn)看作一個(gè)應(yīng)用?,F(xiàn)在,數(shù)據(jù)庫(kù)模型里只有一個(gè)用戶表,支持博客、個(gè)人資料和其他核心功能的數(shù)據(jù)都存儲(chǔ)在相同數(shù)據(jù)庫(kù)。既然所有的核心數(shù)據(jù)邏輯上都組織到一個(gè)數(shù)據(jù)庫(kù),那么MySpace必須找到新的辦法以分擔(dān)負(fù)荷一顯然,運(yùn)行在普通硬件上的單個(gè)數(shù)據(jù)庫(kù)服務(wù)器是無能為力的。這次,不再按站點(diǎn)功能和應(yīng)用分割數(shù)據(jù)庫(kù),MySpace開始將它的用戶按每百萬一組分割,然后將各組的全部數(shù)據(jù)分別存入獨(dú)立的SQLServer實(shí)例。目前,MySpace的每臺(tái)數(shù)據(jù)庫(kù)服務(wù)器實(shí)際運(yùn)行兩個(gè)SQLServer實(shí)例,也就是說每臺(tái)服務(wù)器服務(wù)大約2百萬用戶。Benedetto指出,以后還可以按照這種模式以更小粒度劃分架構(gòu),從而優(yōu)化負(fù)荷分擔(dān)。當(dāng)然,還是有一個(gè)特殊數(shù)據(jù)庫(kù)保存了所有賬戶的名稱和密碼。用戶登錄后,保存了他們其他數(shù)據(jù)的數(shù)據(jù)庫(kù)再接管服務(wù)。特殊數(shù)據(jù)庫(kù)的用戶表雖然龐大,但它只負(fù)責(zé)用戶登錄,功能單一,所以負(fù)荷還是比較容易控制的。里程碑四:9百萬到1千7百萬賬戶2005年早期,賬戶達(dá)到9百萬后,MySpace開始用Microsoft的C#編寫ASP.NET程序。C#是C語言的最新派生語言,吸收了C++和Java的優(yōu)點(diǎn),依托于Microsoft.NET框架(Microsoft為軟件組件化和分布式計(jì)算而設(shè)計(jì)的模型架構(gòu))。ASP.NET則由編寫Web站點(diǎn)腳本的ASP技術(shù)演化而來,是Microsoft目前主推的Web站點(diǎn)編程環(huán)境??梢哉f是立竿見影,MySpace馬上就發(fā)現(xiàn)ASP.NET程序運(yùn)行更有效率,與ColdFusion相比,完成同樣任務(wù)需消耗的處理器能力更小。據(jù)技術(shù)總監(jiān)Whitcomb說,新代碼需要150臺(tái)服務(wù)器完成的工作,如果用ColdFusion則需要246臺(tái)。Benedetto還指出,性能上升的另一個(gè)原因可能是在變換軟件平臺(tái),并用新語言重寫代碼的過程中,程序員復(fù)審并優(yōu)化了一些功能流程。最終,MySpace開始大規(guī)模遷移到ASP.NET。即便剩余的少部分ColdFusion代碼,也從Cold-Fusion服務(wù)器搬到了ASP.NET,因?yàn)樗麄兊玫搅薆lueDragon.NET(喬治亞州阿爾法利塔NewAtlantaCommunications公司的產(chǎn)品,它能將ColdFusion代碼自動(dòng)重新編譯到Microsoft平臺(tái))的幫助。賬戶達(dá)到1千萬時(shí),MySpace再次遭遇存儲(chǔ)瓶頸問題。SAN的引入解決了早期一些性能問題,但站點(diǎn)目前的要求已經(jīng)開始周期性超越SAN的I/O容量--即它從磁盤存儲(chǔ)系統(tǒng)讀寫數(shù)據(jù)的極限速度。原因之一是每數(shù)據(jù)庫(kù)1百萬賬戶的分割策略,通常情況下的確可以將壓力均分到各臺(tái)服務(wù)器,但現(xiàn)實(shí)并非一成不變。比如第七臺(tái)賬戶數(shù)據(jù)庫(kù)上線后,僅僅7天就被塞滿了,主要原因是佛羅里達(dá)一個(gè)樂隊(duì)的歌迷瘋狂注冊(cè)。某個(gè)數(shù)據(jù)庫(kù)可能因?yàn)槿魏卧?,在任何時(shí)候遭遇主要負(fù)荷,這時(shí),SAN中綁定到該數(shù)據(jù)庫(kù)的磁盤存儲(chǔ)設(shè)備簇就可能過載。"SAN讓磁盤I/O能力大幅提升了,但將它們綁定到特定數(shù)據(jù)庫(kù)的做法是錯(cuò)誤的。"Benedetto說。最初,MySpace通過定期重新分配SAN中數(shù)據(jù),以讓其更為均衡的方法基本解決了這個(gè)問題,但這是一個(gè)人工過程,"大概需要兩個(gè)人全職工作。"Benedetto說。長(zhǎng)期解決方案是遷移到虛擬存儲(chǔ)體系上,這樣,整個(gè)SAN被當(dāng)作一個(gè)巨型存儲(chǔ)池,不再要求每個(gè)磁盤為特定應(yīng)用服務(wù)°MySpace目前采用了一種新型SAN設(shè)備--來自加利福尼亞州弗里蒙特的3PARdata。在3PAR的系統(tǒng)里,仍能在邏輯上按容量劃分?jǐn)?shù)據(jù)存儲(chǔ),但它不再被綁定到特定磁盤或磁盤簇,而是散布于大量磁盤。這就使均分?jǐn)?shù)據(jù)訪問負(fù)荷成為可能。當(dāng)數(shù)據(jù)庫(kù)需要寫入一組數(shù)據(jù)時(shí),任何空閑磁盤都可以馬上完成這項(xiàng)工作,而不再像以前那樣阻塞在可能已經(jīng)過載的磁盤陣列處。而且,因?yàn)槎鄠€(gè)磁盤都有數(shù)據(jù)副本,讀取數(shù)據(jù)時(shí),也不會(huì)使SAN的任何組件過載。當(dāng)2005年春天賬戶數(shù)達(dá)到1千7百萬時(shí),MySpace又啟用了新的策略以減輕存儲(chǔ)系統(tǒng)壓力,即增加數(shù)據(jù)緩存層--位于Web服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器之間,其唯一職能是在內(nèi)存中建立被頻繁請(qǐng)求數(shù)據(jù)對(duì)象的副本,如此一來,不訪問數(shù)據(jù)庫(kù)也可以向Web應(yīng)用供給數(shù)據(jù)。換句話說,100個(gè)用戶請(qǐng)求同一份資料,以前需要查詢數(shù)據(jù)庫(kù)100次,而現(xiàn)在只需1次,其余都可從緩存數(shù)據(jù)中獲得。當(dāng)然如果頁(yè)面變化,緩存的數(shù)據(jù)必須從內(nèi)存擦除,然后重新從數(shù)據(jù)庫(kù)獲取--旦在此之前,數(shù)據(jù)庫(kù)的壓力已經(jīng)大大減輕,整個(gè)站點(diǎn)的性能得到提升。緩存區(qū)還為那些不需要記入數(shù)據(jù)庫(kù)的數(shù)據(jù)提供了驛站,比如為跟蹤用戶會(huì)話而創(chuàng)建的臨時(shí)文件--Benedetto坦言他需要在這方面補(bǔ)課,"我是數(shù)據(jù)庫(kù)存儲(chǔ)狂熱分子,因此我總是想著將萬事萬物都存到數(shù)據(jù)庫(kù)。"但將像會(huì)話跟蹤這類的數(shù)據(jù)也存到數(shù)據(jù)庫(kù),站點(diǎn)將陷入泥沼。增加緩存服務(wù)器是"一開始就應(yīng)該做的事情,但我們成長(zhǎng)太快,以致于沒有時(shí)間坐下來好好研究這件事情。"Benedetto補(bǔ)充道。里程碑五:2千6百萬賬戶2005年中期,服務(wù)賬戶數(shù)達(dá)到2千6百萬時(shí),MySpace切換到了還處于beta測(cè)試的SQLServer2005。轉(zhuǎn)換何太急?主流看法是2005版支持64位處理器。但Benedetto說,"這不是主要原因,盡管這也很重要;主要還是因?yàn)槲覀儗?duì)內(nèi)存的渴求。"支持64位的數(shù)據(jù)庫(kù)可以管理更多內(nèi)存。更多內(nèi)存就意味著更高的性能和更大的容量。原來運(yùn)行32位版本的SQLServer服務(wù)器,能同時(shí)使用的內(nèi)存最多只有4G。切換到64位,就好像加粗了輸水管的直徑。升級(jí)到SQLServer2005和64位WindowsServer2003后,MySpace每臺(tái)服務(wù)器配備了32G內(nèi)存,后于2006年再次將配置標(biāo)準(zhǔn)提升到64G。意外錯(cuò)誤如果沒有對(duì)系統(tǒng)架構(gòu)的歷次修改與升級(jí),MySpace根本不可能走到今天。但是,為什么系統(tǒng)還經(jīng)常吃撐著了?很多用戶抱怨的"意外錯(cuò)誤”是怎么引起的呢?原因之一是MySpace對(duì)Microsoft的Web技術(shù)的應(yīng)用已經(jīng)進(jìn)入連Microsoft自己也才剛剛開始探索的領(lǐng)域。比如11月,超出SQLServer最大同時(shí)連接數(shù),MySpace系統(tǒng)崩潰。Benedetto說,這類可能引發(fā)系統(tǒng)崩潰的情況大概三天才會(huì)出現(xiàn)一次,但仍然過于頻繁了,以致惹人惱怒。一旦數(shù)據(jù)庫(kù)罷工,"無論這種情)兄什么時(shí)候發(fā)生,未緩存的數(shù)據(jù)都不能從SQLServer獲得,那么你就必然看到一個(gè)'意外錯(cuò)誤'提示。"他解釋說。去年夏天,MySpace的Windows2003多次自動(dòng)停止服務(wù)。后來發(fā)現(xiàn)是操作系統(tǒng)一個(gè)內(nèi)置功能惹的禍--預(yù)防分布式拒絕服務(wù)攻擊(黑客使用很多客戶機(jī)向服務(wù)器發(fā)起大量連接請(qǐng)求,以致服務(wù)器癱瘓)。MySpace和其他很多頂級(jí)大站點(diǎn)一樣,肯定會(huì)經(jīng)常遭受攻擊,但它應(yīng)該從網(wǎng)絡(luò)級(jí)而不是依靠Windows本身的功能來解決問題--否則,大量MySpace合法用戶連接時(shí)也會(huì)引起服務(wù)器反擊。"我們花了大約一個(gè)月時(shí)間尋找Windows2003服務(wù)器自動(dòng)停止的原因。"Benedetto說。最后,通過Microsoft的幫助,他們才知道該怎么通知服務(wù)器:"別開槍,是友軍。"緊接著是在去年7月某個(gè)周日晚上,MySpace總部所在地洛杉磯停電,造成整個(gè)系統(tǒng)停運(yùn)12小時(shí)。大型Web站點(diǎn)通常要在地理上分布配置多個(gè)數(shù)據(jù)中心以預(yù)防單點(diǎn)故障。本來,MySpace還有其他兩個(gè)數(shù)據(jù)中心以應(yīng)對(duì)突發(fā)事件,但Web服務(wù)器都依賴于部署在洛杉磯的SAN。沒有洛杉磯的SAN,Web服務(wù)器除了懇求你耐心等待,不能提供任何服務(wù)。Benedetto說,主數(shù)據(jù)中心的可靠性通過下列措施保證:可接入兩張不同電網(wǎng),另有后備電源和一臺(tái)儲(chǔ)備有30天燃料的發(fā)電機(jī)。但在這次事故中,不僅兩張電網(wǎng)失效,而且在切換到備份電源的過程中,操作員燒掉了主動(dòng)力線路。2007年中,MySpace在另兩個(gè)后備站點(diǎn)上也建設(shè)了SAN。這對(duì)分擔(dān)負(fù)荷大有幫助--正常情況下,每個(gè)SAN都能負(fù)擔(dān)三分之一的數(shù)據(jù)訪問量。而在緊急情況下,任何一個(gè)站點(diǎn)都可以獨(dú)立支撐整個(gè)服務(wù),Benedetto說。MySpace仍然在為提高穩(wěn)定性?shī)^斗,雖然很多用戶表示了足夠信任且能原諒偶現(xiàn)的錯(cuò)誤頁(yè)面。"作為開發(fā)人員,我憎惡Bug,它太氣人了。"DanTanner這個(gè)31歲的德克薩斯軟件工程師說,他通過MySpace重新聯(lián)系到了高中和大學(xué)同學(xué)。"不過,MySpace對(duì)我們的用處很大,因此我們可以原諒偶發(fā)的故障和錯(cuò)誤。"Tanner說,如果站點(diǎn)某天出現(xiàn)故障甚至崩潰,恢復(fù)以后他還是會(huì)繼續(xù)使用。這就是為什么Drew在論壇里咆哮時(shí),大部分用戶都告訴他應(yīng)該保持平靜,如果等幾分鐘,問題就會(huì)解決的原因。Drew無法平靜,他寫道,"我已經(jīng)兩次給MySpace發(fā)郵件,而它說一小時(shí)前還是正常的,現(xiàn)在出了點(diǎn)問題??…完全是一堆廢話。"另一個(gè)用戶回復(fù)說,"畢竟它是免費(fèi)的。"Benedetto坦承100%的可靠性不是他的目標(biāo)。"它不是銀行,而是一個(gè)免費(fèi)的服務(wù)。"他說。換句話說,MySpace的偶發(fā)故障可能造成某人最后更新的個(gè)人資料丟失,但并不意味著網(wǎng)站弄丟了用戶的錢財(cái)。"關(guān)鍵是要認(rèn)識(shí)到,與保證站點(diǎn)性能相比,丟失少許數(shù)據(jù)的故障是可接受的。"Benedetto說。所以,MySpace甘冒丟失2分鐘到2小時(shí)內(nèi)任意點(diǎn)數(shù)據(jù)的危險(xiǎn),在SQLServer配置里延長(zhǎng)了"checkpoint"操作一它將待更新數(shù)據(jù)永久記錄到磁盤一的間隔時(shí)間,因?yàn)檫@樣做可以加快數(shù)據(jù)庫(kù)的運(yùn)行。Benedetto說,同樣,開發(fā)人員還經(jīng)常在幾個(gè)小時(shí)內(nèi)就完成構(gòu)思、編碼、測(cè)試和發(fā)布全過程。這有引入Bug的風(fēng)險(xiǎn),但這樣做可以更快實(shí)現(xiàn)新功能。而且,因?yàn)檫M(jìn)行大規(guī)模真實(shí)測(cè)試不具可行性,他們的測(cè)試通常是在僅以部分活躍用戶為對(duì)象,且用戶對(duì)軟件新功能和改進(jìn)不知就里的情況下進(jìn)行的。因?yàn)槭聦?shí)上不可能做真實(shí)的加載測(cè)試,他們做的測(cè)試通常都是針對(duì)站點(diǎn)?!蔽覀兎高^大量錯(cuò)誤,"Benedetto說,"但到頭來,我認(rèn)為我們做對(duì)的還是比做錯(cuò)的多。"七、從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法LiveJournal是99年始于校園中的項(xiàng)目,幾個(gè)人出于愛好做了這樣一個(gè)應(yīng)用,以實(shí)現(xiàn)以下功能:博客,論壇社會(huì)性網(wǎng)絡(luò),找到朋友聚合,把朋友的文章聚合在一起LiveJournal采用了大量的開源軟件,甚至它本身也是一個(gè)開源軟件。在上線后,LiveJournal實(shí)現(xiàn)了非??焖俚脑鲩L(zhǎng):2004年4月份:280萬注冊(cè)用戶。2005年4月份:680萬注冊(cè)用戶。2005年8月份:790萬注冊(cè)用戶。達(dá)到了每秒鐘上千次的頁(yè)面請(qǐng)求及處理。使用了大量MySQL服務(wù)器。使用了大量通用組件'三、從LiveJournal發(fā)展中學(xué)習(xí)LiveJournal從1臺(tái)服務(wù)器發(fā)展到100臺(tái)服務(wù)器,這其中經(jīng)歷了無數(shù)的傷痛,但同時(shí)也摸索出了解決這些問題的方法,通過對(duì)LiveJournal的學(xué)習(xí),可以讓我們避免LJ曾經(jīng)犯過的錯(cuò)誤,并且從一開始就對(duì)系統(tǒng)進(jìn)行良好的設(shè)計(jì),以避免后期的痛苦。下面我們一步一步看LJ發(fā)展的腳步。1、一臺(tái)服務(wù)器一臺(tái)別人捐助的服務(wù)器,LJ最初就跑在上面,就像Google開始時(shí)候用的破服務(wù)器一樣,值得我們尊敬。這個(gè)階段,1丁的人以驚人的速度熟悉的Unix的操作管理,服務(wù)器性能出現(xiàn)過問題,不過還好,可以通過一些小修小改應(yīng)付過去。在這個(gè)階段里L(fēng)J把CGI升級(jí)到了FastCGI。最終問題出現(xiàn)了,網(wǎng)站越來越慢,已經(jīng)無法通過優(yōu)過化來解決的地步,需要更多的服務(wù)器,這時(shí)LJ開始提供付費(fèi)服務(wù),可能是想通過這些錢來購(gòu)買新的服務(wù)器,以解決當(dāng)時(shí)的困境。毫無疑問,當(dāng)時(shí)LJ存在巨大的單點(diǎn)問題,所有的東西都在那臺(tái)服務(wù)器的鐵皮盒子里裝著。2、兩臺(tái)服務(wù)器用付費(fèi)服務(wù)賺來的錢LJ買了兩臺(tái)服務(wù)器:一臺(tái)叫做Kenny的Dell6U機(jī)器用于提供Web服務(wù),一臺(tái)叫做Cartman的Dell6U服務(wù)器用于提供數(shù)據(jù)庫(kù)服務(wù)。7有了更大的磁盤,更多的計(jì)算資源。但同時(shí)網(wǎng)絡(luò)結(jié)構(gòu)還是非常簡(jiǎn)單,每臺(tái)機(jī)器兩塊網(wǎng)卡,Cartman通過內(nèi)網(wǎng)為Kenny提供MySQL數(shù)據(jù)庫(kù)服務(wù)。暫時(shí)解決了負(fù)載的問題,新的問題又出現(xiàn)了:原來的一個(gè)單點(diǎn)變成了兩個(gè)單點(diǎn)。沒有冷備份或熱備份。網(wǎng)站速度慢的問題又開始出現(xiàn)了,沒辦法,增長(zhǎng)太快了。Web服務(wù)器上CPU達(dá)到上限,需要更多的Web服務(wù)器。3、四臺(tái)服務(wù)器又買了兩臺(tái),Kyle和Stan,這次都是1U的,都用于提供Web服務(wù)。目前LJ一共有3臺(tái)Web服務(wù)器和一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。這時(shí)需要在3臺(tái)Web服務(wù)器上進(jìn)行負(fù)載均橫。LJ把Kenny用于外部的網(wǎng)關(guān),使用mod_backhand進(jìn)行負(fù)載均橫。然后問題又出現(xiàn)了:?jiǎn)吸c(diǎn)故障。數(shù)據(jù)庫(kù)和用于做網(wǎng)關(guān)的Web服務(wù)器都是單點(diǎn),一旦任何一臺(tái)機(jī)器出現(xiàn)問題將導(dǎo)致所有服務(wù)不可用。雖然用于做網(wǎng)關(guān)的Web服務(wù)器可以通過保持心跳同步迅速切換,但還是無法解決數(shù)據(jù)庫(kù)的單點(diǎn),LJ當(dāng)時(shí)也沒做這個(gè)。網(wǎng)站又變慢了,這次是因?yàn)镮O和數(shù)據(jù)庫(kù)的問題,問題是怎么往應(yīng)用里面添加數(shù)據(jù)庫(kù)呢?4、五臺(tái)服務(wù)器又買了一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。在兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上使用了數(shù)據(jù)庫(kù)同步(Mysql支持的Master-Slave模式),寫操作全部針對(duì)主數(shù)據(jù)庫(kù)(通過Binlog,主服務(wù)器上的寫操作可以迅速同步到從服務(wù)器上),讀操作在兩個(gè)數(shù)據(jù)庫(kù)上同時(shí)進(jìn)行(也算是負(fù)載均橫的一種吧)。實(shí)現(xiàn)同步時(shí)要注意幾個(gè)事項(xiàng):讀操作數(shù)據(jù)庫(kù)選擇算法處理,要選一個(gè)當(dāng)前負(fù)載輕一點(diǎn)的數(shù)據(jù)庫(kù)。在從數(shù)據(jù)庫(kù)服務(wù)器上只能進(jìn)行讀操作準(zhǔn)備好應(yīng)對(duì)同步過程中的延遲,處理不好可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)同步的中斷。只需要對(duì)寫操作進(jìn)行判斷即可,讀操作不存在同步問題。5、更多服務(wù)器有錢了,當(dāng)然要多買些服務(wù)器。部署后快了沒多以,又開始慢了。這次有更多的Web服務(wù)器,更多的數(shù)據(jù)庫(kù)服務(wù)器,存在IO與CPU爭(zhēng)用。于是采用了BIG-IP作為負(fù)載均衡解決方案。
6、現(xiàn)在我們?cè)谀睦?現(xiàn)在服務(wù)器基本上夠了,但性能還是有問題,原因出在架構(gòu)上。數(shù)據(jù)庫(kù)的架構(gòu)是最大的問題。由于增加的數(shù)據(jù)庫(kù)都是以Slave模式添加到應(yīng)用內(nèi),這樣唯一的好處就是將讀操作分布到了多臺(tái)機(jī)器,但這樣帶來的后果就是寫操作被大量分發(fā),每臺(tái)機(jī)器都要執(zhí)行,服務(wù)器越多,浪費(fèi)就越大,隨著寫操作的增加,用于服務(wù)讀操作的資源越來越少。*1ywW2柏ns由一臺(tái)分布到兩臺(tái)最終效果現(xiàn)在我們發(fā)現(xiàn),我們并不需要把這些數(shù)據(jù)在如此多的服務(wù)器上都保留一份。服務(wù)器上已經(jīng)做了RAID,數(shù)據(jù)庫(kù)也進(jìn)行了備份,這么多的備份完全是對(duì)資源的浪費(fèi),屬于冗余極端過度。那為什么不把數(shù)據(jù)分布存儲(chǔ)呢?問題發(fā)現(xiàn)了,開始考慮如何解決?,F(xiàn)在要做的就是把不同用戶的數(shù)據(jù)分布到不同的服務(wù)器上進(jìn)行存儲(chǔ),以實(shí)現(xiàn)數(shù)據(jù)的分布式存儲(chǔ),讓每臺(tái)機(jī)器只為相對(duì)固定的用戶服務(wù),以實(shí)現(xiàn)平行的架構(gòu)和良好的可擴(kuò)展性。為了實(shí)現(xiàn)用戶分組,我們需要為每一個(gè)用戶分配一個(gè)組標(biāo)記,用于標(biāo)記此用戶的數(shù)據(jù)存放在哪一組數(shù)據(jù)庫(kù)服務(wù)器中。每組數(shù)據(jù)庫(kù)由一個(gè)master及幾個(gè)slave組成,并且slave的數(shù)量在2-3臺(tái),以實(shí)現(xiàn)系統(tǒng)資源的最合理分配,既保證數(shù)據(jù)讀操作分布,又避免數(shù)據(jù)過度冗余以及同步操作對(duì)系統(tǒng)資源的過度消耗。由一臺(tái)(一組)中心服務(wù)器提供用戶分組控制。所有用戶的分組信息都存儲(chǔ)在這臺(tái)機(jī)器上,所有針對(duì)用戶的操作需要先查詢這臺(tái)機(jī)器得到用戶的組號(hào),然后再到相應(yīng)的數(shù)據(jù)庫(kù)組中獲取數(shù)據(jù)。這樣的用戶架構(gòu)與目前LJ的架構(gòu)已經(jīng)很相像了。在具體的實(shí)現(xiàn)時(shí)需要注意幾個(gè)問題:在數(shù)據(jù)庫(kù)組內(nèi)不要使用自增ID,以便于以后在數(shù)據(jù)庫(kù)組之間遷移用戶,以實(shí)現(xiàn)更合理的I/O,磁盤空間及負(fù)載分布。將userid,postid存儲(chǔ)在全局服務(wù)器上,可以使用自增,數(shù)據(jù)庫(kù)組中的相應(yīng)值必須以全局服務(wù)器上的值為準(zhǔn)。全局服務(wù)器上使用事務(wù)型數(shù)據(jù)庫(kù)InnoDB。在數(shù)據(jù)庫(kù)組之間遷移用戶時(shí)要萬分小心,當(dāng)遷移時(shí)用戶不能有寫操作。7、現(xiàn)在我們?cè)谀睦飭栴}:一個(gè)全局主服務(wù)器,掛掉的話所有用戶注冊(cè)及寫操作就掛掉。每個(gè)數(shù)據(jù)庫(kù)組一個(gè)主服務(wù)器,掛掉的話這組用戶的寫操作就掛掉。數(shù)據(jù)庫(kù)組從服務(wù)器掛掉的話會(huì)導(dǎo)致其它服務(wù)器負(fù)載過大。對(duì)于Master-Slave模式的單點(diǎn)問題,LJ采取了Master-Master模式來解決。所謂Master-Master實(shí)際上是人工實(shí)現(xiàn)的,并不是由MySQL直接提供的,實(shí)際上也就是兩臺(tái)機(jī)器同時(shí)是Master,也同時(shí)是Slave,互相同步。Master-Master實(shí)現(xiàn)時(shí)需要注意:一個(gè)Master出錯(cuò)后恢復(fù)同步,最好由服務(wù)器自動(dòng)完成。數(shù)字分配,由于同時(shí)在兩臺(tái)機(jī)器上寫,有些ID可能會(huì)沖突。解決方案:奇偶數(shù)分配ID,一臺(tái)機(jī)器上寫奇數(shù),一臺(tái)機(jī)器上寫偶數(shù)通過全局服務(wù)器進(jìn)行分配(LJ采用的做法)。Master-Master模式還有一種用法,這種方法與前一種相比,仍然保持兩臺(tái)機(jī)器的同步,但只有一臺(tái)機(jī)器提供服務(wù)(讀和寫),在每天晚上的時(shí)候進(jìn)行輪換,或者出現(xiàn)問題的時(shí)候進(jìn)行切換。8、現(xiàn)在我們?cè)谀睦铿F(xiàn)在插播一條廣告,MylSAMVSInnoDB。使用InnoDB:支持事務(wù)需要做更多的配置,不過值得,可以更安全的存儲(chǔ)數(shù)據(jù),以及得到更快的速度。使用MyISAM:記錄日志(LJ用它來記網(wǎng)絡(luò)訪問日志)存儲(chǔ)只讀靜態(tài)數(shù)據(jù),足夠快。并發(fā)性很差,無法同時(shí)讀寫數(shù)據(jù)(添加數(shù)據(jù)可以)MySQL非正常關(guān)閉或死機(jī)時(shí)會(huì)導(dǎo)致索引錯(cuò)誤,需要使用myisamchk修復(fù),而且當(dāng)訪問量大時(shí)出現(xiàn)非常頻繁。9、緩存去年我寫過一篇文章介紹memcached,它就是由LJ的團(tuán)隊(duì)開發(fā)的一款緩存工具,以key-value的方式將數(shù)據(jù)存儲(chǔ)到分布的內(nèi)存中。LJ緩存的數(shù)據(jù):12臺(tái)獨(dú)立服務(wù)器(不是捐贈(zèng)的)28個(gè)實(shí)例30GB總?cè)萘?0-93%的命中率(用過squid的人可能知道,squid內(nèi)存加磁盤的命中率大概在70-80%)如何建立緩存策略?想緩存所有的東西?那是不可能的,我們只需要緩存已經(jīng)或者可能導(dǎo)致系統(tǒng)瓶頸的地方,最大程度的提交系統(tǒng)運(yùn)行效率。通過對(duì)MySQL的日志的分析我們可以找到緩存的對(duì)象。緩存的缺點(diǎn)?沒有完美的事物,緩存也有缺點(diǎn):增大開發(fā)量,需要針對(duì)緩存處理編寫特殊的代碼。管理難度增加,需要更多人參與系統(tǒng)維護(hù)。當(dāng)然大內(nèi)存也需要錢。10、Web訪問負(fù)載均衡在數(shù)據(jù)包級(jí)別使用BIG-IP,但BIG-IP并不知道我們內(nèi)部的處理機(jī)制,無法判斷由哪臺(tái)服務(wù)器對(duì)這些請(qǐng)求進(jìn)行處理。反向代理并不能很好的起到作用,不是已經(jīng)夠快了,就是達(dá)不到我們想要的效果。所以,LJ又開發(fā)了Perlbal。特點(diǎn):快,小,可管理的httpweb服務(wù)器/代理可以在內(nèi)部進(jìn)行轉(zhuǎn)發(fā)使用Perl開發(fā)單線程,異步,基于事件,使用epoll,kqueue支持Console管理與http遠(yuǎn)程管理,支持動(dòng)態(tài)配置加載多種模式:web服務(wù)器,反向代理,插件支持插件:GIF/PNG互換?11、MogileFSLJ使用開源的MogileFS作為分布式文件存儲(chǔ)系統(tǒng)。MogileFS使用非常簡(jiǎn)單,它的主要設(shè)計(jì)思想是:文件屬于類(類是最小的復(fù)制單位)跟蹤文件存儲(chǔ)位置在不同主機(jī)上存儲(chǔ)使用MySQL集群統(tǒng)一存儲(chǔ)分布信息大容易廉價(jià)磁盤到目前為止就這么多了,更多文檔可以在/words/找到。D和LiveJ的同學(xué)們拿這個(gè)文檔參加了兩次MySQLCon,兩次OSCon,以及眾多的其它會(huì)議,無私的把他們的經(jīng)驗(yàn)分享出來,值得我們學(xué)習(xí)。在web2.0時(shí)代快速開發(fā)得到大家越來越多的重視,但良好的設(shè)計(jì)仍是每一個(gè)應(yīng)用的基礎(chǔ),希望we
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- 現(xiàn)場(chǎng)柴油發(fā)電機(jī)臨時(shí)供電方案設(shè)計(jì)與實(shí)施細(xì)節(jié)
- 機(jī)電養(yǎng)護(hù)監(jiān)理管理辦法
- 生態(tài)文明建設(shè)教育課程體系構(gòu)建與教學(xué)設(shè)計(jì)研究
- 數(shù)字仿真:產(chǎn)品創(chuàng)新加速器技術(shù)探索
- 煤系巷道頂板疊加理論與有效錨固層厚度應(yīng)用研究
- 醫(yī)療集團(tuán)資產(chǎn)管理辦法
- 熱紅外遙感勘探-洞察及研究
- 音樂傳播視角下高職學(xué)生合唱藝術(shù)審美能力培養(yǎng)策略研究
- 全員安全生產(chǎn)責(zé)任制清單模板
- 關(guān)于安全生產(chǎn)會(huì)議的法律規(guī)定
- 【信得科技】2025豬細(xì)菌病防控手冊(cè)
- 罐體制作合同協(xié)議
- 電動(dòng)車維修與保養(yǎng)考核試卷
- “住改商”登記利害關(guān)系業(yè)主同意證明(參考樣本)
- 2025-2030中國(guó)氣象服務(wù)行業(yè)市場(chǎng)前景趨勢(shì)及競(jìng)爭(zhēng)格局與投資研究報(bào)告
- 外研版六年級(jí)上冊(cè)英語全冊(cè)教學(xué)課件
- 廣西壯族自治區(qū)南寧市2024-2025學(xué)年九年級(jí)上學(xué)期期末道德與法治試題(含答案)
- 企業(yè)迎檢工作要點(diǎn)
- 2025年度汽車維修配件股份合作協(xié)議4篇
- 2022年河北省特種設(shè)備作業(yè)安全管理人員證考試題庫(kù)(含答案)
- 以客戶為中心的銀行服務(wù)體驗(yàn)優(yōu)化
評(píng)論
0/150
提交評(píng)論