導讀：
上次我們以LiveJournal爲例詳細分析了一個小網站在一步一步的發展成爲大規模的網站中性能優化的方案，以解決在發展中由於負載增長而引起的性能問題，同時在設計網站架構的時候就從根本上避免或者解決這些問題。
今天我們來看一下在網站的設計上一些通常使用的解決大規模訪問，高負載的方法。我們將主要涉及到以下幾方面：
1、 前端負載
2、 業務邏輯層
3、 數據層
在LJ性能優化文章中我們提到對服務器分組是解決負載問題，實現無限擴展的解決方案。通常中我們會採用類似LDAP的方案來解決，這在郵件的服務器以及個人網站，博客的應用中都有使用，在Windows下面有類似的Active Directory解決方案。有的應用（例如博客或者個人網頁）會要求在二級域名解析的時候就將用戶定位到所屬的服務器羣組，這個時候請求還沒到應用上面，我們需要在DNS裏解決這個問題。這個時候可以用到一款軟件bind dlz，這是bind的一個插件，用於取代bind的文本解析配置文件。它支持包括LDAP，BDB在內的多種數據存儲方式，可以比較好的解決這個問題。
另外一種涉及到DNS的問題就是目前普遍存在的南北互聯互通的問題，通過bind9內置的視圖功能可以根據不同的IP來源解析出不同的結果，從而將南方的用戶解析到南方的服務器，北方的用戶解析到北方的服務器。這個過程中會碰到兩個問題，一是取得南北IP的分佈列表，二是保證南北服務器之間的通訊順暢。第一個問題有個笨辦法解決，從日誌裏取出所有的訪問者IP，寫一個腳本，從南北的服務器分別ping回去，然後分析結果，可以得到一個大致準確的列表，當然最好的辦法還是直到從運營商那裏拿到這份列表(update:參見這篇文章)。後一個問題解決辦法比較多，最好的辦法就是租用雙線機房，同一臺機器，雙IP，南北同時接入，差一些的辦法就是南北各自找機房，通過大量的測試找出中間通訊順暢的兩個機房，後一種通常來說成本較低，但效果較差，維護不便。
另外DNS負載均衡也是廣泛使用的一種負載均衡方法，通過並列的多條A記錄將訪問隨即的分佈到多臺前端服務器上，這種通常使用在靜態頁面居多的應用上，幾大門戶內容部分的前端很多都是用的這種方法。
用戶被定位到正確的服務器羣組後，應用程序就接手用戶的請求，並開始沿着定義好的業務邏輯進行處理。這些請求主要包括兩類靜態文件(圖片，js腳本,css等)，動態請求。
靜態請求一般使用squid進行緩存處理，可以根據應用的規模採用不同的緩存配置方案，可以是一級緩存，也可以是多級緩存，一般情況下cache的命中率可以達到70%左右，能夠比較有效的提升服務器處理能力。Apache的deflate模塊可以壓縮傳輸數據，提高速度，2.0版本以後的cache模塊也內置實現磁盤和內存的緩存，而不必要一定做反向代理。
動態請求目前一般有兩種處理方式，一種是靜態化，在頁面發生變化時重新靜態頁面，現在大量的CMS，BBS都採用這種方案，加上cache，可以提供較快的訪問速度。這種通常是寫操作較少的應用比較適合的解決方案。
另一種解決辦法是動態緩存，所有的訪問都仍然通過應用處理，只是應用處理的時候會更多的使用內存，而不是數據庫。通常訪問數據庫的操作是極慢的，而訪問內存的操作很快，至少是一個數量級的差距，使用memcached可以實現這一解決方案，做的好的memcache甚至可以達到90%以上的緩存命中率。10年前我用的還是2M的內存，那時的一本雜事上曾經風趣的描述一對父子的對話：
兒子：爸爸，我想要1G的內存。
爸爸：兒子，不行，即使是你過生日也不行。
時至今日，大內存的成本已經完全可以承受。Google使用了大量的PC機建立集羣用於數據處理，而我一直覺得，使用大內存PC可以很低成本的解決前端甚至中間的負載問題。由於PC硬盤壽命比較短，速度比較慢，CPU也稍慢，用於做web前端既便宜，又能充分發揮大內存的優勢，而且壞了的話只需要替換即可，不存在數據的遷移問題。
下面就是應用的設計。應用在設計的時候應當儘量的設計成支持可擴展的數據庫設計，數據庫可以動態的添加，同時支持內存緩存，這樣的成本是最低的。另外一種應用設計的方法是採用中間件，例如ICE。這種方案的優點是前端應用可以設計的相對簡單，數據層對於前端應用透明，由ICE提供，數據庫分佈式的設計在後端實現，使用ICE封裝後給前端應用使用，這路設計對每一部分設計的要求較低，將業務更好的分層，但由於引入了中間件，分了更多層，實現起來成本也相對較高。
在數據庫的設計上一方面可以使用集羣，一方面進行分組。同時在細節上將數據庫優化的原則儘量應用，數據庫結構和數據層應用在設計上儘量避免臨時表的創建、死鎖的產生。數據庫優化的原則在網上比較常見，多google一下就能解決問題。在數據庫的選擇上可以根據自己的習慣選擇，Oracle，MySQL等，並非Oracle就夠解決所有的問題，也並非MySQL就代表小應用，合適的就是最好的。
前面講的都是基於軟件的性能設計方案，實際上硬件的良好搭配使用也可以有效的降低時間成本，以及開發維護成本，只是在這裏我們不再展開。
網站架構的設計是一個整體的工程，在設計的時候需要考慮到性能，可括展性，硬件成本，時間成本等等，如何根據業務的定位，資金，時間，人員的條件設計合適的方案是件比較困難的事情，但多想多實踐，終究會建立一套適合自己的網站設計理念，用於指導網站的設計工作，爲網站的發展奠定良好的基礎。
yudunde 發表於 June 18, 2006 12:22 AM | Example
以往文章使用開源軟件，設計高性能可擴展網站
評論
Hi 敦德：
你的文章商業價值很高啊： 看匹配出來的廣告
北京博大網人－南北互聯互通虛擬主機
249元/年=100M空間+100M郵箱+域名。南北互聯互通，高速訪問。5年成功...
www.3271.cn
光明在線6年用戶超10萬－建網站面向全國
網站的設計：建網站980元，送域名空間，300種功能，網站自動生成，中...
www.aaawww.com
網站的設計－網站吧68元建站
提供網站的設計，NOON網站吧再掀自助網站風暴：超多功能上千頁面，全...
www.wangzhan8.com
信網－設計網站
360元建設網站，專業公司、多年經驗，按需訂製、非模板製作，贈送域名...
www.clxtech.com
NOON設計網站專家68元建站－諾凡
NOON網站吧（京ICP證041545號）設計網站，再掀自助建站風暴：超多功能...
www.wangzhan8.com
億速互聯－讓您的企業在網絡中更精彩
專業網站整體策劃、資深美工設計、豐富的網站建設經驗。面向全國提供...
www.cnes.com.cn
最近我在做上下文廣告方面的系統：近期看看有沒有合作的機會。你的育兒博客也是很有商業價值的內容。
Posted by: Che Dongat June 18, 2006 10:39 AM
哈哈，好的。我頁面上沒放廣告啊，你從哪裏查到的相關廣告?
Posted by: Donaldat June 18, 2006 11:27 AM
頂一下，其實很多時候我發現，瓶頸在數據庫上，
squid的方法不錯，但是很擔心被人當跳板。
順便說一句，google現在的集羣已經不是隻有 pc了
Posted by: 二孬 at June 19, 2006 07:20 PM
squid參數裏可以設置的，避免被用來做正向代理
Posted by: Donaldat June 20, 2006 09:18 AM
奇怪，爲什麼你和車東都沒有提到過是用LVS來做網站的負載均衡呢？？和DNS相比有什麼優缺點呢？
Posted by: 藍槐at June 28, 2006 11:51 AM
LVS目前應該還是主要用於在前端針對web server進行的分佈式擴展，其實用DNS輪循雖然效果差一點，但基本可以滿足要求。
"IPVS無法檢查到請求的內容再選擇服務器，這就要求後端服務器組提供相同的服務，不管請求被髮送到哪一臺服務器，返回結果都是一樣的。"這對於大部分都是動態請求的網站來說無法接受:)
它還有個七層交換的項目，目的就是解決這個問題，但開發的不太完善，用的也不多。
Posted by: Donaldat June 28, 2006 01:19 PM
對不起，我的網站開發經驗不是很豐富，想問一下什麼情況需要根據請求內容來選擇服務器呢？謝謝^_^
Posted by: 藍槐at June 30, 2006 11:26 AM
例如訪問用戶的短消息數據和訪問文章數據有時候是放在不同的應用服務器上處理的，這就叫根據請求內容來選擇不同的服務器。
本文轉自
http://www.example.net.cn/2006/06/open_source_high_performance.html
