大型Web應用運行時 PHP負載均衡指南
過去當運行一個大的web應用時候意味著需要運行一個大型的web服務器。因為你的應用吸引了大量的用戶，你將不得不在你的服務器里增加更多的內(nèi)存和處理器。今天，“大型服務器”模式已經(jīng)過去，取而代之的是大量的小服務器，使用各種各樣的負載均衡技術(shù)。
“更多小服務器”的優(yōu)勢超過過去的“大型服務器”模式體現(xiàn)在兩個方面：
1. 如果服務器宕機，那么負載均衡系統(tǒng)將停止請求到宕機的服務器，轉(zhuǎn)而分發(fā)負載到其他正常運行的服務器上。
2. 擴展你的服務器更加容易。你要做的僅僅是加入新的服務器到負載均衡系統(tǒng)。不需要中斷你的應用運行。
所以，把握住這個機會。當然，代價就是這要求你的應用開發(fā)時增加一點復雜度。這就是本文要覆蓋的內(nèi)容。
這時你可能對自己說:“但是我怎么知道我正在使用負載均衡呢？”。最誠實的回答是，如果你正在問這個問題，那么答案是你多半沒有在使用負載均衡系統(tǒng)并且你的系統(tǒng)不需要考慮這個問題。大多數(shù)情況，當應用成長足夠大的規(guī)模時，負載均衡就需要明確提出和設置了。然而，我也偶爾看見虛擬主機公司為客戶的應用做這個負載均衡，或者像下面描述的那樣要自己來做。
注意，我一直提“web應用”而不是website,這是想?yún)^(qū)分“web應用”是那些復雜的站點往往涉及服務器端編程和數(shù)據(jù)庫，而不是website那樣只顯示簡單的靜態(tài)內(nèi)容。
1. PHP文件
***個問題是，如果你有大量的小型服務器，你怎么把你的php文件上傳到所有的服務器上？有如下的方法供你參考：
◆分別上傳所有的文件到每一個服務器 , 這種方法帶來的問題是：想像一下你有20個服務器，那么上傳過程中這將很容易導致錯誤，并且更新時極有可能導致不同服務器上有不同版本的文件。
◆使用 ‘rsync ‘ (或類似的軟件) . 這樣的工具能同步本地目錄和多個遠程主機目錄上的文件。
◆使用版本控制軟件(如subversion ) . 這是我最喜歡的方法。用它可以很好地維護我得代碼，當發(fā)布我的應用時，可以在每一個服務器上運行svn update命令同步。這種方法也使切換服務器得代碼到過去的某一個版本更加容易。
◆使用一個文件服務器(你可能發(fā)現(xiàn)NFS 非常適合做這件事情). 這種方式是使用一個文件服務器來存放你的web應用. 當然，如果你的文件服務器宕機，那么多所有你的站點將不能使用。這時，你就需要花費更多的開支來恢復它。
選擇哪種方式依賴于你的需求和你掌握的技能。如果你使用版本控制系統(tǒng)，那么你可能得計劃一個方法如果同時執(zhí)行一個更新命令更新所有服務器上的代碼。然而，如果使用文件服務器，你就要實現(xiàn)一些失敗恢復機制，防止萬一服務器宕機導致請求失敗。
2. 文件上傳
當只有一臺服務器時，文件上傳不是一個問題。但是當我們有多臺服務器時，那么上傳的文件應該怎么存放呢？上傳文件的問題和跨服務器php文件存儲是類似的。下面是幾種可能的方案:
◆把文件存儲到數(shù)據(jù)庫中。大多數(shù)數(shù)據(jù)允許存儲二進制數(shù)據(jù)。當你請求文件下載時，訪問數(shù)據(jù)把二進制數(shù)據(jù)和相應的文件名和類型輸出給用戶。在使用這種方案前應該考慮數(shù)據(jù)庫怎樣存儲你的文件。該方法的問題在于如果數(shù)據(jù)庫服務器宕機將使文件不可用。
◆在一個文件服務器上存儲上傳的文件 . 與前面的介紹一樣，你要安裝一個文件服務器讓所有web服務器共享，把所有上傳的文件上傳到這里，上傳后所有的web服務器就都可以使用它。但是，如果文件服務器宕機，那么可能發(fā)生圖像文件下載中斷。
◆設計你自己的上傳機制傳輸文件到服務器到每一個服務器 . 這個方法沒有單個文件服務器或者數(shù)據(jù)庫方案的缺陷，但是將增加你代碼的復雜度。例如，如果上傳到多個服務器過程中，服務器宕機，你要怎么處理？
用數(shù)據(jù)庫存儲上傳文件但是設計一個文件緩存機制是一個不錯的方案。當服務器接收一個文件下載請求時，首先檢查緩存系統(tǒng)中是否有該文件，如果發(fā)現(xiàn)那么從緩存系統(tǒng)下載，否則從數(shù)據(jù)庫讀取并把它緩存到文件系統(tǒng)中。
3. 會話(Sessions)
如果你熟悉php的session 處理，你將可能知道默認情況下，它存儲session數(shù)據(jù)在服務器的臨時文件里。而且，這個文件僅僅在你請求處理的那個服務器上，但是接下來的請求可能被另外一個服務器處理，這將在另一個服務器上生成新的session。這導致session頻繁地不被識別，如登錄用戶總是要求重新登錄。
我推薦的方案是，要么重新php內(nèi)建的session處理機制存儲session數(shù)據(jù)到數(shù)據(jù)庫，或者實現(xiàn)你自己的機制保證發(fā)送一個用戶的請求到同一臺服務器。
4. 配置(Configuration)
盡管這個話題不是和php特別相關(guān)，我感覺還是有必要提及。當運行集群服務器時，用某種方法保持服務器之間的配置文件同步是一個好主意。如果配置文件不一致，可能導致一些非常奇怪的斷斷續(xù)續(xù)的行為導致很難排查這些問題。
我推薦使用版本控制系統(tǒng)單獨管理他們。這樣你可以為不同的項目安裝存儲不同的php配置文件，也可以保持所有服務器配置文件同步。
5. 日志(Logging)
像配置問題一樣，logging不是僅僅和php相關(guān)。但是對于保持服務器健康運行它仍然是非常重要的。沒有正確的logging系統(tǒng)，你怎么知道如果PHP代碼開始產(chǎn)生錯誤(在系統(tǒng)正式運行時，你總是關(guān)閉display_errors 設置，不是嗎?)
有幾種方法你可以實現(xiàn)logging：
1. 在每一個服務器上記錄日志。 這是最簡單的方法。每一個機器僅僅記錄一個文件。好處是簡單，可能只要很少的配置。但是，隨著服務器數(shù)量的增多，監(jiān)控每臺服務器上的日志文件將變得非常困難。
2. 記錄日志到一個共享 這種方法每一個服務器仍然有這個日志文件，但是他們通過共享機制被存儲在一個中央文件服務器上，這將使監(jiān)控日志變得更簡單。該方案的問題在于，如果文件服務器不可用將導致一個簡單的日志不能寫入問題最終導致整個應用崩潰。
3. 記錄日志到logging服務器 你可以使用一個logging軟件，如syslog 來把所有的日志寫到一個中央服務器。盡管這個方法要求更多的配置，但是他也提供了最健壯的方案。
【編輯推薦】
