摘要
面試的時候的回答可以如下：在nginx裡面配置乙個upstream，然後把相關的伺服器ip都配置進去。然後採用輪詢的方案，然後在nginx裡面的配置項裡，proxy-pass指向這個upstream，這樣就能實現負載均衡。
nginx的負載均衡有4種模式：
1)、輪詢（預設）
每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
2)、weight
指定輪詢機率，weight和訪問比率成正比，用於後端伺服器效能不均的情況。
2)、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問乙個後端伺服器，可以解決session的問題。
3)、fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
4)、url_hash（第三方）
開啟nginx.cnf檔案
在http節點下新增upstream節點：
upstream webnameupstream webnameupstream webname然後在server節點下進行配置：
location /name這樣就基本完成了負載均衡的配置。
下面是主備的配置：
還是在upstream裡面
upstream webnameupstream webname負載均衡
先來簡單了解一下什麼是負載均衡，單從字面上的意思來理解就可以解釋n臺伺服器平均分擔負載，不會因為某台伺服器負載高宕機而某台伺服器閒置的情況。那麼負載均衡的前提就是要有多台伺服器才能實現，也就是兩台以上即可。
測試環境
由於沒有伺服器，所以本次測試直接host指定網域名稱，然後在vmware裡安裝了三颱centos。
測試網域名稱 ：a.com
a伺服器ip ：192.168.5.149 （主）
b伺服器ip ：192.168.5.27
c伺服器ip ：192.168.5.126
部署思路
a伺服器做為主伺服器，網域名稱直接解析到a伺服器（192.168.5.149）上，由a伺服器負載均衡到b伺服器（192.168.5.27）與c伺服器（192.168.5.126）上。
網域名稱解析
由於不是真實環境，網域名稱就隨便使用乙個a.com用作測試，所以a.com的解析只能在hosts檔案設定。
開啟：c:windowssystem32driversetchosts
在末尾新增
192.168
.5.149
a.com
從截圖上看已成功將a.com解析到192.168.5.149ip
a伺服器nginx.conf設定
開啟nginx.conf，檔案位置在nginx安裝目錄的conf目錄下。
在http段加入以下**
upstream a.com
server
}
b、c伺服器nginx.conf設定
開啟nginx.confi，在http段加入以下**
server測試 當訪問a.com的時候，為了區分是轉向哪台伺服器處理我分別在b、c伺服器下寫乙個不同內容的index.html檔案，以作區分。
開啟瀏覽器訪問a.com結果，重新整理會發現所有的請求均分別被主伺服器（192.168.5.149）分配到b伺服器（192.168.5.27）與c伺服器（192.168.5.126）上，實現了負載均衡效果。
b伺服器處理頁面
c伺服器處理頁面
假如其中一台伺服器死機會怎樣？
當某台伺服器宕機了，是否會影響訪問呢？
我們先來看看例項，根據以上例子，假設c伺服器192.168.5.126這台機子宕機了（由於無法模擬宕機，所以我就把c伺服器關機）然後再來訪問看看。
訪問結果：
我們發現，雖然c伺服器（192.168.5.126）宕機了，但不影響**訪問。這樣，就不會擔心在負載均衡模式下因為某台機子宕機而拖累整個站點了。
如果b.com也要設定負載均衡怎麼辦？
很簡單，跟a.com設定一樣。如下：
假設b.com的主伺服器ip是192.168.5.149，負載均衡到192.168.5.150和192.168.5.151機器上
現將網域名稱b.com解析到192.168.5.149ip上。
在主伺服器(192.168.5.149)的nginx.conf加入以下**：
upstream b.com
server
}
在192.168.5.150與192.168.5.151機器上設定nginx，開啟nginx.conf在末尾新增以下**：
server完成以後步驟後即可實現b.com的負載均衡配置。
主伺服器不能提供服務嗎？
以上例子中，我們都是應用到了主伺服器負載均衡到其它伺服器上，那麼主伺服器本身能不能也加在伺服器列表中，這樣就不會白白浪費拿一台伺服器純當做**功能，而是也參與到提供服務中來。
如以上案例三颱伺服器：
a伺服器ip ：192.168.5.149 （主）
b伺服器ip ：192.168.5.27
c伺服器ip ：192.168.5.126
我們把網域名稱解析到a伺服器，然後由a伺服器**到b伺服器與c伺服器，那麼a伺服器只做乙個**功能，現在我們讓a伺服器也提供站點服務。
我們先來分析一下，如果新增主伺服器到upstream中，那麼可能會有以下兩種情況發生：
1、主伺服器**到了其它ip上，其它ip伺服器正常處理；
2、主伺服器**到了自己ip上，然後又進到主伺服器分配ip那裡，假如一直分配到本機，則會造成乙個死迴圈。
怎麼解決這個問題呢？因為80埠已經用來監聽負載均衡的處理，那麼本伺服器上就不能再使用80埠來處理a.com的訪問請求，得用乙個新的。於是我們把主伺服器的nginx.conf加入以下一段**：
server既然能正常訪問，那麼我們就可以把主伺服器新增到upstream中，但是埠要改一下，如下**：
upstream a.com重啟nginx，然後再來訪問a.com看看會不會分配到主伺服器上。
主伺服器也能正常加入服務了。
最後 一、負載均衡不是nginx獨有，著名鼎鼎的apache也有，但效能可能不如nginx。
二、多台伺服器提供服務，但網域名稱只解析到主伺服器，而真正的伺服器ip不會被ping下即可獲得，增加一定安全性。
三、upstream裡的ip不一定是內網，外網ip也可以。不過經典的案例是，區域網中某台ip暴露在外網下，網域名稱直接解析到此ip。然後又這台主伺服器**到內網伺服器ip中。
四、某台伺服器宕機、不會影響**正常執行，nginx不會把請求**到已宕機的ip上
填坑日記8 Nginx 部署 負載均衡 快取
搞完日記7 http的session相關資訊後，又去翻了翻http https http2的相關的內容，另外寫了兩篇文章。現在回到繼續填坑的過程中來。前面已經完成了乙個開發的基本流程，接下來，我需要把這樣乙個東西打包然後再發布到一台伺服器上提供服務。開發模式下我們用的npm start對應的命令是 ...
面試題 PHP面試題
建議 比如是系統配置，缺少了無法執行，自然使用 require 如果某一段程式少了，只是少了統計 訪問的，不是必不可少的。可以使用 include 而加不加 once 就是效率上的區別，雖然系統會幫你考慮只包含一次，但系統的判斷會降低效率，因此，更應該在開發之初，把目錄結構調整高好，盡量不使用 on...
面試題系列（8）
89.抽象類 凡是類內有1個以上的純虛函式出現，這個類就是抽象類 純虛類 純虛函式錯誤型別 cannot instantiate abstract class due to following members a.直接在棧 堆內或者全域性區內申請純虛類 基類 的物件 b.在構造派生類物件時 堆或者棧...