關于nginx的負載均衡軟件配置很多朋友都有接觸過。但是，對于硬件產品，由于其高昂的費用，接觸的人相對較少一些。下面，我就來針對Nginx負載均衡器與大家做一些探討。

在項目實施過程中發現，業務系統最前端的Cisco PIX535防火墻的外網IP映射的是內網Nginx負載均稀器的內網IP（DNAT），這時的Nginx負載均衡器的作用相當于整套系統的樞紐，如果該服務器發生故障，會導致整個網站無法訪問，所以我們需要二臺以上的Nginx負載均稀器，以實現故障轉移和高可用性。

實現的辦法有如下：

一、二臺Nginx負載均衡器通過Keepalived形成高可用，防火墻映射的是Keepalived形成的vip地址；keepalived是lvs的擴展形式，部署起來非常容易，成熟的案例在sina等企業也得到應用；但Keepalived做不到監控nginx服務級別，即如果nginx服務崩潰了，Keepalived也沒有辦法，雖然可以通過Heartbeat來解決這個問題，但Heartbeat本身就存在著裂腦情況，所以目前我只是將Heartbeat用于內部測試環境，生產環境我仍然是用Keepalived。

二、最前端不用Cisco防火墻映射，而用F5代替；第二層用二臺或二臺以上的Nginx負載均衡器，第三層才是web集群。

這樣的好處很明顯：不存在單點Nginx負載均衡出現故障問題。

同樣缺點也很明顯：整個工程的成本增加，你的客戶和老板很可能非常不滿意。

三、張宴兄采用的辦法是用DNS輪詢，二臺Nginx負載均衡器均提供一個虛擬的外網IP對應用DNS（應用環境為逍遙網xoyo．com），二臺Nginx上的故障轉移通過自身的shell腳本來實現，具體請參見張宴的《實戰Nginx－取代Apache的高性能web服務器》一書。方案很實用，而且也是線上環境，但美中不足的是我手上的證券系統，都只有IP，并無DNS域名對應，看來這個需要跟券商談判爭取了。

四、目前我手上跑的三套在線系統都是單機Nginx，是由于券商都有值班人員和監控系統Nagios，但這樣會增加生產成本。

我目前想的一個辦法是：

在Nginx負載均衡器上開啟sendmail服務，運行一個監控shell腳本，每2－5分鐘就wgethttp：／／172．16．110．61／test．php（為了避免Cisco防火墻某些技術上的限制，這里采用內網IP形式）即2分鐘或5分鐘就自動去獲取一次后端web的某網頁一次，如果正常就啥也不做；如果發生異常情況，就向我的139郵箱發送Ctritical警報。因為139郵箱對應了手機號碼，所以此時手機將會收到報警信息，達到預警目的。