目錄
1.網絡層架構
1.1 鏡像網站技術
1.2 CDN內容分發網絡——調整服務器的域名解析來實現
1.3 應用層分佈式設計——查詢、定向
2.交換層架構
2.1 第四層交換簡介
2.2 硬件實現
2.3 軟件實現——LVS，負載均衡
3.應用程序層優化
3.1 網站服務器程序的選擇
3.2 數據庫選擇——mysqL主輔、集羣設計
3.3 服務器端腳本解析器的選擇——JSP、PHP、ASP
3.4 可配置性
3.5 封裝和中間層思想
4.服務器優化（接收請求的服務器優化）
4.1 Socket優化——調相關內核參數，再用命令檢測效果
4.2 硬盤級緩存——squid
4.3 內存級緩存——memcached
4.4 CPU與IO均衡
4.5 讀寫分離——文件系統改進
5.擴容、容錯處理
5.1 擴容
5.2 容錯
1.網絡層架構
1.1 鏡像網站技術
鏡像網站是指將一個完全相同的站點放到幾個服務器上，分別有自己的URL，這些服務器上的網站互相稱爲鏡像網站［13］。鏡像網站和主站並沒有太大差別， 或者可以視爲主站的拷貝。鏡像網站的好處是：如果不能對主站作正常訪問（如服務器故障，網絡故障或者網速太慢等），仍能通過鏡像服務器獲得服務。不便之處 是：更新網站內容的時候，需要同時更新多個服務器；需要用戶記憶超過一個網址，或需要用戶選擇訪問多個鏡像網站中的一個，而用戶選擇的，不一定是最優的。 在用戶選擇的過程中，缺乏必要的可控性。
在互聯網發展的初期，互聯網上的網站內容很少，而且大都是靜態內容，更新頻率底。但因爲服務器運算能力低，帶寬小，網速慢，熱門網站的訪問壓力還是很大。 鏡像網站技術在這種情況下作爲一種有效解決方案，被廣泛採用。隨着互聯網的發展，越來越多的網站使用服務器端腳本動態生成內容，同步更新越來越困難，對可 控性要求越來越高，鏡像技術因爲不能滿足這類網站的需要，漸漸的淡出了人們的視線。但有一些大型的軟件下載站，因爲符合鏡像網站的條件——下載的內容是靜 態的，更新頻率較低，對帶寬，速度要求又比較高，如國外的SourceForge （http://www.SourceForge.net，著名開源軟件託管網站），Fedora（http://fedoraproject.org，RedHat贊助的Linux發行版），國內的華軍軟件園（http://www.onlinedown.net），天空軟件站（http://www.skycn.com）等，還在使用這項技術（圖1）。
1.2 CDN內容分發網絡
CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是通過在現有的互聯網中增加一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡“邊緣”，使用戶可以就近取得 所需的內容，分散服務器的壓力，解決互聯網擁擠的狀況，提高用戶訪問網站的響應速度。從而解決由於網絡帶寬小、用戶訪問量大、網點分佈不均等原因所造成的 用戶訪問網站響應速度慢的問題［14］。
CDN與鏡像網站技術的不同之處在於網站代替用戶去選擇最優的內容服務器，增強了可控制性。CDN其實是夾在網頁瀏覽者和被訪問的服務器中間的一層鏡像或 者說緩存，瀏覽者訪問時點擊的還是服務器原來的URL地址，但是看到的內容其實是對瀏覽者來說最優的一臺鏡像服務器上的頁面緩存內容。這是通過調整服務器 的域名解析來實現的。使用CDN技術的域名解析服務器需要維護一個鏡像服務器列表和一份來訪IP到鏡像服務器的對應表。當一個用戶的請求到來的時候，根據 用戶的IP，查詢對應表，得到最優的鏡像服務器的IP地址，返回給用戶。這裏的最優，需要綜合考慮服務器的處理能力，帶寬，離訪問者的距離遠近等因素。當 某個地方的鏡像網站流量過大，帶寬消耗過快，或者出現服務器，網絡等故障的時候，可以很方便的設置將用戶的訪問轉到另外一個地方（圖2）。這樣就增強了可 控制性。
CDN網絡加速技術也有它的侷限性。首先，因爲內容更新的時候，需要同步更新多臺鏡像服務器，所以它也只適用於內容更新不太頻繁，或者對實時性要 求不是很高的網站；其次，DNS解析有緩存，當某一個鏡像網站的訪問需要轉移時，主DNS服務器更改了IP解析結果，但各地的DNS服務器緩存更新會滯後 一段時間，這段時間內用戶的訪問仍然會指向該服務器，可控制性依然有不足。
目前，國內訪問量較高的大型網站如新浪、網易等的資訊頻道，均使用CDN網絡加速技術（圖3），雖然網站的訪問量巨大，但無論在什麼地方訪問，速度都會很快。但論壇，郵箱等更新頻繁，實時性要求高的頻道，則不適合使用這種技術。
1.3 應用層分佈式設計
新浪播客爲了獲得CDN網絡加速的優點，又必須避免CDN的不足，在應用層軟件設計上，採取了一個替代的辦法。新浪播客提供了一個供播放器查詢視頻文件地 址的接口。當用戶打開視頻播放頁面的時候，播放器首先連接查詢接口，通過接口獲得視頻文件所在的最優的鏡像服務器地址，然後再到該服務器去下載視頻文件。 這樣，用一次額外的查詢獲得了全部的控制性，而這次查詢的通訊流量非常小，幾乎可以忽略不計。CDN中由域名解析獲得的靈活性也保留了下來：由接口程序維 護鏡像網站列表及來訪IP到鏡像網站的對應表即可。鏡像網站中不需要鏡像所有的內容，而是隻鏡像更新速度較慢的視頻文件。這是完全可以承受的。
網絡層架構小結
從整個互聯網絡的高度來看網站架構，努力的方向是明確的：讓用戶就近取得內容，但又要在速度和可控制性之間作一個平衡。對於更新比較頻繁內容，由於難以保持鏡像網站之間的同步，則需要使用其他的輔助技術。
2.交換層架構
2.1 第四層交換簡介
第四層交換的一個簡單定義是：它是一種傳輸功能，它決定傳輸不僅僅依據MAC地址(第二層網橋)或源/目標IP地址(第三層路由)，而且依據IP 地址與 TCP/UDP (第四層) 應用端口號的組合（Socket）［17］。第四層交換功能就像是虛擬IP，指向實際的服務器。它傳輸的數據支持多種協議，有HTTP、FTP、NFS、 Telnet等。
以HTTP協議爲例，在第四層交換中爲每個服務器組設立一個虛擬IP（Virtue IP，VIP），每組服務器支持某一個或幾個域名。在域名服務器（DNS）中存儲服務器組的VIP，而不是某一臺服務器的真實地址。
當用戶請求頁面時，一個帶有目標服務器組的VIP連接請求發送給第四層交換機。第四層交換機使用某種選擇策略，在組中選取最優的服務器，將數據包中的目標 VIP地址用實際服務器的IP地址取代，並將連接請求傳給該服務器。第四層交換一般都實現了會話保持功能，即同一會話的所有的包由第四層交換機進行映射 後，在用戶和同一服務器間進行傳輸
2.2 硬件實現
2.3 軟件實現
軟件四層交換常用的有 Linux上的LVS（Linux Virtual Server），它提供了基於心跳（heart beat）的實時災難應對解決方案，提高了系統的魯棒性，同時提供了靈活的VIP配置和管理功能，可以同時滿足多種應用需求
3.應用程序層優化
3.1 網站服務器程序的選擇
經統計［40］，當前互聯網上有超過50%的網站主機使用Apache［41］服務器程序。 Apache是開源界的首選Web服務器，因爲它的強大和可靠，而且適用於絕大部分的應用場合。但是它的強大有時候卻顯得笨重，配置文件複雜得讓人望而生 畏，高併發情況下效率不太高。而輕量級的Web服務器Lighttpd［42］卻是後起之秀，基於單進程多路複用技術，其靜態文件的響應能力遠高於 Apache。 Lighttpd對PHP的支持也很好，還可以通過Fastcgi方式支持其他的語言，比如Python等。雖然Lighttpd是輕量級的服務器，功能 上不能跟Apache比，某些複雜應用無法勝任，但即使是大部分內容動態生成的網站，仍免不了會有一些靜態元素，比如圖片、JS腳本、CSS等等，可以考 慮將Lighttpd放在Squid的前面，構成 Lighttpd->Squid->Apache的一條處理鏈，Lighttpd在最前面，專門處理靜態內容的請求，把動態內容請求通過 Proxy模塊轉發給Squid，如果Squid中有該請求的內容且沒有過期，則直接返回給Lighttpd。新請求或者過期的頁面請求交由Apache 中的腳本程序來處理。經過Lighttpd和Squid的兩級過濾，Apache需要處理的請求大大減少，減少了Web應用程序的壓力。同時這樣的構架， 便於把不同的處理分散到多臺計算機上進行，由Lighttpd在前面統一分發。
在這種架構下，每一級都是可以進行單獨優化的，比如Lighttpd可以採用異步IO方式，Squid可以啓用內存來緩存，Apache可以啓用MPM （Multi -Processing Modules，多道處理模塊）等，並且每一級都可以使用多臺機器來均衡負載，伸縮性好。
著名視頻分享網站YouTube就是選擇使用Lighttpd作爲網站的前臺服務器程序。
3.2 數據庫選擇
MySQL提供多種後臺存儲引擎的選擇，如MyISAM， Heap， InnoDB，Berkeley Db等。缺省格式爲MyISAM。 MyISAM 存儲引擎與磁盤兼容的非常好
主輔結構
MySQL也有一些它自身的缺陷，如缺乏圖形界面，缺乏存儲過程， 還不支持觸發器，參照完整性，子查詢和數據表視圖等，但這些功能都在開發者的TO-DO列表當中。這就是開源的力量：你永遠可以期待更好。
國外的Yahoo!，國內的新浪，搜狐等很多大型商業網站都使用MySQL 作爲後臺數據庫。對於一般的網站系統，無論從成本還是性能上考慮，MySQL應該是最佳的選擇。
3.3 服務器端腳本解析器的選擇
3.4 可配置性
3.5 封裝和中間層思想
4.服務器優化
常見的影響服務器的處理速度的因素有：網絡連接，硬盤讀寫，內存空間，CPU速度。
4.1 Socket優化
GNU/Linux 提供了很多可調節的內核參數，可以使用這些參數爲服務器進行動態配置，包括影響 Socket 性能的一些重要的選項。這些選項包含在 /proc 虛擬文件系統中。這個文件系統中的每個文件都表示一個或多個參數，它們可以通過 cat工具進行讀取，或使用 echo 命令進行修改。這裏僅列出一些影響TCP/IP 棧性能的可調節內核參數
如果重啓了 GNU/Linux 系統，設置的內核參數都會恢復成默認值。爲了將所設置的值作爲這些參數的默認值，可以使用 /etc/rc.local 文件，在系統每次啓動時自動將這些參數配置成所需要的值。
4.2 硬盤級緩存——squid
硬盤級別的緩存是指將需要動態生成的內容暫時緩存在硬盤上，在一個可接受的延遲時間範圍內，同樣的請求不再動態生成，以達到節約系統資源，提高網 站承受能力的目的。Linux環境下硬盤級緩存一般使用Squid。當前的Squid可以處理HTTP， FTP， GOPHER， SSL和WAIS等協議。
Squid默認通過檢測HTTP協議頭的Expires和 Cache-Control字段來決定緩存的時間。
Squid 運行的時候，默認會在硬盤上建兩層hash目錄，用來存儲緩存的Object。它還會在內存中建立一個Hash Table，用來記錄硬盤中Object分佈的情況。如果Squid配置成爲一個Squid集羣中的一個的話，它還會建立一個 Digest Table(摘要表)，用來存儲其它 Squid 上的Object摘要。當用戶端想要的資料本地硬盤上沒有時，可以很快的知道應該去集羣中的哪一臺機器獲得。在硬盤空間快要達到配置限額的時候，可以配置 使用某種策略（默認使用LRU：Least Recently Used-最近最少用）刪除一些Object，從而騰出空間
集羣中的Squid Server 之間可以有兩種關係：第一種關係是：Child 和 Parent。當 Child Squid Server 沒有資料時，會直接向 Parent Squid Server 要資料，然後一直等，直到 Parent 給它資料爲止。第二種關係是：Sibling 和 Sibling。當 Squid Server 沒有資料時，會先向 Sibling 的 Squid Server 要資料，如果 Sibling 沒資料，就跳過它向 Parent 要或直接上原始網站去拿。
默認配置的Squid，沒有經過任何優化的時候，一般可以達到 50% 的命中率［30］（圖4）。如果需要，還可以通過參數優化，拆分業務，優化文件系統等辦法，使得Squid達到 90% 以上的緩存命中率。 Squid處理TCP連接消耗的服務器資源比真正的HTTP服務器要小的多，當Squid分擔了大部分連接，網站的承壓能力就大大增強了。
4.3 內存級緩存——memcached
Memcached也有它的不足。首先它的數據是保存在內存當中的，一旦服務進程重啓（進程意外被關掉，機器重啓等），數據會全部丟失。其次 Memcached以root權限運行，而且Memcached本身沒有任何權限管理和認證功能，安全性不足。第一條是Memcached作爲內存緩存服 務使用無法避免的，當然，如果內存中的數據需要保存，可以採取更改Memcached的源代碼，增加定期寫入硬盤的功能。對於第二條，我們可以將 Memcached服務綁定在內網IP上，通過Linux防火牆進行防護。
4.4 CPU與IO均衡
在一個網站提供的所有功能中，有的功能可能需要消耗大量的服務器端IO資源，像下載，視頻播放等，而有的功能則可能需要消耗大量的服務器CPU資 源，像視頻格式轉換，LOG統計等。在一個服務器集羣中，當我們發現某些機器上CPU和IO的利用率相差很大的時候，例如CPU負載很高而IO負責很低， 我們可以考慮將該服務器上的某些耗CPU資源的進程換成耗IO的進程，以達到均衡的目的。均衡每一臺機器的CPU和IO消耗，不僅可以獲得更充分的服務器 資源利用，而且還能夠支持暫時的過載，遇到突發事件，訪問流量劇增的時候， 實現得體的性能下降(Graceful performance degradation)［34］，而不是立即崩潰。
4.5 讀寫分離
總結
對於一個高併發高流量的網站來說，任何一個環節的瓶頸都會造成網站性能的下降，影響用戶體驗，進而造成巨大的經濟損失。在全互聯網層面，應該使用 分佈式設計，縮短網站與用戶的網絡距離，減少主幹網上的流量，以及防止在網絡意外情況下網站無法訪問的問題。在局域網層面，應該使用服務器集羣，一方面可 以支撐更大的訪問量，另一方面也作爲冗餘備份，防止服務器故障導致的網站無法訪問。在單服務器層面，應該配置操作系統，文件系統及應用層軟件，均衡各種資 源的消耗，消除系統性能瓶頸，充分發揮服務器的潛能。在應用層，可以通過各種緩存來提升程序的效率，減少服務器資源消耗（圖6）。另外，還需要合理設計應 用層程序，爲以後的需求變更，擴容做好準備。
在每一個層次，都需要考慮容錯的問題，嚴格消除單點故障，做到無論應用層程序錯誤，服務器軟件錯誤，服務器硬件錯誤，還是網絡錯誤，都不影響網站服務。
轉載自：http://www.linuxso.com/liuliang/9263.html
1.網絡層架構
1.1 鏡像網站技術
1.2 CDN內容分發網絡——調整服務器的域名解析來實現
1.3 應用層分佈式設計——查詢、定向
2.交換層架構
2.1 第四層交換簡介
2.2 硬件實現
2.3 軟件實現——LVS，負載均衡
3.應用程序層優化
3.1 網站服務器程序的選擇
3.2 數據庫選擇——mysqL主輔、集羣設計
3.3 服務器端腳本解析器的選擇——JSP、PHP、ASP
3.4 可配置性
3.5 封裝和中間層思想
4.服務器優化（接收請求的服務器優化）
4.1 Socket優化——調相關內核參數，再用命令檢測效果
4.2 硬盤級緩存——squid
4.3 內存級緩存——memcached
4.4 CPU與IO均衡
4.5 讀寫分離——文件系統改進
5.擴容、容錯處理
5.1 擴容
5.2 容錯
1.網絡層架構
1.1 鏡像網站技術
鏡像網站是指將一個完全相同的站點放到幾個服務器上，分別有自己的URL，這些服務器上的網站互相稱爲鏡像網站［13］。鏡像網站和主站並沒有太大差別， 或者可以視爲主站的拷貝。鏡像網站的好處是：如果不能對主站作正常訪問（如服務器故障，網絡故障或者網速太慢等），仍能通過鏡像服務器獲得服務。不便之處 是：更新網站內容的時候，需要同時更新多個服務器；需要用戶記憶超過一個網址，或需要用戶選擇訪問多個鏡像網站中的一個，而用戶選擇的，不一定是最優的。 在用戶選擇的過程中，缺乏必要的可控性。
在互聯網發展的初期，互聯網上的網站內容很少，而且大都是靜態內容，更新頻率底。但因爲服務器運算能力低，帶寬小，網速慢，熱門網站的訪問壓力還是很大。 鏡像網站技術在這種情況下作爲一種有效解決方案，被廣泛採用。隨着互聯網的發展，越來越多的網站使用服務器端腳本動態生成內容，同步更新越來越困難，對可 控性要求越來越高，鏡像技術因爲不能滿足這類網站的需要，漸漸的淡出了人們的視線。但有一些大型的軟件下載站，因爲符合鏡像網站的條件——下載的內容是靜 態的，更新頻率較低，對帶寬，速度要求又比較高，如國外的SourceForge （http://www.SourceForge.net，著名開源軟件託管網站），Fedora（http://fedoraproject.org，RedHat贊助的Linux發行版），國內的華軍軟件園（http://www.onlinedown.net），天空軟件站（http://www.skycn.com）等，還在使用這項技術（圖1）。
1.2 CDN內容分發網絡
CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是通過在現有的互聯網中增加一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡“邊緣”，使用戶可以就近取得 所需的內容，分散服務器的壓力，解決互聯網擁擠的狀況，提高用戶訪問網站的響應速度。從而解決由於網絡帶寬小、用戶訪問量大、網點分佈不均等原因所造成的 用戶訪問網站響應速度慢的問題［14］。
CDN與鏡像網站技術的不同之處在於網站代替用戶去選擇最優的內容服務器，增強了可控制性。CDN其實是夾在網頁瀏覽者和被訪問的服務器中間的一層鏡像或 者說緩存，瀏覽者訪問時點擊的還是服務器原來的URL地址，但是看到的內容其實是對瀏覽者來說最優的一臺鏡像服務器上的頁面緩存內容。這是通過調整服務器 的域名解析來實現的。使用CDN技術的域名解析服務器需要維護一個鏡像服務器列表和一份來訪IP到鏡像服務器的對應表。當一個用戶的請求到來的時候，根據 用戶的IP，查詢對應表，得到最優的鏡像服務器的IP地址，返回給用戶。這裏的最優，需要綜合考慮服務器的處理能力，帶寬，離訪問者的距離遠近等因素。當 某個地方的鏡像網站流量過大，帶寬消耗過快，或者出現服務器，網絡等故障的時候，可以很方便的設置將用戶的訪問轉到另外一個地方（圖2）。這樣就增強了可 控制性。
CDN網絡加速技術也有它的侷限性。首先，因爲內容更新的時候，需要同步更新多臺鏡像服務器，所以它也只適用於內容更新不太頻繁，或者對實時性要 求不是很高的網站；其次，DNS解析有緩存，當某一個鏡像網站的訪問需要轉移時，主DNS服務器更改了IP解析結果，但各地的DNS服務器緩存更新會滯後 一段時間，這段時間內用戶的訪問仍然會指向該服務器，可控制性依然有不足。
目前，國內訪問量較高的大型網站如新浪、網易等的資訊頻道，均使用CDN網絡加速技術（圖3），雖然網站的訪問量巨大，但無論在什麼地方訪問，速度都會很快。但論壇，郵箱等更新頻繁，實時性要求高的頻道，則不適合使用這種技術。
1.3 應用層分佈式設計
新浪播客爲了獲得CDN網絡加速的優點，又必須避免CDN的不足，在應用層軟件設計上，採取了一個替代的辦法。新浪播客提供了一個供播放器查詢視頻文件地 址的接口。當用戶打開視頻播放頁面的時候，播放器首先連接查詢接口，通過接口獲得視頻文件所在的最優的鏡像服務器地址，然後再到該服務器去下載視頻文件。 這樣，用一次額外的查詢獲得了全部的控制性，而這次查詢的通訊流量非常小，幾乎可以忽略不計。CDN中由域名解析獲得的靈活性也保留了下來：由接口程序維 護鏡像網站列表及來訪IP到鏡像網站的對應表即可。鏡像網站中不需要鏡像所有的內容，而是隻鏡像更新速度較慢的視頻文件。這是完全可以承受的。
網絡層架構小結
從整個互聯網絡的高度來看網站架構，努力的方向是明確的：讓用戶就近取得內容，但又要在速度和可控制性之間作一個平衡。對於更新比較頻繁內容，由於難以保持鏡像網站之間的同步，則需要使用其他的輔助技術。
2.交換層架構
2.1 第四層交換簡介
第四層交換的一個簡單定義是：它是一種傳輸功能，它決定傳輸不僅僅依據MAC地址(第二層網橋)或源/目標IP地址(第三層路由)，而且依據IP 地址與 TCP/UDP (第四層) 應用端口號的組合（Socket）［17］。第四層交換功能就像是虛擬IP，指向實際的服務器。它傳輸的數據支持多種協議，有HTTP、FTP、NFS、 Telnet等。
以HTTP協議爲例，在第四層交換中爲每個服務器組設立一個虛擬IP（Virtue IP，VIP），每組服務器支持某一個或幾個域名。在域名服務器（DNS）中存儲服務器組的VIP，而不是某一臺服務器的真實地址。
當用戶請求頁面時，一個帶有目標服務器組的VIP連接請求發送給第四層交換機。第四層交換機使用某種選擇策略，在組中選取最優的服務器，將數據包中的目標 VIP地址用實際服務器的IP地址取代，並將連接請求傳給該服務器。第四層交換一般都實現了會話保持功能，即同一會話的所有的包由第四層交換機進行映射 後，在用戶和同一服務器間進行傳輸
2.2 硬件實現
2.3 軟件實現
軟件四層交換常用的有 Linux上的LVS（Linux Virtual Server），它提供了基於心跳（heart beat）的實時災難應對解決方案，提高了系統的魯棒性，同時提供了靈活的VIP配置和管理功能，可以同時滿足多種應用需求
3.應用程序層優化
3.1 網站服務器程序的選擇
經統計［40］，當前互聯網上有超過50%的網站主機使用Apache［41］服務器程序。 Apache是開源界的首選Web服務器，因爲它的強大和可靠，而且適用於絕大部分的應用場合。但是它的強大有時候卻顯得笨重，配置文件複雜得讓人望而生 畏，高併發情況下效率不太高。而輕量級的Web服務器Lighttpd［42］卻是後起之秀，基於單進程多路複用技術，其靜態文件的響應能力遠高於 Apache。 Lighttpd對PHP的支持也很好，還可以通過Fastcgi方式支持其他的語言，比如Python等。雖然Lighttpd是輕量級的服務器，功能 上不能跟Apache比，某些複雜應用無法勝任，但即使是大部分內容動態生成的網站，仍免不了會有一些靜態元素，比如圖片、JS腳本、CSS等等，可以考 慮將Lighttpd放在Squid的前面，構成 Lighttpd->Squid->Apache的一條處理鏈，Lighttpd在最前面，專門處理靜態內容的請求，把動態內容請求通過 Proxy模塊轉發給Squid，如果Squid中有該請求的內容且沒有過期，則直接返回給Lighttpd。新請求或者過期的頁面請求交由Apache 中的腳本程序來處理。經過Lighttpd和Squid的兩級過濾，Apache需要處理的請求大大減少，減少了Web應用程序的壓力。同時這樣的構架， 便於把不同的處理分散到多臺計算機上進行，由Lighttpd在前面統一分發。
在這種架構下，每一級都是可以進行單獨優化的，比如Lighttpd可以採用異步IO方式，Squid可以啓用內存來緩存，Apache可以啓用MPM （Multi -Processing Modules，多道處理模塊）等，並且每一級都可以使用多臺機器來均衡負載，伸縮性好。
著名視頻分享網站YouTube就是選擇使用Lighttpd作爲網站的前臺服務器程序。
3.2 數據庫選擇
MySQL提供多種後臺存儲引擎的選擇，如MyISAM， Heap， InnoDB，Berkeley Db等。缺省格式爲MyISAM。 MyISAM 存儲引擎與磁盤兼容的非常好
主輔結構
MySQL也有一些它自身的缺陷，如缺乏圖形界面，缺乏存儲過程， 還不支持觸發器，參照完整性，子查詢和數據表視圖等，但這些功能都在開發者的TO-DO列表當中。這就是開源的力量：你永遠可以期待更好。
國外的Yahoo!，國內的新浪，搜狐等很多大型商業網站都使用MySQL 作爲後臺數據庫。對於一般的網站系統，無論從成本還是性能上考慮，MySQL應該是最佳的選擇。
3.3 服務器端腳本解析器的選擇
3.4 可配置性
3.5 封裝和中間層思想
4.服務器優化
常見的影響服務器的處理速度的因素有：網絡連接，硬盤讀寫，內存空間，CPU速度。
4.1 Socket優化
GNU/Linux 提供了很多可調節的內核參數，可以使用這些參數爲服務器進行動態配置，包括影響 Socket 性能的一些重要的選項。這些選項包含在 /proc 虛擬文件系統中。這個文件系統中的每個文件都表示一個或多個參數，它們可以通過 cat工具進行讀取，或使用 echo 命令進行修改。這裏僅列出一些影響TCP/IP 棧性能的可調節內核參數
如果重啓了 GNU/Linux 系統，設置的內核參數都會恢復成默認值。爲了將所設置的值作爲這些參數的默認值，可以使用 /etc/rc.local 文件，在系統每次啓動時自動將這些參數配置成所需要的值。
4.2 硬盤級緩存——squid
硬盤級別的緩存是指將需要動態生成的內容暫時緩存在硬盤上，在一個可接受的延遲時間範圍內，同樣的請求不再動態生成，以達到節約系統資源，提高網 站承受能力的目的。Linux環境下硬盤級緩存一般使用Squid。當前的Squid可以處理HTTP， FTP， GOPHER， SSL和WAIS等協議。
Squid默認通過檢測HTTP協議頭的Expires和 Cache-Control字段來決定緩存的時間。
Squid 運行的時候，默認會在硬盤上建兩層hash目錄，用來存儲緩存的Object。它還會在內存中建立一個Hash Table，用來記錄硬盤中Object分佈的情況。如果Squid配置成爲一個Squid集羣中的一個的話，它還會建立一個 Digest Table(摘要表)，用來存儲其它 Squid 上的Object摘要。當用戶端想要的資料本地硬盤上沒有時，可以很快的知道應該去集羣中的哪一臺機器獲得。在硬盤空間快要達到配置限額的時候，可以配置 使用某種策略（默認使用LRU：Least Recently Used-最近最少用）刪除一些Object，從而騰出空間
集羣中的Squid Server 之間可以有兩種關係：第一種關係是：Child 和 Parent。當 Child Squid Server 沒有資料時，會直接向 Parent Squid Server 要資料，然後一直等，直到 Parent 給它資料爲止。第二種關係是：Sibling 和 Sibling。當 Squid Server 沒有資料時，會先向 Sibling 的 Squid Server 要資料，如果 Sibling 沒資料，就跳過它向 Parent 要或直接上原始網站去拿。
默認配置的Squid，沒有經過任何優化的時候，一般可以達到 50% 的命中率［30］（圖4）。如果需要，還可以通過參數優化，拆分業務，優化文件系統等辦法，使得Squid達到 90% 以上的緩存命中率。 Squid處理TCP連接消耗的服務器資源比真正的HTTP服務器要小的多，當Squid分擔了大部分連接，網站的承壓能力就大大增強了。
4.3 內存級緩存——memcached
Memcached也有它的不足。首先它的數據是保存在內存當中的，一旦服務進程重啓（進程意外被關掉，機器重啓等），數據會全部丟失。其次 Memcached以root權限運行，而且Memcached本身沒有任何權限管理和認證功能，安全性不足。第一條是Memcached作爲內存緩存服 務使用無法避免的，當然，如果內存中的數據需要保存，可以採取更改Memcached的源代碼，增加定期寫入硬盤的功能。對於第二條，我們可以將 Memcached服務綁定在內網IP上，通過Linux防火牆進行防護。
4.4 CPU與IO均衡
在一個網站提供的所有功能中，有的功能可能需要消耗大量的服務器端IO資源，像下載，視頻播放等，而有的功能則可能需要消耗大量的服務器CPU資 源，像視頻格式轉換，LOG統計等。在一個服務器集羣中，當我們發現某些機器上CPU和IO的利用率相差很大的時候，例如CPU負載很高而IO負責很低， 我們可以考慮將該服務器上的某些耗CPU資源的進程換成耗IO的進程，以達到均衡的目的。均衡每一臺機器的CPU和IO消耗，不僅可以獲得更充分的服務器 資源利用，而且還能夠支持暫時的過載，遇到突發事件，訪問流量劇增的時候， 實現得體的性能下降(Graceful performance degradation)［34］，而不是立即崩潰。
4.5 讀寫分離
總結
對於一個高併發高流量的網站來說，任何一個環節的瓶頸都會造成網站性能的下降，影響用戶體驗，進而造成巨大的經濟損失。在全互聯網層面，應該使用 分佈式設計，縮短網站與用戶的網絡距離，減少主幹網上的流量，以及防止在網絡意外情況下網站無法訪問的問題。在局域網層面，應該使用服務器集羣，一方面可 以支撐更大的訪問量，另一方面也作爲冗餘備份，防止服務器故障導致的網站無法訪問。在單服務器層面，應該配置操作系統，文件系統及應用層軟件，均衡各種資 源的消耗，消除系統性能瓶頸，充分發揮服務器的潛能。在應用層，可以通過各種緩存來提升程序的效率，減少服務器資源消耗（圖6）。另外，還需要合理設計應 用層程序，爲以後的需求變更，擴容做好準備。
在每一個層次，都需要考慮容錯的問題，嚴格消除單點故障，做到無論應用層程序錯誤，服務器軟件錯誤，服務器硬件錯誤，還是網絡錯誤，都不影響網站服務。
轉載自：http://www.linuxso.com/liuliang/9263.html
