大規(guī)模網(wǎng)站設計

大型高并發(fā)高負載網(wǎng)站的系統(tǒng)架構我在CERNET做過撥號接入平臺的搭建，而后在Yahoo&3721從事過搜索引擎前端開發(fā)，又在MOP處理過大型社區(qū)貓撲大雜燴的架構升級等工作，同時自己接觸和開發(fā)過不少大中型網(wǎng)站的模塊，因此在大型網(wǎng)站應對高負載和并發(fā)的解決方案上有一些積累和經(jīng)驗，可以和大家一起探討一下。一個小型的網(wǎng)站，比如個人網(wǎng)站，可以使用最簡單的html靜態(tài)頁面就實現(xiàn)了，配合一些圖片達到美化效果，所有的頁面均存放在一個目錄下，這樣的網(wǎng)站對系統(tǒng)架構、性能的要求都很簡單，隨著互聯(lián)網(wǎng)業(yè)務的不斷豐富，網(wǎng)站相關的技術經(jīng)過這些年的發(fā)展，已經(jīng)細分到很細的方方面面，尤其對于大型網(wǎng)站來說，所采用的技術更是涉及面非常廣，從硬件到軟件、編程語言、數(shù)據(jù)庫、WebServer、防火墻等各個領域都有了很高的要求，已經(jīng)不是原來簡單的html靜態(tài)網(wǎng)站所能比擬的。大型網(wǎng)站，比如門戶網(wǎng)站。在面對大量用戶訪問、高并發(fā)請求方面，基本的解決方案集中在這樣幾個環(huán)節(jié)：使用高性能的服務器、高性能的數(shù)據(jù)庫、高效率的編程語言、還有高性能的Web容器。但是除了這幾個方面，還沒法根本解決大型網(wǎng)站面臨的高負載和高并發(fā)問題。上面提供的幾個解決思路在一定程度上也意味著更大的投入，并且這樣的解決思路具備瓶頸，沒有很好的擴展性，下面我從低成本、高性能和高擴張性的角度來說說我的一些經(jīng)驗。1、HTML靜態(tài)化其實大家都知道，效率最高、消耗最小的就是純靜態(tài)化的html頁面，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實現(xiàn)，這個最簡單的方法其實也是最有效的方法。但是對于大量內容并且頻繁更新的網(wǎng)站，我們無法全部手動去挨個實現(xiàn)，于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng)CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發(fā)布系統(tǒng)來管理和實現(xiàn)的，信息發(fā)布系統(tǒng)可以實現(xiàn)最簡單的信息錄入自動生成靜態(tài)頁面，還能具備頻道管理、權限管理、自動抓取等功能，對于一個大型網(wǎng)站來說，擁有一套高效、可管理的CMS是必不可少的。除了門戶和信息發(fā)布類型的網(wǎng)站，對于交互性要求很高的社區(qū)類型網(wǎng)站來說，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內的帖子、文章進行實時的靜態(tài)化，有更新的時候再重新靜態(tài)化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網(wǎng)易社區(qū)等也是如此。目前很多博客也都實現(xiàn)了靜態(tài)化，我使用的這個Blog程序WordPress還沒有靜態(tài)化，所以如果面對高負載訪問，-定不能承受同時，html靜態(tài)化也是某些緩存策略使用的手段，對于系統(tǒng)中頻繁使用數(shù)據(jù)庫查詢但是內容更新很小的應用，可以考慮使用html靜態(tài)化來實現(xiàn)，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行后臺管理并且存儲再數(shù)據(jù)庫中，這些信息其實大量被前臺程序調用，但是更新頻率很小，可以考慮將這部分內容進行后臺更新的時候進行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫訪問請求。在進行html靜態(tài)化的時候可以使用一種折中的方法，就是前端使用動態(tài)實現(xiàn)，在一定的策略下進行定時靜態(tài)化和定時判斷調用，這個能實現(xiàn)很多靈活性的操作，我開發(fā)的臺球網(wǎng)站故人居（就是使用了這樣的方法，我通過設定一些html靜態(tài)化的時間間隔來對動態(tài)網(wǎng)站內容進行緩存，達到分擔大部分的壓力到靜態(tài)頁面上，可以應用于中小型網(wǎng)站的架構上。故人居網(wǎng)站的地址：http://www.8zone.0n順便提一下，有喜歡臺球的朋友多多支持我這個免費網(wǎng)站:）2、圖片服務器分離大家知道，對于Web服務器來說，不管是Apache.IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進行分離，這是基本上大型網(wǎng)站都會采用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統(tǒng)壓力，并且可以保證系統(tǒng)不會因為圖片問題而崩潰。在應用服務器和圖片服務器上，可以進行不同的配置優(yōu)化，比如Apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率。我的臺球網(wǎng)站故人居8也使用了圖片服務器架構上的分離，目前是僅僅是架構上分離，物理上沒有分離，由于沒有錢買更多的服務器:）大家可以看到故人居上的圖片連接都是類似或者的URL。另外，在處理靜態(tài)頁面或者圖片、js等訪問方面，可以考慮使用lighttp代替Apache，它提供了更輕量級和更高效的處理能力。3、數(shù)據(jù)庫集群和庫表散列大型網(wǎng)站都有復雜的應用，這些應用必須使用數(shù)據(jù)庫，那么在面對大量訪問的時候，數(shù)據(jù)庫的瓶頸很快就能顯現(xiàn)出來，這時一臺數(shù)據(jù)庫將很快無法滿足應用，于是我們需要使用數(shù)據(jù)庫集群或者庫表散列。在數(shù)據(jù)庫集群方面，很多數(shù)據(jù)庫都有自己的解決方案，OracleSybase等都有很好的方案，常用的MySQL提供的Master/Slav也是類似的方案，您使用了什么樣的DB，就參考相應的解決方案來實施即可。上面提到的數(shù)據(jù)庫集群由于在架構、成本、擴張性方面都會受到所采用DB類型的限制，于是我們需要從應用程序的角度來考慮改善系統(tǒng)架構，庫表散列是常用并且最有效的解決方案。我們在應用程序中安裝業(yè)務和應用或者功能模塊將數(shù)據(jù)庫進行分離，不同的模塊對應不同的數(shù)據(jù)庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數(shù)據(jù)庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴展性。sohu的論壇就是采用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數(shù)據(jù)庫分離，然后對帖子、用戶按照板塊和ID進行散列數(shù)據(jù)庫和表，最終可以在配置文件中進行簡單的配置便能讓系統(tǒng)隨時增加一臺低成本的數(shù)據(jù)庫進來補充系統(tǒng)性能。4、緩存緩存一詞搞技術的都接觸過，很多地方用到緩存。網(wǎng)站架構和網(wǎng)站開發(fā)中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在后面講述。架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的mod_proxy緩存模塊，也可以使用外加的Squid進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。網(wǎng)站程序開發(fā)方面的緩存，Linux上提供的Memcached是常用的緩存方案，不少web編程語言都提供memcache訪問接口，php、per、c和java都有，可以在web開發(fā)中使用，可以實時或者Cron的把數(shù)據(jù)、對象等內容進行緩存，策略非常靈活。一些大型社區(qū)使用了這樣的架構。另外，在使用web語言開發(fā)的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊和eAccelerato加速和Cache模塊，還要知名的Apc、XCache（國人開發(fā)的，支持！）php緩存模塊，Java就更多了，.ne不是很熟悉，相信也肯定有。5、鏡像鏡像是大型網(wǎng)站常采用的提高性能和數(shù)據(jù)安全性的方式，鏡像的技術可以解決不同網(wǎng)絡接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網(wǎng)站在教育網(wǎng)內搭建鏡像站點，數(shù)據(jù)進行定時更新或者實時更新。在鏡像的細節(jié)技術方面，這里不闡述太深，有很多專業(yè)的現(xiàn)成的解決架構和產(chǎn)品可選。也有廉價的通過軟件實現(xiàn)的思路，比如Linux上的rsync等工具。6、負載均衡負載均衡將是大型網(wǎng)站解決高負荷訪問和大量并發(fā)請求采用的終極解決辦法。負載均衡技術發(fā)展了多年，有很多專業(yè)的服務提供商和產(chǎn)品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。另外有關初級的負載均衡DNS輪循和較專業(yè)的CDN架構就不多說了。6.1硬件四層交換第四層交換使用第三層和第四層信息包的報頭信息，根據(jù)應用區(qū)間識別業(yè)務流，將整個區(qū)間段的業(yè)務流分配到合適的應用服務器進行處理。第四層交換功能就象是虛IP，指向物理服務器。它傳輸?shù)臉I(yè)務服從的協(xié)議多種多樣，有http、FTP、NFS、Telnet或其他協(xié)議。這些業(yè)務在物理服務器基礎上，需要復雜的載量平衡算法。在IP世界，業(yè)務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區(qū)間則由源端和終端IP地址、TCP和UDP端口共同決定。在硬件四層交換產(chǎn)品領域，有一些知名的產(chǎn)品可以選擇，比如AlteonF5等，這些產(chǎn)品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力oYahoo中國當初接近2000臺服務器使用了三四臺Alteor就搞定了。6.2軟件四層交換大家知道了硬件四層交換機的原理后，基于OSI模型來實現(xiàn)的軟件四層交換也就應運而生，這樣的解決方案實現(xiàn)的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有余的，有人說軟件實現(xiàn)方式其實更靈活，處理能力完全看你配置的熟悉能力。軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是LinuxVirtualSer，ver他提供了基于心跳線heartbeat實時災難應對解決方案，提高系統(tǒng)的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對于分布式的系統(tǒng)來說必不可少。一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網(wǎng)站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構里面增減節(jié)點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討?？偨Y：對于大型網(wǎng)站來說，前面提到的每個方法可能都會被同時使用到，Michael這里介紹得比較淺顯，具體實現(xiàn)過程中很多細節(jié)還需要大家慢慢熟悉和體會，有時一個很小的squid#數(shù)或者apache參數(shù)設置，對于系統(tǒng)性能的影響就會很大，希望大家一起討論，達到拋磚引玉之效。使用開源軟件，設計高性能可擴展互動網(wǎng)站上次我們以LiveJournal例詳細分析了一個小網(wǎng)站在一步一步的發(fā)展成為大規(guī)模的網(wǎng)站中性能優(yōu)化的方案，以解決在發(fā)展中由于負載增長而引起的性能問題，同時在設計網(wǎng)站架構的時候就從根本上避免或者解決這些問題。今天我們來看一下在網(wǎng)站的設計上一些通常使用的解決大規(guī)模訪問，高負載的方法。我們將主要涉及到以下幾方面：1士土土LU十卜1、前端負載2、業(yè)務邏輯層3、數(shù)據(jù)層在LJ性能優(yōu)化文章中我們提到對服務器分組是解決負載問題，實現(xiàn)無限擴展的解決方案。通常中我們會采用類似LDAP的方案來解決，這在郵件的服務器以及個人網(wǎng)站，博客的應用中都有使用，在Windows下面有類似的ActiveDirecto解決方案。有的應用（例如博客或者個人網(wǎng)頁）會要求在二級域名解析的時候就將用戶定位到所屬的服務器群組，這個時候請求還沒到應用上面，我們需要在DNS里解決這個問題。這個時候可以用到一款軟件binddl,z這是bind的一個插件，用于取代bind的文本解析配置文件。它支持包括LDAP，BDB在內的多種數(shù)據(jù)存儲方式，可以比較好的解決這個問題。另外一種涉及到DNS的問題就是目前普遍存在的南北互聯(lián)互通的問題，通過bind9內置的視圖功能可以根據(jù)不同的IP來源解析出不同的結果，從而將南方的用戶解析到南方的服務器，北方的用戶解析到北方的服務器。這個過程中會碰到兩個問題，一是取得南北IP的分布列表，二是保證南北服務器之間的通訊順暢。第一個問題有個笨辦法解決，從日志里取出所有的訪問者IP，寫一個腳本從南北的服務器分別Ping回去，然后分析結果，可以得到一個大致準確的列表，當然最好的辦法還是直到從運營商那里拿到這份列表（update參見這篇文章）。后一個問題解決辦法比較多，最好的辦法就是租用雙線機房，同一臺機器，雙IP，南北同時接入，差一些的辦法就是南北各自找機房，通過大量的測試找出中間通訊順暢的兩個機房，后一種通常來說成本較低，但效果較差，維護不便。另外DNS負載均衡也是廣泛使用的一種負載均衡方法，通過并列的多條A記錄將訪問隨即的分布到多臺前端服務器上，這種通常使用在靜態(tài)頁面居多的應用上，幾大門戶內容部分的前端很多都是用的這種方法。用戶被定位到正確的服務器群組后，應用程序就接手用戶的請求，并開始沿著定義好的業(yè)務邏輯進行處理。這些請求主要包括兩類靜態(tài)文件（圖片，js腳本,csSg），動態(tài)請求。靜態(tài)請求一般使用squid進行緩存處理，可以根據(jù)應用的規(guī)模采用不同的緩存配置方案，可以是一級緩存，也可以是多級緩存，一般情況下cache的命中率可以達到70%左右，能夠比較有效的提升服務器處理能力。Apache的deflat模塊可以壓縮傳輸數(shù)據(jù)，提高速度，2.0版本以后的cache模塊也內置實現(xiàn)磁盤和內存的緩存，而不必要一定做反向代理。動態(tài)請求目前一般有兩種處理方式，一種是靜態(tài)化，在頁面發(fā)生變化時重新靜態(tài)頁面，現(xiàn)在大量的CMS，BBS都采用這種方案，加上cache，可以提供較快的訪問速度。這種通常是寫操作較少的應用比較適合的解決方案。另一種解決辦法是動態(tài)緩存，所有的訪問都仍然通過應用處理，只是應用處理的時候會更多的使用內存，而不是數(shù)據(jù)庫。通常訪問數(shù)據(jù)庫的操作是極慢的，而訪問內存的操作很快，至少是一個數(shù)量級的差距，使用memcached可以實現(xiàn)這一解決方案，做的好的memcache甚至可以達到90%以上的緩存命中率。10年前我用的還是2M的內存，那時的一本雜事上曾經(jīng)風趣的描述一對父子的對話：兒子：爸爸，我想要1G的內存。爸爸：兒子，不行，即使是你過生日也不行。時至今日，大內存的成本已經(jīng)完全可以承受。Google使用了大量的PC機建立集群用于數(shù)據(jù)處理，而我一直覺得，使用大內存PC可以很低成本的解決前端甚至中間的負載問題。由于PC硬盤壽命比較短，速度比較慢，CPU也稍慢，用于做web前端既便宜，又能充分發(fā)揮大內存的優(yōu)勢，而且壞了的話只需要替換即可，不存在數(shù)據(jù)的遷移問題。下面就是應用的設計。應用在設計的時候應當盡量的設計成支持可擴展的數(shù)據(jù)庫設計，數(shù)據(jù)庫可以動態(tài)的添加，同時支持內存緩存，這樣的成本是最低的。另外一種應用設計的方法是采用中間件，例如ICE。這種方案的優(yōu)點是前端應用可以設計的相對簡單，數(shù)據(jù)層對于前端應用透明，由ICE提供，數(shù)據(jù)庫分布式的設計在后端實現(xiàn)，使用ICE封裝后給前端應用使用，這路設計對每一部分設計的要求較低，將業(yè)務更好的分層，但由于引入了中間件，分了更多層，實現(xiàn)起來成本也相對較高。在數(shù)據(jù)庫的設計上一方面可以使用集群，一方面進行分組。同時在細節(jié)上將數(shù)據(jù)庫優(yōu)化的原則盡量應用，數(shù)據(jù)庫結構和數(shù)據(jù)層應用在設計上盡量避免臨時表的創(chuàng)建、死鎖的產(chǎn)生。數(shù)據(jù)庫優(yōu)化的原則在網(wǎng)上比較常見，多google-下就能解決問題。在數(shù)據(jù)庫的選擇上可以根據(jù)自己的習慣選擇，OracleMySQL等，并非0甜己。就夠解決所有的問題，也并非MySQL就代表小應用，合適的就是最好的。前面講的都是基于軟件的性能設計方案，實際上硬件的良好搭配使用也可以有效的降低時間成本，以及開發(fā)維護成本，只是在這里我們不再展開。網(wǎng)站架構的設計是一個整體的工程，在設計的時候需要考慮到性能，可括展性，硬件成本，時間成本等等，如何根據(jù)業(yè)務的定位，資金，時間，人員的條件設計合適的方案是件比較困難的事情，但多想多實踐，終究會建立一套適合自己的網(wǎng)站設計理念，用于指導網(wǎng)站的設計工作，為網(wǎng)站的發(fā)展奠定良好的基礎。從LiveJournal后臺發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法于敦德2006-3-16一、LiveJourna發(fā)展歷程LiveJournal是99年始于校園中的項目，幾個人出于愛好做了這樣一個應用，以實現(xiàn)以下功能:博客，論壇社會性網(wǎng)絡，找到朋友聚合，把朋友的文章聚合在一起LiveJournal采用了大量的開源軟件，甚至它本身也是一個開源軟件。在上線后，LiveJournal實現(xiàn)了非?？焖俚脑鲩L：2004年4月份：280萬注冊用戶。2005年4月份：680萬注冊用戶。2005年8月份：790萬注冊用戶。達到了每秒鐘上千次的頁面請求及處理。使用了大量MySQL服務器。使用了大量通用組件。二、LiveJourna架構現(xiàn)狀概況netweb4web4三、從LiveJournal展中學習LiveJournal從1臺服務器發(fā)展到100臺服務器，這其中經(jīng)歷了無數(shù)的傷痛，但同時也摸索出了解決這些問題的方法，通過對LiveJournal的學習，可以讓我們避免LJ曾經(jīng)犯過的錯誤，并且從一開始就對系統(tǒng)進行良好的設計，以避免后期的痛苦。下面我們一步一步看LJ發(fā)展的腳步。1、一臺服務器一臺別人捐助的服務器，LJ最初就跑在上面，就像Google開始時候用的破服務器一樣，值得我們尊敬。這個階段，LJ的人以驚人的速度熟悉的Unix的操作管理，服務器性能出現(xiàn)過問題，不過還好，可以通過一些小修小改應付過去。在這個階段里LJ把CGI升級到了FastCGI。最終問題出現(xiàn)了，網(wǎng)站越來越慢，已經(jīng)無法通過優(yōu)過化來解決的地步，需要更多的服務器，這時LJ開始提供付費服務，可能是想通過這些錢來購買新的服務器，以解決當時的困境。毫無疑問，當時LJ存在巨大的單點問題，所有的東西都在那臺服務器的鐵皮盒子里裝著。

2、兩臺服務器用付費服務賺來的錢LJ買了兩臺服務器：一臺叫做Kenny的Dell6U機器用于提供Web服務，一臺叫做Cartman的Dell6U服務器用于提供數(shù)據(jù)庫服務。、有了更大的磁盤，更多的計算資源。但同時網(wǎng)絡結構還是非常簡單，每臺機器兩塊網(wǎng)卡，Cartman通過內網(wǎng)為Kenny提供MySQL數(shù)據(jù)庫服務。暫時解決了負載的問題，新的問題又出現(xiàn)了：原來的一個單點變成了兩個單點。沒有冷備份或熱備份。網(wǎng)站速度慢的問題又開始出現(xiàn)了，沒辦法，增長太快了。Web服務器上CPU達到上限，需要更多的Web服務器。3、四臺服務器又買了兩臺，Kyle和Stan，這次都是1U的，都用于提供Web服務。目前LJ一共有3臺Web服務器和一臺數(shù)據(jù)庫服務器。這時需要在3臺Web服務器上進行負載均橫。

單點故障。數(shù)據(jù)庫和用于做網(wǎng)關的Web服務器都是單點，一旦任何一臺機器出現(xiàn)問題將導致所有服務不可用。雖然用于做網(wǎng)關的Web服務器可以通過保持心跳同步迅速切換，但還是無法解決數(shù)據(jù)庫的單點，LJ當時也沒做這個。網(wǎng)站又變慢了，這次是因為IO和數(shù)據(jù)庫的問題，問題是怎么往應用里面添加數(shù)據(jù)庫呢？4、五臺服務器又買了一臺數(shù)據(jù)庫服務器。在兩臺數(shù)據(jù)庫服務器上使用了數(shù)據(jù)庫同步（Mysql支持的Master-Slave模式），寫操作全部針對主數(shù)據(jù)庫（通過Binlog，主服務器上的寫操作可以迅速同步到從服務器上），讀操作在兩個數(shù)據(jù)庫上同時進行（也算是負載均橫的一種吧）。讀操作數(shù)據(jù)庫選擇算法處理，要選一個當前負載輕一點的數(shù)據(jù)庫。在從數(shù)據(jù)庫服務器上只能進行讀操作

準備好應對同步過程中的延遲，處理不好可能會導致數(shù)據(jù)庫同步的中斷。只需要對寫操作進行判斷即可，讀操作不存在同步問題。5、更多服務器有錢了，當然要多買些服務器。部署后快了沒多久，又開始慢了。這次有更多的Web服務器，更多的數(shù)據(jù)庫服務器，存在IO與CPU爭用。于是采用了BIG-IP作為負載均衡解決方案。6、現(xiàn)在我們在哪里:net.現(xiàn)在服務器基本上夠了，但性能還是有問題，原因出在架構上。數(shù)據(jù)庫的架構是最大的問題。由于增加的數(shù)據(jù)庫都是以Slave模式添加到應用內，這樣唯一的好處就是將讀操作分布到了多臺機器，但這樣帶來的后果就是寫操作被大量分發(fā)，每臺機器都要執(zhí)行，服務器越多，浪費就越大，隨著寫操作的增加，用于服務讀操作的資源越來越少。w/1server500w/1server500ready's200writ攻&由一臺分布到兩臺最終效果現(xiàn)在我們發(fā)現(xiàn)，我們并不需要把這些數(shù)據(jù)在如此多的服務器上都保留一份。服務器上已經(jīng)做了RAID，數(shù)據(jù)庫也進行了備份，這么多的備份完全是對資源的浪費，屬于冗余極端過度。那為什么不把數(shù)據(jù)分布存儲呢？最終效果問題發(fā)現(xiàn)了，開始考慮如何解決。現(xiàn)在要做的就是把不同用戶的數(shù)據(jù)分布到不同的服務器上進行存儲，以實現(xiàn)數(shù)據(jù)的分布式存儲，讓每臺機器只為相對固定的用戶服務，以實現(xiàn)平行的架構和良好的可擴展性。為了實現(xiàn)用戶分組，我們需要為每一個用戶分配一個組標記，用于標記此用戶的數(shù)據(jù)存放在哪一組數(shù)據(jù)庫服務器中。每組數(shù)據(jù)庫由一個master及幾個slave組成，并且slave的數(shù)量在2-3臺，以實現(xiàn)系統(tǒng)資源的最合理分配，既保證數(shù)據(jù)讀操作分布，又避免數(shù)據(jù)過度冗余以及同步操作對系統(tǒng)資源的過度消耗。,almostresemblestoday'sarchitecture豈心球/豈*fnsnd!1*由一臺（一組）中心服務器提供用戶分組控制。所有用戶的分組信息都存儲在這臺機器上，所有針對用戶的操作需要先查詢這臺機器得到用戶的組號，然后再到相應的數(shù)據(jù)庫組中獲取數(shù)據(jù)。這樣的用戶架構與目前LJ的架構已經(jīng)很相像了。在具體的實現(xiàn)時需要注意幾個問題：在數(shù)據(jù)庫組內不要使用自增ID，以便于以后在數(shù)據(jù)庫組之間遷移用戶，以實現(xiàn)更合理的I/O,磁盤空間及負載分布。將userid，postid存儲在全局服務器上，可以使用自增，數(shù)據(jù)庫組中的相應值必須以全局服務器上的值為）隹。全局服務器上使用事務型數(shù)據(jù)庫InnoDB。在數(shù)據(jù)庫組之間遷移用戶時要萬分小心，當遷移時用戶不能有寫操作。7、現(xiàn)在我們在哪里net.GlobalDatabase問題:GlobalDatabase一個全局主服務器，掛掉的話所有用戶注冊及寫操作就掛掉。每個數(shù)據(jù)庫組一個主服務器，掛掉的話這組用戶的寫操作就掛掉。數(shù)據(jù)庫組從服務器掛掉的話會導致其它服務器負載過大。對于Master-Slave模式的單點問題，LJ采取了Master-Master模式來解決。所謂Master-Master實際上是人工實現(xiàn)的，并不是由MySQL直接提供的，實際上也就是兩臺機器同時是Master，也同時是Slave，互相同步。Master-Master實現(xiàn)時需要注意：一個Master出錯后恢復同步，最好由服務器自動完成。

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

6、現(xiàn)在我們在哪里:現(xiàn)在服務器基本上夠了，但性能還是有問題，原因出在架構上。數(shù)據(jù)庫的架構是最大的問題。由于增加的數(shù)據(jù)庫都是以Slave模式添加到應用內，這樣唯一的好處就是將讀操作分布到了多臺機器，但這樣帶來的后果就是寫操作被大量分發(fā)，每臺機器都要執(zhí)行，服務器越多，浪費就越大，隨著寫操作的增加，用于服務讀操作的資源越來越少。*1ywW2柏ns由一臺分布到兩臺最終效果現(xiàn)在我們發(fā)現(xiàn)，我們并不需要把這些數(shù)據(jù)在如此多的服務器上都保留一份。服務器上已經(jīng)做了RAID，數(shù)據(jù)庫也進行了備份，這么多的備份完全是對資源的浪費，屬于冗余極端過度。那為什么不把數(shù)據(jù)分布存儲呢？問題發(fā)現(xiàn)了，開始考慮如何解決?，F(xiàn)在要做的就是把不同用戶的數(shù)據(jù)分布到不同的服務器上進行存儲，以實現(xiàn)數(shù)據(jù)的分布式存儲，讓每臺機器只為相對固定的用戶服務，以實現(xiàn)平行的架構和良好的可擴展性。為了實現(xiàn)用戶分組，我們需要為每一個用戶分配一個組標記，用于標記此用戶的數(shù)據(jù)存放在哪一組數(shù)據(jù)庫服務器中。每組數(shù)據(jù)庫由一個master及幾個slave組成，并且slave的數(shù)量在2-3臺，以實現(xiàn)系統(tǒng)資源的最合理分配，既保證數(shù)據(jù)讀操作分布，又避免數(shù)據(jù)過度冗余以及同步操作對系統(tǒng)資源的過度消耗。由一臺（一組）中心服務器提供用戶分組控制。所有用戶的分組信息都存儲在這臺機器上，所有針對用戶的操作需要先查詢這臺機器得到用戶的組號，然后再到相應的數(shù)據(jù)庫組中獲取數(shù)據(jù)。這樣的用戶架構與目前LJ的架構已經(jīng)很相像了。在具體的實現(xiàn)時需要注意幾個問題：在數(shù)據(jù)庫組內不要使用自增ID，以便于以后在數(shù)據(jù)庫組之間遷移用戶，以實現(xiàn)更合理的I/O,磁盤空間及負載分布。將userid，postid存儲在全局服務器上，可以使用自增，數(shù)據(jù)庫組中的相應值必須以全局服務器上的值為準。全局服務器上使用事務型數(shù)據(jù)庫InnoDB。在數(shù)據(jù)庫組之間遷移用戶時要萬分小心，當遷移時用戶不能有寫操作。7、現(xiàn)在我們在哪里問題：一個全局主服務器，掛掉的話所有用戶注冊及寫操作就掛掉。每個數(shù)據(jù)庫組一個主服務器，掛掉的話這組用戶的寫操作就掛掉。數(shù)據(jù)庫組從服務器掛掉的話會導致其它服務器負載過大。對于Master-Slave模式的單點問題，LJ采取了Master-Master模式來解決。所謂Master-Master實際上是人工實現(xiàn)的，并不是由MySQL直接提供的，實際上也就是兩臺機器同時是Master，也同時是Slave，互相同步。Master-Master實現(xiàn)時需要注意：一個Master出錯后恢復同步，最好由服務器自動完成。數(shù)字分配，由于同時在兩臺機器上寫，有些ID可能會沖突。解決方案：奇偶數(shù)分配ID，一臺機器上寫奇數(shù)，一臺機器上寫偶數(shù)通過全局服務器進行分配（LJ采用的做法）。Master-Master模式還有一種用法，這種方法與前一種相比，仍然保持兩臺機器的同步，但只有一臺機器提供服務（讀和寫），在每天晚上的時候進行輪換，或者出現(xiàn)問題的時候進行切換。8、現(xiàn)在我們在哪里現(xiàn)在插播一條廣告，MylSAMVSInnoDB。使用InnoDB:支持事務需要做更多的配置，不過值得，可以更安全的存儲數(shù)據(jù)，以及得到更快的速度。使用MyISAM:記錄日志（LJ用它來記網(wǎng)絡訪問日志）存儲只讀靜態(tài)數(shù)據(jù)，足夠快。并發(fā)性很差，無法同時讀寫數(shù)據(jù)（添加數(shù)據(jù)可以）MySQL非正常關閉或死機時會導致索引錯誤，需要使用myisamchk修復，而且當訪問量大時出現(xiàn)非常頻繁。9、緩存去年我寫過一篇文章介紹memcached，它就是由LJ的團隊開發(fā)的一款緩存工具，以key-value的方式將數(shù)據(jù)存儲到分布的內存中。LJ緩存的數(shù)據(jù)：12臺獨立服務器（不是捐贈的）28個實例30GB總容量90-93%的命中率（用過squid的人可能知道，squid內存加磁盤的命中率大概在70-80%）如何建立緩存策略？想緩存所有的東西？那是不可能的，我們只需要緩存已經(jīng)或者可能導致系統(tǒng)瓶頸的地方，最大程度的提交系統(tǒng)運行效率。通過對MySQL的日志的分析我們可以找到緩存的對象。緩存的缺點？沒有完美的事物，緩存也有缺點：增大開發(fā)量，需要針對緩存處理編寫特殊的代碼。管理難度增加，需要更多人參與系統(tǒng)維護。當然大內存也需要錢。10、Web訪問負載均衡在數(shù)據(jù)包級別使用BIG-IP，但BIG-IP并不知道我們內部的處理機制，無法判斷由哪臺服務器對這些請求進行處理。反向代理并不能很好的起到作用，不是已經(jīng)夠快了，就是達不到我們想要的效果。所以，LJ又開發(fā)了Perlbal。特點：快，小，可管理的httpweb服務器/代理可以在內部進行轉發(fā)使用Perl開發(fā)單線程，異步，基于事件，使用epoll,kqueue支持Console管理與http遠程管理，支持動態(tài)配置加載多種模式：web服務器，反向代理，插件支持插件：GIF/PNG互換？11、MogileFSLJ使用開源的MogileFS作為分布式文件存儲系統(tǒng)。MogileFS使用非常簡單，它的主要設計思想是：文件屬于類（類是最小的復制單位）跟蹤文件存儲位置在不同主機上存儲使用MySQL集群統(tǒng)一存儲分布信息大容易廉價磁盤到目前為止就這么多了，更多文檔可以在/words/找到。D和LiveJ的同學們拿這個文檔參加了兩次MySQLCon，兩次OSCon，以及眾多的其它會議，無私的把他們的經(jīng)驗分享出來，值得我們學習。在web2.0時代快速開發(fā)得到大家越來越多的重視，但良好的設計仍是每一個應用的基礎，希望we