用PHP來做負(fù)載均衡指南

1、用php來做負(fù)載均衡指南過去當(dāng)運行一個大的web應(yīng)用時候意味著需要運行一個大型的web服務(wù)器。由于你的應(yīng)用吸引了大量的用戶，你將不得不在你的服務(wù)器里增強更多的內(nèi)存和處理器。今日， 大型服務(wù)器 模式已經(jīng)過去，取而代之的是大量的小服務(wù)器，用法各式各樣的技術(shù)。 更多小服務(wù)器 的優(yōu)勢超過過去的 大型服務(wù)器 模式體現(xiàn)在兩個方面： 假如服務(wù)器宕機，那么負(fù)載均衡系統(tǒng)將停止哀求到宕機的服務(wù)器，轉(zhuǎn)而分發(fā)負(fù)載到其他正常運行的服務(wù)器上。 擴展你的服務(wù)器越發(fā)簡單。你要做的僅僅是加入新的服務(wù)器到負(fù)載均衡系統(tǒng)。不需要中斷你的應(yīng)用運行。 所以，掌握住這個機會。固然，代價就是這要求你的應(yīng)用開發(fā)時增強一點復(fù)雜度。這就是本文要籠

2、罩的內(nèi)容。 這時你可能對自己說： 但是我怎么知道我正在用法負(fù)載均衡呢？ 。最誠實的回答是，假如你正在問這個問題，那么答案是你多半沒有在用法負(fù)載均衡系統(tǒng)并且你的系統(tǒng)不需要考慮這個問題。大多數(shù)狀況，當(dāng)應(yīng)用成長足夠大的規(guī)模時，負(fù)載均衡就需要明確提出和設(shè)置了。然而，我也間或看見虛擬主機公司為客戶的應(yīng)用做這個負(fù)載均衡，或者像下面描述的那樣要自己來做。 注重，我向來提 web應(yīng)用 而不是website，這是想?yún)^(qū)別 web應(yīng)用 是那些復(fù)雜的站點往往涉及服務(wù)器端編程和數(shù)據(jù)庫，而不是website那樣只顯示容易的靜態(tài)內(nèi)容。 1. quo;rsy （或類似的軟件） 。 這樣的工具能同步本地名目和多個遠程主機名目上

3、的文件。 用法版本控制軟件（如bversion ） 。 這是我最喜愛的辦法。用它可以很好地維護我得代碼，當(dāng)發(fā)布我的應(yīng)用時，可以在每一個服務(wù)器上運行svn up同步。這種辦法也使切換服務(wù)器得代碼到過去的某一個版本越發(fā)簡單。 用法一個文件服務(wù)器（你可能發(fā)覺nfs 十分適合做這件事情）。 這種方式是用法一個文件服務(wù)器來存放你的web應(yīng)用。 固然，假如你的文件服務(wù)器宕機，那么多全部你的站點將不能用法。這時，你就需要花費更多的開支來復(fù)原它。 挑選哪種方式依靠于你的需求和你把握的技能。假如你用法版本控制系統(tǒng)，那么你可能得方案一個辦法假如同時執(zhí)行一個更新指令更新全部服務(wù)器上的代碼。然而，假如用法文件服務(wù)器，

4、你就要實現(xiàn)一些失敗復(fù)原機制，防止萬一服務(wù)器宕機導(dǎo)致哀求失敗。 2. 文件上傳 當(dāng)惟獨一臺服務(wù)器時，文件上傳不是一個問題。但是當(dāng)我們有多臺服務(wù)器時，那么上傳的文件應(yīng)當(dāng)怎么存放呢？上傳文件的問題和跨服務(wù)器php文件存儲是類似的。下面是幾種可能的計劃： 把文件存儲到數(shù)據(jù)庫中。大多數(shù)數(shù)據(jù)允許存儲二進制數(shù)據(jù)。當(dāng)你哀求文件下載時，拜訪數(shù)據(jù)把二進制數(shù)據(jù)和相應(yīng)的文件名和類型輸出給用戶。在用法這種計劃前應(yīng)當(dāng)考慮數(shù)據(jù)庫怎樣存儲你的文件。該辦法的問題在于假如數(shù)據(jù)庫服務(wù)器宕機將使文件不行用。 在一個文件服務(wù)器上存儲上傳的文件 。 與前面的介紹一樣，你要安裝一個文件服務(wù)器讓全部web服務(wù)器分享，把全部上傳的文件上傳到這

5、里，上傳后全部的web服務(wù)器就都可以用法它。但是，假如文件服務(wù)器宕機，那么可能發(fā)生圖像文件下載中斷。 設(shè)計你自己的上傳機制傳輸文件到服務(wù)器到每一個服務(wù)器 。 這個辦法沒有單個文件服務(wù)器或者數(shù)據(jù)庫計劃的缺陷，但是將增強你代碼的復(fù)雜度。例如，假如上傳到多個服務(wù)器過程中，服務(wù)器宕機，你要怎么處理？ 用數(shù)據(jù)庫存儲上傳文件但是設(shè)計一個文件緩存機制是一個不錯的計劃。當(dāng)服務(wù)器接收一個文件下載哀求時，首先檢查緩存系統(tǒng)中是否有該文件，假如發(fā)覺那么從緩存系統(tǒng)下載，否則從數(shù)據(jù)庫讀取并把它緩存到文件系統(tǒng)中。 3. 會話（sessions） 假如你認(rèn)識php的session 處理，你將可能知道默認(rèn)狀況下，它存儲sess

6、ion數(shù)據(jù)在服務(wù)器的暫時文件里。而且，這個文件僅僅在你哀求處理的那個服務(wù)器上，但是接下來的哀求可能被另外一個服務(wù)器處理，這將在另一個服務(wù)器上生成新的session。這導(dǎo)致session頻繁地不被識別，如登錄取戶總是要求重新登錄。 我推舉的計劃是，要么重新php內(nèi)建的session處理機制存儲session數(shù)據(jù)到數(shù)據(jù)庫，或者實現(xiàn)你自己的機制保證發(fā)送一個用戶的哀求到同一臺服務(wù)器。 4. 配置（configuration） 盡管這個話題不是和php特殊相關(guān)，我感覺還是有須要提及。當(dāng)運行服務(wù)器時，用某種辦法保持服務(wù)器之間的配置文件同步是一個好想法。假如配置文件不全都，可能導(dǎo)致一些十分驚奇的斷斷續(xù)續(xù)的行

7、為導(dǎo)致很難排查這些問題。 我推舉用法版本控制系統(tǒng)單獨管理他們。這樣你可以為不同的項目安裝存儲不同的php配置文件，也可以保持全部服務(wù)器配置文件同步。 5. 日志（logging） 像配置問題一樣，logging不是僅僅和php相關(guān)。但是對于保持服務(wù)器健康運行它仍然是十分重要的。沒有正確的logging系統(tǒng)，你怎么知道假如php代碼開頭產(chǎn)生錯誤（在系統(tǒng)正式運行時，你總是關(guān)閉display_errors 設(shè)置，不是嗎？） 有幾種辦法你可以實現(xiàn)logging： 在每一個服務(wù)器上記錄日志。 這是最容易的辦法。每一個機器僅僅記錄一個文件。益處是容易，可能只要很少的配置。但是，隨著服務(wù)器數(shù)量的增多，監(jiān)控每臺服務(wù)器上的日志文件將變得十分困難。 記錄日志到一個分享 這種辦法每一個服務(wù)器仍然有這個日志文件，但是他們通過分享機制被存儲在一個中心文件服務(wù)器上，這將使監(jiān)控日志變得更容易。該計劃的問題在于，假如文件服務(wù)器不行用將導(dǎo)致一個容易的日