1、如何使用Varnish來加速網站訪問
第一種方法，利用緩存插件。越來越多的站長構架網站已經不再自己寫程序，而是使用比較完善的現成CMS作為框架結構，比如用到WORDPRESS。網上提供的一些常用CMS功能是非常完美的，但需要單獨再設置才能夠更加完美的適合我們的網站，提高網站速度。這就需要使用緩存插件來實現。比如WP-
Supercache，W3-TotalCache這兩款插件是我們必須安裝的緩存插件，可以有效的提高網站速度。
第二種方法，使用CDN加速。近一年CDN已經在我們個人站長中聽的較多，也有很多朋友在使用。CDN的全稱是Content Delivery
Network，解釋為內容分發網路。原理思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。也就是網站加速器，這個需要付費使用的，免費的不是太穩定。
第三種方法，優化代碼，減少臃腫結構。如果我們使用較為流行的CMS這方便應該不會有臃腫的代碼結構存在，但需要注意的是我們在製作或者選擇網站模
板的時候也會存在不合理的結構。我們需要在寫模板或者程序的時候使用較為簡潔的程序框架，簡潔有利於用戶體驗，也更利於搜索引擎蜘蛛的爬行和抓取。
第四種方法，刪除相關插件。有些站長在構架網站的時候喜歡用很多插件實現特別的效果，我們要知道自己製作的網站的目的是為了讓搜索引擎更加優化，抓
取更多的頁面獲得更好的排名效果。而不是採用多麼絢麗的效果。插件過多，也會影響我們網站的訪問速度和資料庫的讀取速度。插件盡量控制在4個之內。能不用插件的就不要用插件實現。
第五種方法，減少社會化標簽按鈕的數量。WEB2.0網站越來越多，我們為了把自己的網站也融入到2.0系統中會在自己的網站加入更多的社會化網站
按鈕。但是由於這些數據都是遠程調用的，載入需要很長的時間，從而減慢了我們網站的訪問速度。我個人建議大家不要加入社會化書簽，如果要加入也要加入那些
載入速度快的網站平台。
第六種方法，拒絕載入額外的評論系統。最近我也看到很多提供第三方評論的網站平台，可以提供評論服務，看似不錯可以減少我們網站的數據量和垃圾評
論，但是我們也可以看到載入後速度慢了很多。如果對方的速度還可以，都沒有太大問題，如果速度慢，那就影響很大。所以，我建議，不要加入第三方平台。
第七種方法，禁止Gravatar頭像。Gravatar頭像載入也比較浪費資源，我們沒有必要載入Gravatar頭像，雖然好看一些，但沒有必要。可能在網站流量小，評論少看不出來影響效果，如果評論多會明顯感覺到速度很慢。
第八種方法，減少圖片大小和數量。我們盡量在上傳網站圖片的時候減少圖片的大小和尺寸，可以在上傳圖片之前對圖片進行壓縮處理，圖片適當尺碼即可，不要過大。圖片僅僅是網站的點綴，而不需要都是圖文。同時，我們也盡量避免使用大量的視頻或者音頻內容。
第九種方法，開啟GZip壓縮功能。一般的主機都支持GZip壓縮功能。我們需要利用好主機提供給我們的功能，開啟壓縮可以提高網站的訪問速度，一般主機都是免費提供的，但很多人都沒有開啟。
第十種方法，減少JavaScript腳本文件，盡量存放在一個文件中。盡量外部調用JS代碼，不要放在網頁中，更不要遠程調用外部的JS代碼。例
如Google建議您載入在HEAD標簽的分析。您也可以嘗試結合的JavaScript和壓縮他們更快地載入。有些時候我們在頭部的CSS，JS代碼太
多，導致中間內容部分載入太慢。所以盡量減少頭部的代碼。
2、varnish 最大並發可以到多少
-p 後跟參數為了進行優化 -w 最小最大線程和超時
http://linux.chinaunix.net/techdoc/net/2007/09/06/967227.shtml
cu論壇里有
3、varnish 內存最大設置多大
varnish 內存最大設置2G。
Varnish是一個輕量級的Cache和反向代理軟體，先進的設計理念和成熟的設計框架是Varnish的主要特點，現在的Varnish總共代碼量不大，功能上雖然在不斷改進，但是還需要繼續豐富和加強。下面總結了Varnish的一些特點：
（1）是基於內存緩存，重啟後數據將消失。
（2）利用虛擬內存方式，io性能好。
（3）支持設置0~60秒內的精確緩存時間。
（4）VCL配置管理比較靈活。
（5）32位機器上緩存文件大小為最大2G。
（6）具有強大的管理功能，例如top，stat，admin，list等。
（7）狀態機設計巧妙，結構清晰。
（8）利用二叉堆管理緩存文件，達到積極刪除目的。
Varnish的Storage方式可分為兩種：
1）Malloc 通過malloc獲取內存。
2）Mmap file 創建大文件，通過二分法分段映射成1G以內的大塊。
Varnish進程的工作模式：
varnish啟動或有2個進程 master(management)進程和child(worker)進程。master讀入存儲配置命令，進行初始化，然後fork，監控child。child則分配線程進行cache工作，child還會做管理線程和生成很多worker線程。
child進程主線程初始化過程中，將存儲大文件整個載入到內存中，如果該文件超出系統的虛擬內存，則會減少原來配置mmap大小，然後繼續載入，這時候創建並初始化空閑存儲結構體，放在存儲管理的struct中，等待分配。
接著varnish某個負責介面新http連接的線程開始等待用戶，如果有新的http連接，但是這個線程只負責接收，然後喚醒等待線程池中的work線程，進行請求處理。
worker線程讀入uri後，將會查找已有的object，命中直接返回，沒有命中，則會從後端伺服器中取出來，放到緩存中。如果緩存已滿，會根據LRU演算法，釋放舊的object。對於釋放緩存，有一個超時線程會檢測緩存中所有object的生命周期，如果緩存過期（ttl），則刪除，釋放相應的存儲內存。
4、LINUX平台上怎麼安裝varnish
安裝Varnish網站緩存加速器（Linux系統）：
1、創建www用戶和組，及Varnish緩存文件存放目錄（/var/vcache）：
/usr/sbin/groupadd
www -g 48
/usr/sbin/useradd -u 48 -g www www
mkdir -p /var/vcache
chmod
+w /var/vcache
chown -R www:www
/var/vcache
2、創建Varnish日誌目錄（/var/logs/）：
mkdir
-p /var/logs
chmod +w /var/logs
chown -R www:www
/var/logs
3、編譯安裝varnish：
wget
warnish官網下載
tar
zxvf varnish-1.1.2.tar.gz
cd varnish-1.1.2
./configure
--prefix=/usr/local/varnish
make && make
install
4、創建Varnish配置文件：
vi
/usr/local/varnish/vcl.conf
輸入以下內容：
引用
backend myblogserver {
set backend.host =
"192.168.0.5";
set backend.port = "80";
}
acl purge {
"localhost";
"127.0.0.1";
"192.168.1.0"/24;
}
sub vcl_recv {
if (req.request ==
"PURGE") {
if (!client.ip ~ purge) {
error 405 "Not allowed.";
}
lookup;
}
if (req.http.host ~ "^blog.s135.com") {
set
req.backend = myblogserver;
if (req.request != "GET"
&& req.request != "HEAD") {
pipe;
}
else {
lookup;
}
}
else {
error 404 "Zhang Yan Cache
Server";
lookup;
}
}
sub vcl_hit {
if (req.request == "PURGE") {
set obj.ttl = 0s;
error 200 "Purged.";
}
}
sub vcl_miss {
if
(req.request == "PURGE") {
error 404 "Not in cache.";
}
}
sub vcl_fetch {
if (req.request == "GET" &&
req.url ~ "\.(txt|js)$") {
set obj.ttl = 3600s;
}
else {
set obj.ttl = 30d;
}
}
即(1)、Varnish通過反向代理請求後端IP為192.168.0.5，埠為80的web伺服器；
(2)、Varnish允許localhost、127.0.0.1、192.168.0.***三個來源IP通過PURGE方法清除緩存；
(3)、Varnish對域名為blog.s135.com的請求進行處理，非blog.s135.com域名的請求則返回「Zhang
Yan Cache
Server」；
(4)、Varnish對HTTP協議中的GET、HEAD請求進行緩存，對POST請求透過，讓其直接訪問後端Web伺服器。之所以這樣配置，是因為POST請求一般是發送數據給伺服器的，需要伺服器接收、處理，所以不緩存；
(5)、Varnish對以.txt和.js結尾的URL緩存時間設置1小時，對其他的URL緩存時間設置為30天。
5、啟動Varnish
ulimit
-SHn 51200
/usr/local/varnish/sbin/varnishd -n /var/vcache -f
/usr/local/varnish/vcl.conf -a 0.0.0.0:80 -s
file,/var/vcache/varnish_cache.data,1G -g www -u www -w 30000,51200,10 -T
127.0.0.1:3500 -p
client_http11=on
6、啟動varnishncsa用來將Varnish訪問日誌寫入日誌文件：
/usr/local/varnish/bin/varnishncsa
-n /var/vcache -w /var/logs/varnish.log
&
7、配置開機自動啟動Varnish
vi
/etc/rc.local
在末尾增加以下內容：
引用
ulimit -SHn 51200
/usr/local/varnish/sbin/varnishd
-n /var/vcache -f /usr/local/varnish/vcl.conf -a 0.0.0.0:80 -s
file,/var/vcache/varnish_cache.data,1G -g www -u www -w 30000,51200,10 -T
127.0.0.1:3500 -p client_http11=on
/usr/local/varnish/bin/varnishncsa -n
/var/vcache -w /var/logs/youvideo.log
&
8、優化Linux內核參數
vi
/etc/sysctl.conf
在末尾增加以下內容：
引用
net.ipv4.tcp_fin_timeout =
30
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_syncookies =
1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle =
1
net.ipv4.ip_local_port_range = 5000 65000
5、CloudFoundry何時可以支持綁定域名
[譯注]本文翻譯自CloudFoundry英文博客站點，原文題為「」，文章發表時間是2012年09月13日。使用雲的價值主張是「一切因此而簡單」。但構建和操作大規模的雲卻絕非易事。As正如MarkLucovsky在他的最新訪談中所言：「誰說大規模分布式系統簡單？」盡管像CloudFoundry這樣的解決方案使構建核心雲技術不再那麼令人生畏，但仍然不是件容易的事。在這篇嘉賓博文中，AppFog的創始人和CEOLucasCarlson講述了如何使用CloudFoundry開源PaaS技術建立AppFog的歷程以及在這一過程中的收獲核心雲技術高深莫測運行基於CloudFoundry的簡單服務並不是難事。查看MicroCloudFoundryTM。構建一個適合生產和企業工作負荷的服務相當困難。要構建含有一個API端點的基於CloudFoundry的服務，該服務在4個以上的獨立基礎結構供應商的6個以上不同可用性區域中運行，適合於生產和企業工作負荷，具有一定規模和一般可用性？目前這真的很難。快馬加鞭推行CloudFoundry正如您可以設想到的那樣，自從AppFog宣布GA以來，人們一直在問我們怎樣去做。我們是如何解決怎樣將針對CloudFoundry提供、為跨多個雲、多個可用區域以及多個供應商提供一個可共用界面的公共雲擴大規模的？首先：CloudFoundry代碼庫確實很不錯。由於選擇使用CloudFoundry進行構建，我們不必面對此類項目可能出現的很多潛在嚴峻挑戰和消耗大量時間的問題。其次：我們能夠從CloudFoundry生態系統內的工具、代碼和服務所獲得的益處顯著加快了我們的開發速度。第三：擁有GA中已經存在並具有一定規模而且並非基於CloudFoundry的公共PaaS是我們的一個重要促進因素。我們具有實現強大的PaaS所需要的內部操作經驗。AppFog的操作經驗對我們來說非常寶貴。盡管PaaS與NoOps趨勢緊密結合，但NoOps並不意味著無操作，而只是對開發人員而言無操作。正如每一個曾運行過CloudFoundry的人員所知，很多操作對於運行PaaS都必不可少而且很重要。最為重要的是，我們擁有一個有成千上萬的開發人員（PHPFog的用戶）參與的充滿活力的社區供我們咨詢，在從內部測試版到公共測試版直至GA的過程中幫助我們定義、測試及改進AppFog。悉心傾聽，交付所成正是這個社區幫助我們了解了AppFog的GA的發展目標、需要的工作方式以及我們的目標定價。開發人員對我們的要求如下：能夠跨數十個或數百個負載平衡的實例上輕松擴展應用程序，甚至免費版也是如此必須在基礎結構中最快的伺服器上運行應用程序（例如M2.4XL）必須能夠跨多個基礎結構（Rackspace、HP、AWS、Azure，並且無價格差異）運行應用程序必須簡化定價。沒有稀奇古怪的打包和組合以及名稱。簡單而且價格合理，最重要的是公正。在雲中實現真正的互操作性，包括運供應商之間的一鍵式零代碼遷移，從而消除了所有供應商鎖定痕跡目標是30秒部署到AWS、Rackspace、HP、Azure等等。支持CloudFoundry代碼庫中的任意及所有語言支持任意及所有關系數據存儲和NoSQL數據存儲這是一個令人生畏的列表。但這正是開發人員所需要的。因此讓我們面對現實…我們事實上是如何做到的呢？如何圍繞CloudFoundry構建PaaS這是個復雜的過程。幸運的是，幾個月前，JeremyVoorhis在倫敦QCon做了一個報告，敘述了AppFog如何將CloudFoundryOSS位與我們自有的自定義擴展和增強功能集並用，來構建商用系統。這無疑是了解從CloudFoundry到AppFog的發展歷程的最好開端。此報告的幻燈片位於此處，視頻位於此處。在此，我們不逐一回顧Jeremy歷時近一小時的講話，但我們要討論一些要點。首先，Jeremy澄清了一些關於「CloudFoundry」這一標志的混淆之處。一方面，CloudFoundry.com是VMware提供的託管PaaS，運行在vSphere虛擬平台上，該平台基於CloudFoundry.org中的開源項目。VMware還公開了其用來管理CloudFoundry.com-CloudFoundryBOSH-的工具的源代碼，並公開了其託管服務生產環境中的BOSH版本。我們不在託管VMware服務上進行，而是從同一個開源CloudFoundry項目構建。這種分布式開源系統使團隊能夠在其生命周期內在雲中管理及部署應用程序和服務，這是AppFog服務的核心。由於我們構建了一個基礎結構不可知的CloudFoundry服務，因此AppFog在當前的CloudFoundry生態系統中是獨一無二的。CloudFoundry的好處在於，基本上它可以與從基於OpenStack的IaaS（如Rackspace或HP）到AWS、Joyent、Citrix等等所提供的基礎結構相結合來實現。這種固有的多雲可移植性就是CloudFoundry項目如此鼓舞人心的原因所在。對於我們而言，在應用程序的生命周期內和多個基礎結構間部署和重新部署的能力是構建下一代PaaS的關鍵。我們認為，它還可以實現PaaS的以下基本使命：(a)促進產品團隊對開發的關注；(b)在應用程序生命周期內形成更短的反饋周期；(c)提供接近即時水平擴展性的可能性。CloudFoundry在雲計算革新中的作用即使是對於通常而言精通雲計算領域的人，回顧歷史發展環境也非常重要。對我們AppFog人而言，CloudFoundry已提供了一些重要的構建基礎來構成首個下一代PaaS。但是，這對我們有何意義？首先，了解一些背景信息很重要。PaaS最初是在一些歷史性突破的基礎上應運而生的，例如：20世紀90年代在Rackspace等公司出現數據中心。21世紀前十年的早期在VMware出現伺服器虛擬化21世紀前十年的中期AWS在虛擬化資源中引入API最近出現的DevOps範例及其關聯和派生的工具，例如Puppet和Chef。但只是在過去兩年，這條發展路線才開始真正走向成熟。像CloudFoundry和OpenStack這樣的工具已產生，並能夠對整個應用程序生命周期進行管理。這意味著「平台即服務」中的「平台」現在可以包含開發之外的應用程序生命周期的所有方面。Jeremy在報告中將此稱為「NoOps」。其含義絕非是再也無人去執行操作，而是操作工作的職責已傳遞到平台層，並且在應用程序生命周期的大部分時間（如果不是全部生命周期）會保留在該層。如果沒有像CloudFoundry這樣包羅萬象的工具，我們永遠也不能逾越第一代PaaS平台與下一代PaaS（如AppFog）之間的鴻溝，前者對於基礎結構管理而言實質上與用於（難以控制的）基礎結構管理的網關相比只是略有改進，而後者為用戶帶來的好處則要全面得多。AppFog對CloudFoundry的修正AppFog從為託管CloudFoundry生態系統提供強大的用戶界面和多雲體驗入手開始工作。我們在CloudFoundry代碼庫和成型的PaaS產品之間遇到了許多障礙。盡管當前的Cloudfoundry.org項目集成了CLI和各種IDE，但我們還著眼於全面的用戶體驗，包括快速注冊、Web控制台以及我們稱為Jumpstart、附加組件等等的構建前示例應用程序。盡管一些CloudFoundry用戶確實覺得從命令行、Eclipse或SpringToolSuite來操作系統（就像很多AppFog用戶的做法一樣）非常習慣，但我們還是希望為用戶提供直觀而又別具一格的控制台，用來管理他們的所有應用程序。下面是AppFog控制台的一個示例：系統創建者希望CloudFoundry對於事物的UX端處於一種不可知的狀態，而且不希望使其UX實現過於武斷。我們知道，簡單和直觀並不是最終目的，而在基於低於標準的基礎系統生成簡潔的UX是很容易的事情。但還有很多方面需要進行探尋，以滿足盡可能多用戶的需求，我們相信我們已經做到了這一點。以下是我們在CloudFoundry的頂層和下層所引入的一些創新舉措：基於Varnish的緩存層，用於顯著提高速度從一個基於CF的基礎結構一鍵克隆到另一個基礎結構，實現真正的工作負載可移植性CloudFoundryAPI兼容層，自動將請求路由到在空間的完全不同部分中運行的完全自治的CF實例跨數據中心的深度nagios集成，使我們在問題產生影響前就發現問題的存在此外，CloudFoundry使AppFog能夠創建非常完整的自通信體系結構。無論是在基礎結構級別還是其他級別，它還使我們能夠將AppFog設計為一個假定故障發生的系統，並提供一組處理故障的規程。翻開CloudFoundry新的一頁構建能夠跨多個雲的完全成熟的商用級別PaaS，並使其全部具有最高水準的最終用戶體驗，即使是從基本的CloudFoundry.org系統開始，也是一項宏大的事業。它需要一個極富開發人員敬業精神並全心投入的團隊，一個願意設身處地為客戶著想的團隊。但我們認為值得為這樣的成果付出。我們非常幸運能夠擁有像CloudFoundry這樣的核心系統。我們以多種方式進行回報，包括為項目添加初始PHP運行時支持，並在優化CloudFoundry使其能夠在公共雲中良好運行的過程中不斷進行回饋。對於AppFog轉向GA，我們的激動之情難以言表。對於已經注冊並開發了千千萬萬個應用程序的千千萬萬個開發人員，我們更是無比興奮。我們認為，AppFog的成功不僅僅證明了PaaS的強大，還證明了CloudFoundry代碼庫的力度及其開源生態系統和社區的強大。這不僅僅是AppFog的勝利，更是為CloudFoundry的成功做出貢獻的每一個人的勝利。關於作者：LucasCarlson是一位創業家和專業程序員，擅長開發具備一定規模的Web應用程序。Lucas是主要跨雲PaaS公司AppFog的創始人和CEO。他撰寫了十多個Ruby庫，並為包括Rails和RedCloth在內的多個重要Rails產品做出了貢獻。Lucas創立、主了廣受歡迎的RubyonRails競賽RailsDay並擔任評委，一直是很多重要編程會議中廣受歡迎的發言人。Lucas是MOG的第一位工程師，負責這一開創性音樂流服務的開發和技術指導。Lucas居住在俄勒岡州波特蘭，喜愛統計學和Go。
6、nginx lvs haproxy哪個用的多
一、lvs的優勢：
1、抗負載能力強，因為lvs工作方式的邏輯是非常之簡單，而且工作在網路4層僅做請求分發之用，沒有流量，所以在效率上基本不需要太過考慮。在我手裡的 lvs，僅僅出過一次問題：在並發最高的一小段時間內均衡器出現丟包現象，據分析為網路問題，即網卡或linux2.4內核的承載能力已到上限，內存和 cpu方面基本無消耗。
2、配置性低，這通常是一大劣勢，但同時也是一大優勢，因為沒有太多可配置的選項，所以除了增減伺服器，並不需要經常去觸碰它，大大減少了人為出錯的幾率。
3、工作穩定，因為其本身抗負載能力很強，所以穩定性高也是順理成章，另外各種lvs都有完整的雙機熱備方案，所以一點不用擔心均衡器本身會出什麼問題，節點出現故障的話，lvs會自動判別，所以系統整體是非常穩定的。
4、無流量，上面已經有所提及了。lvs僅僅分發請求，而流量並不從它本身出去，所以可以利用它這點來做一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。
5、基本上能支持所有應用，因為lvs工作在4層，所以它可以對幾乎所有應用做負載均衡，包括http、資料庫、聊天室等等。
另：lvs也不是完全能判別節點故障的，譬如在wlc分配方式下，集群里有一個節點沒有配置VIP，會使整個集群不能使用，這時使用wrr分配方式則會丟掉一台機。目前這個問題還在進一步測試中。所以，用lvs也得多多當心為妙。
二、nginx和lvs作對比的結果
1、nginx工作在網路的7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下lvs並不具備這樣的功能，所以 nginx單憑這點可利用的場合就遠多於lvs了；但nginx有用的這些功能使其可調整度要高於lvs，所以經常要去觸碰觸碰，由lvs的第2條優點 看，觸碰多了，人為出問題的幾率也就會大。
2、nginx對網路的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區分內外網，如果是同時擁有內外網的 節點，就相當於單機擁有了備份線路；lvs就比較依賴於網路環境，目前來看伺服器在同一網段內並且lvs使用direct方式分流，效果較能得到保證。另 外注意，lvs需要向託管商至少申請多一個ip來做Visual IP，貌似是不能用本身的IP來做VIP的。要做好LVS管理員，確實得跟進學習很多有關網路通信方面的知識，就不再是一個HTTP那麼簡單了。
3、nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日誌列印出來。lvs的安裝和配置、測試就要花比較長的時間了，因為同上所述，lvs對網路依賴比較大，很多時候不能配置成功都是因為網路問題而不是配置問題，出了問題要解決也相應的會麻煩得多。
4、nginx也同樣能承受很高負載且穩定，但負載度和穩定度差lvs還有幾個等級：nginx處理所有流量所以受限於機器IO和配置；本身的bug也還是難以避免的；nginx沒有現成的雙機熱備方案，所以跑在單機上還是風險較大，單機上的事情全都很難說。
5、nginx可以檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點。目前lvs中 ldirectd也能支持針對伺服器內部的情況來監控，但lvs的原理使其不能重發請求。重發請求這點，譬如用戶正在上傳一個文件，而處理該上傳的節點剛 好在上傳過程中出現故障，nginx會把上傳切到另一台伺服器重新處理，而lvs就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能 會因此而惱火。
6、nginx對請求的非同步處理可以幫助節點伺服器減輕負載，假如使用apache直接對外服務，那麼出現很多的窄帶鏈接時apache伺服器將會佔用大 量內存而不能釋放，使用多一個nginx做apache代理的話，這些窄帶鏈接會被nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相 當多的內存佔用。這點使用squid也有相同的作用，即使squid本身配置為不緩存，對apache還是有很大幫助的。lvs沒有這些功能，也就無法能 比較。
7、nginx能支持http和email（email的功能估計比較少人用），lvs所支持的應用在這點上會比nginx更多。
在使用上，一般最前端所採取的策略應是lvs，也就是DNS的指向應為lvs均衡器，lvs的優點令它非常適合做這個任務。
重要的ip地址，最好交由lvs託管，比如資料庫的ip、webservice伺服器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給lvs託管是最為穩妥的，這樣做的唯一缺點是需要的VIP數量會比較多。
nginx可作為lvs節點機器使用，一是可以利用nginx的功能，二是可以利用nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比nginx弱不少了，性能上也有所遜色於nginx。
nginx也可作為中層代理使用，這一層面nginx基本上無對手，唯一可以撼動nginx的就只有lighttpd了，不過lighttpd目前還沒有 能做到nginx完全的功能，配置也不那麼清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個VIP和lvs是最完美的方案了。
nginx也可作為網頁靜態伺服器，不過超出了本文討論的范疇，簡單提一下。
具體的應用還得具體分析，如果是比較小的網站（日PV<1000萬），用nginx就完全可以了，如果機器也不少，可以用DNS輪詢，lvs所耗費的機器還是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用lvs。
****************************************************************************************************************
Nginx的優點:
性能好，可以負載超過1萬的並發。
功能多，除了負載均衡，還能作Web伺服器，而且可以通過Geo模塊來實現流量分配。
社區活躍，第三方補丁和模塊很多
支持gzip proxy
缺點:
不支持session保持。
對後端realserver的健康檢查功能效果不好。而且只支持通過埠來檢測，不支持通過url來檢測。
nginx對big request header的支持不是很好，如果client_header_buffer_size設置的比較小，就會返回400bad request頁面。
Haproxy的優點:
它的優點正好可以補充nginx的缺點。支持session保持，同時支持通過獲取指定的url來檢測後端伺服器的狀態。
支持tcp模式的負載均衡。比如可以給mysql的從伺服器集群和郵件伺服器做負載均衡。
缺點：
不支持虛擬主機(這個很傻啊)
目前沒有nagios和cacti的性能監控模板
LVS的優點:
性能好，接近硬體設備的網路吞吐和連接負載能力。
LVS的DR模式，支持通過廣域網進行負載均衡。這個其他任何負載均衡軟體目前都不具備。
缺點：
比較重型。另外社區不如nginx活躍。
*************************************************************************************
現在網路中常見的的負載均衡主要分為兩種：一種是通過硬體來進行進行，常見的硬體有比較昂貴的NetScaler、F5、Radware和Array等商用的負載均衡器，也有類似於LVS、Nginx、HAproxy的基於Linux的開源的負載均衡策略,
商用負載均衡裡面NetScaler從效果上比F5的效率上更高。對於負載均衡器來說，不過商用負載均衡由於可以建立在四~七層協議之上，因此適用 面更廣所以有其不可替代性，他的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小的網路服務來說暫時還沒有需要使用。
另一種負載均衡的方式是通過軟體：比較常見的有LVS、Nginx、HAproxy等，其中LVS是建立在四層協議上面的，而另外Nginx和HAproxy是建立在七層協議之上的，下面分別介紹關於
LVS：使用集群技術和Linux操作系統實現一個高性能、高可用的伺服器，它具有很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
LVS的特點是：
1、抗負載能力強、是工作在網路4層之上僅作分發之用，沒有流量的產生；
2、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率；
3、工作穩定，自身有完整的雙機熱備方案；
4、無流量，保證了均衡器IO的性能不會收到大流量的影響；
5、應用范圍比較廣，可以對所有應用做負載均衡；
6、LVS需要向IDC多申請一個IP來做Visual IP，因此需要一定的網路知識，所以對操作人的要求比較高。
Nginx的特點是：
1、工作在網路的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構；
2、Nginx對網路的依賴比較小；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的並發；
5、Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；
6、Nginx對請求的非同步處理可以幫助節點伺服器減輕負載；
7、Nginx能支持http和Email，這樣就在適用范圍上面小很多；
8、不支持Session的保持、對Big request header的支持不是很好，另外默認的只有Round-robin和IP-hash兩種負載均衡演算法。
HAProxy的特點是：
1、HAProxy是工作在網路7層之上。
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3、支持url檢測後端的伺服器出問題的檢測會有很好的幫助。
4、更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
5、單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6、HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
***********************************************************************************************
現在網站發展的趨勢對網路負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術：
第一階段：利用Nginx或者HAProxy進行單點的負載均衡，這一階段伺服器規模剛脫離開單伺服器、單資料庫的模式，需要一定的負載均衡，但是 仍然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx或者HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協議就可以。這時是第一選擇
第二階段：隨著網路服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用F5就是首要選擇，Nginx此時就作為LVS或者 F5的節點來使用，具體LVS或者F5的是選擇是根據公司規模，人才以及資金能力來選擇的，這里也不做詳談，但是一般來說這階段相關人才跟不上業務的提 升，所以購買商業負載均衡已經成為了必經之路。
第三階段：這時網路服務已經成為主流產品，此時隨著公司知名度也進一步擴展，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定製，以及降低成本來講開源的LVS，已經成為首選，這時LVS會成為主流。
最終形成比較理想的狀態為：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。
7、HTTP是如何工作的？
什麼是HTTP協議
HTTP 協議定義伺服器端和客戶端之間文件傳輸的溝通方式。目前HTTP協議的版本是Http1.1。RFC 2616描述了HTTP協議的具體信息。
這個協議已經成為瀏覽器和Web站點之間的標准。
當我上網的時候底層是如何進行交互的？
當訪問者點擊一個超鏈接的時候，將會給瀏覽器提交一個URL地址。通過這個URL地址，瀏覽器便知道去鏈接那個網站並去取得具體的頁面文件（也可能是一張圖片，一個pdf文件）。
HTTP工作的基礎就是，連接一個伺服器並開始傳輸文件到瀏覽器。
HTTP傳輸的基本過程
在http傳輸的過程中，被稱為客戶端的請求者向伺服器請求一個文件。
最基本的過程是:
1 客戶端連接一個主機；
2 伺服器接收連接,
3 客戶端請求一個文件,
4 伺服器發送一個應答.
實例
我們看幾個典型的過程
首先，我們想訪問本頁面。在瀏覽器上敲入「http://www.maketop.net/resource/rs_041112_02.php」.瀏覽器將連接www.maketop.net然後發送：
>> GET /resource/rs_041112_02.php Http1.1
>> Host: www.maketop.net
>> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
>> Accept-Language: en
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10
>> Connection: Keep-Alive
>>
解釋：瀏覽器請求頁面「/resource/rs_041112_02.php」。並使用HTTP1.1協議。並告訴伺服器你的瀏覽器是Firefox0.10。操作系統是Windows XP。 瀏覽器希望保持與www.maketop.net之間的連接，並請求獲得多的文件，包括網頁中的圖片。翻譯成語言上面是：
>> 用HTTP1.1協議獲得 /resource/rs_041112_02.php
>> 訪問的主機是: www.maketop.net
>> 接收的文件包括了: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
>> 使用的語言是: en
>> 接收的編碼方式（瀏覽器能夠解釋的）是: gzip, deflate
>> 用戶的瀏覽器信息:Windows XP的操作系統 Firefox/0.10的瀏覽器
>> 保持連接: 還要去圖片
>>
www.maketop.net的伺服器發出響應：
<< HTTP/1.1 200 OK
<< Date: Mon, 12 Mar 2004 19:12:16 GMT
<< Server: Apache/1.3.31 (Unix) mod_throttle/3.1.2
<< Last-Modified: Fri, 22 Sep 2004 14:16:18
<< ETag: "dd7b6e-d29-39cb69b2"
<< Accept-Ranges: bytes
<< Content-Length: 3369
<< Connection: close
<< Content-Type: text/html
<<
<< File content goes here
瀏覽器並從伺服器的響應中獲得伺服器的信息：比如運行在Apache。
上面翻譯成翻譯成語言上面就是
<< HTTP1.1協議方式有效
<< 當前時間是: Mon, 12 Mar 2004 19:12:16 GMT
<< 伺服器是: Apache/1.3.31 (Unix) mod_throttle/3.1.2
<< 最後一次修改: Fri, 22 Sep 2004 14:16:18
<< ETag: "dd7b6e-d29-39cb69b2"
<< Accept-Ranges: bytes
<< Content-Length: 3369
<< Connection: close
<< Content-Type: text/html
<<
<< File content goes here
8、varnish緩存可以做正向帶理嗎
arnish是一款高性能的開源HTTP加速器，挪威最大的在線報紙 erdens Gang 使用3台arnish代替了原來的12台Suid，性能比以前更好。但與老牌的suid相比，各有各的優劣勢，網上大量的相對比較只是在其個人對自己熟悉的應用的最大使用上的發揮而已，可能suid到了有能力的人手上才足以發揮最強大的威力arnish採用了「isual Page Cache」技術，在內存的利用上，arnish比Suid具有優勢，它避免了Suid頻繁在內存、磁碟中交換文件，性能要比Suid高。通過arnish管理埠，可以使用正則表達式快速、批量地清除部分緩存，這一點是Suid不能具備的。 本人就varnish的一些見解與配置方法做簡單的介紹與筆記實驗環境：Red Hat Enterprise Linux Server release 5.4 (Tikanga) 內核2.6.18-.el5yum install pcre-devel ##預先安裝一個軟體包，不然會提示錯誤tar zxvf varnish-2.1.3.tar.gzcd varnish-2.1.3 ./configure --prefix=/usr/local/varnish-2.1.3ke && ke install編輯配置文件，有模版，但太多注釋，最好自己新建一個vim /usr/local/varnish-2.1.3/etc/varnish/varnish.conf ############下面附上配置文件的內容及注釋########################http請求處理過程#1,receive請求入口狀態，根據vcl判斷pass還是lookup本地查詢#lookup，在hash表中查找數據，若找到則進入hit狀態，否則進入fetch狀態#pass，選擇後台，進入fetch狀態#fetch，對請求進行後端的獲取，發送請求，獲得數據，並進行本地存儲#deliver，將數據發送給客戶端，進入done#done,處理結束##########配置後端伺服器##############代碼 代碼如下:backend linuxidc01 { .host = "..1."; .port = ""; .probe = { .timeout = 5s; .interval = 2s; .window = 10; .threshold = 8; } }backend linuxidc02 { .host = "..1."; .port = ""; .probe = { .timeout = 5s; .interval = 2s; .window = 10; .threshold = 8; } }##############配置後端伺服器組，進行健康檢測6秒，使用random方式設置權重######## #########另一種方式round-robin則默認輪詢機制####################代碼 代碼如下:director linuxidc random { .retries = 6; { .backend = linuxidc02; .weight = 2; } { .backend = linuxidc01; .weight = 2; } }##########定義訪問列表，允許下列清除varnish緩存#######################代碼 代碼如下:acl local { "localhost"; ".0.0.1"; }########從url判斷針對哪類後面伺服器及緩存配置############################代碼 代碼如下:sub vcl_recv { if (re.http.host ~ "^linuxidc.vicp") #匹配域名跳轉後台伺服器 { set re.backend = linuxidc; } else { error "Unknown HostName!"; } if (re.reuest == "PURGE") #不允許非訪問控制列表內的IP清除varnish緩存 { if (!client.ip ~ local) { error "Not Allowed."; return (lookup); } } #清除url中有jpg等文件的cookie if (re.reuest == "GET" && re.url ~ "\.(jpg|png|gif|swf|jpeg|ico)$") { unset re.http.cookie; } #判斷re.http.X-Forwarded-For 如果前端有多重反向代理，這樣可以獲取客戶端IP。 if (re.http.x-forwarded-for) { set re.http.X-Forwarded-For = re.http.X-Forwarded-For ", " client.ip; } else { set re.http.X-Forwarded-For = client.ip; }##varnish實現圖片的防盜鏈# if (re.http.referer ~ ") # {# if ( !(re.http.referer ~ "" ||# re.http.referer ~ "" ) )# {# set re.http.host = "linuxidc.vicp";# set re.url = "/referer.jpg"; # }# return(lookup);# }# else {return(pass);} if (re.reuest != "GET" && re.reuest != "HEAD" && re.reuest != "PUT" && re.reuest != "POST" && re.reuest != "TRACE" && re.reuest != "OPTIONS" && re.reuest != "DELETE") { return (pipe); } #對非GET|HEAD請求的直接轉發給後端伺服器 if (re.reuest != "GET" && re.reuest != "HEAD") { return (pass); } ##對GET請求，且url里以.php和.php?結尾的，直接轉發給後端伺服器 if (re.reuest == "GET" && re.url ~ "\.(php)($|\?)") { return (pass); } ##對請求中有驗證及cookie，直接轉發給後端伺服器 if (re.http.Authorization || re.http.Cookie) { return (pass);} { ##除以上的訪問請求，從緩存中查找 return (lookup); } ##指定的font目錄不進行緩存 if (re.url ~ "^/fonts/") { return (pass); }}sub vcl_pipe { return (pipe); }##進入pass模式，請求被送往後端，後端返回數據給客戶端，但不進入緩存處理 sub vcl_pass { return (pass); }sub vcl_hash { set re.hash += re.url; if (re.http.host) { set re.hash += re.http.host; } else { set re.hash += server.ip; } return (hash); }##在lookup後如果在cache中找到請求的緩存，一般以下面幾個關鍵詞結束sub vcl_hit { if (!obj.cacheable) { return (pass); } return (deliver); } ##lookup後沒有找到緩存時調用，以下面幾個關鍵詞結束，及調用fetch參數重新測試是否加入緩存sub vcl_miss { return (fetch); }#讓varnish伺服器緩存的類型，從後端取得數據後調用sub vcl_fetch { if (!beresp.cacheable) { return (pass); } if (beresp.http.Set-Cookie) { return (pass); } ##WEB伺服器指明不緩存的內容，varnish伺服器不緩存 if (beresp.http.Prag ~ "no-cache" || beresp.http.Cache-Control ~ "no-cache" || beresp.http.Cache-Control ~ "private") { return (pass); } ##對訪問中get有包含jpg,png等格式的文件進行緩存，緩存時間為7天，s為秒 if (re.reuest == "GET" && re.url ~ "\.(js|css|mp3|jpg|png|gif|swf|jpeg|ico)$") { set beresp.ttl = 7d; } ##對訪問get中包含htm等靜態頁面，緩存秒 if (re.reuest == "GET" && re.url ~ "\/[0-9]\.htm$") { set beresp.ttl = s; } return (deliver); }####添加在頁面head頭信息中查看緩存命中情況########sub vcl_deliver { set resp.http.x-hits = obj.hits ; if (obj.hits > 0) { set resp.http.X-Cache = "HIT ctel-bbs"; } else { set resp.http.X-Cache = "MISS ctel-bbs"; } }#########################以上為 varnish的配置文件##########################創建用戶：groupadd useradd -g 創建 varnish_cache的緩存位置mkdir /data/varnish_cache啟動varnishulimit -SHn ####設置文件描述符，因為我的機子性能並不好，可以按照自己的配置去設置/usr/local/varnish-2.1.3/in/varnishd -u -g -f /usr/local/varnish-2.1.3/etc/varnish/varnish.conf -a 0.0.0.0:80 -s file,/data/varnish_cache/varnish_cache.data,M -w ,,10 -t -T .0.0.1:####-u 以什麼用運行 -g 以什麼組運行 -f varnish配置文件 -a 綁定IP和埠 -s varnish緩存文件位置與大小 -w 最小，最大線程和超時時間 -T varnish管理埠，主要用來清除緩存#結束varnishd進程pkill varnishd啟動varnishncsa用來將arnish訪問日誌寫入日誌文件：/usr/local/varnish-2.1.3/bin/varnishncsa -w /data/logs/varnish.log &每天0點運行，按天切割arnish日誌，生成一個壓縮文件，同時刪除上個月舊日誌的腳本（/var/logs/cutlog.sh）：vim /usr/local/varnish-2.1.3/etc/varnish/cut_varnish_log.sh寫入以下腳本：#!/bin/sh# This file run at 00:00date=$(date -d "yesterday" +"%Y-%m-%d")pkill -9 varnishncsamv /data/logs/varnish.log /data/logs/${date}.log/usr/local/varnish-2.1.3/bin/varnishncsa -w /data/logs/varnish.log &mkdir -p /data/logs/varnish/gzip -c /data/logs/${date}.log > /data/logs/varnish/${date}.log.gzrm -f /data/logs/${date}.logrm -f /data/logs/varnish/$(date -d "-1 month" +"%Y-%m*").log.gz定時任務：crontab -e00 00 * * * /usr/local/varnish-2.1.3/etc/varnish/cut_varnish_log.sh優化Linux內核參數vi /etc/sysctl.confnet.ipv4.tcp_fin_timeout = 30net.ipv4.tcp_keepalive_time = net.ipv4.tcp_syncookies = 1net.ipv4.tcp_tw_reuse = 1net.ipv4.tcp_tw_recycle = 1net.ipv4.ip_local_port_range = 使配置生效/in/sysctl -p通過arnish管理埠，使用正則表達式批量清除緩存清除所有緩存/usr/local/varnish-2.1.3/bin/varnishadm -T .0.0.1: url.purge *$清除ige目錄下所有緩存/usr/local/varnish-2.1.3/bin/varnishadm -T .0.0.1: url.purge /ige/.0.0.1: 為被清除緩存伺服器 為被清除的域名 /static/ige/tt.jsp 為被清除的url列表/usr/local/varnish-2.1.3/bin/varnishadm -T .0.0.1: purge "re.http.host ~ && re.url ~ /static/ige/tt.jsp"+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++一個清除Suid緩存的PHP函數代碼 代碼如下:<?php function purge($ip, $url) { $errstr = ''; $errno = ''; $fp = fsockopen ($ip, 80, $errno, $errstr, 2); if (!$fp) { return false; } else { $out = "PURGE $url HTTP/1.1\r\n"; $out .= "; $out .= "Connection: close\r\n\r\n"; fputs ($fp, $out); $out = fgets($fp , ); fclose ($fp); return true; } } purge("..0.4", "/index.php"); ?> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++配置開機自動啟動arnishvim /etc/rc.d/rc.local在末行寫入以下內容：ulimit -SHn /usr/local/varnish-2.1.3/in/varnishd -u -g -f /usr/local/varnish-2.1.3/etc/varnish/varnish.conf -a 0.0.0.0:80 -s file,/data/varnish_cache/varnish_cache.data,M -w ,,10 -t -T .0.0.1:/usr/local/varnish-2.1.3/bin/varnishncsa -w /data/logs/varnish.log &查看arnish伺服器連接數與命中率：/usr/local/varnish-2.1.3/bin/varnishstat以上為varnish的狀態， 0.00 0.06 Client reuests received 為服務端接收的客戶端請求次數 0.00 0.01 Cache hits 為命中緩存，從緩存中取得數據返回給客戶端的次數，即命中率11 0.00 0.00 Cache misses 為跳過pass緩存，從後端服務應用中取得數據返回給用戶的次數用help看看可以使用哪些arnish命令：/usr/local/varnish-2.1.3/bin/varnishadm -T .0.0.1: help