場景：在國內是無法正常使用google.com。如果想要訪問google.com，可以購買一台國外的伺服器a，此時你和伺服器a的網路是相通的。而伺服器a又跟google.com相通， 此時可以由伺服器a**你（客戶端），去訪問google.com。這個過程稱之為正向**，服務端（google.com）只需要知道**伺服器的ip，不需要知道客戶端的ip。
示例1：
示例2：
結論：正向**，是用於**客戶端的。
##反向**
場景：當乙個伺服器接受過多來自客戶端的請求時，伺服器難以處理和響應這些請求，會使得整個系統效能下降。為了解決這個難題，可以提供多台部署相同應用的伺服器，讓客戶端的請求分別傳送到不同的伺服器上，這樣單機伺服器的壓力就會降低很多，整體效能便會提公升。但是有乙個問題，每個伺服器ip都是不同的，也就是說客戶端的請求要傳送到多個不同的ip上。讓客戶手動指定ip進行請求，這種方式很不明智。首先是客戶的隨機性，不知道會訪問哪台伺服器，其次，會造成一部分伺服器壓力大，一部分伺服器幾乎沒有使用，浪費資源。因此，這裡就需要乙個角色去**伺服器，讓客戶端的請求直接傳送到這個角色上，由這個角色去分發請求到不同的伺服器上。
這個角色就是反向**伺服器。
結論：反向**，是用於**服務端的。
場景：反向**過程中，每台伺服器處理來自客戶端的請求都應該是均衡的。
原理：使用乙個反向**伺服器指向多台部署相同應用的伺服器，客戶端請求直接向反向**伺服器發起，反向**伺服器根據負載均衡機制，將請求**到不同的應用伺服器上。
nginx提供了以下三種負載均衡機制：
round-robin：預設情況下，使用迴圈、輪轉的方式分發請求到伺服器
配置示例：
}}least-connected：當一些請求處理的時間比較長時，最少連線負載均衡能夠爭取到更大的公平。
配置示例：
least-conn;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}ip-hash：採用目標位址雜湊排程（destination hashing scheduling）演算法，根據請求的目標ip位址，作為雜湊鍵（hash key）從靜態分配的雜湊表找出對應的伺服器，若該伺服器可用且未超載，則將請求傳送帶伺服器，否則返回空。
配置示例：
ip-hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;}
不過，nginx雖然強大，但是還是有很多問題的。
1. 單純使用nginx，會造成配置維護成本變高。
2. 單點故障率增加，因為熱點服務的訪問量很高，如果這個服務的負載均衡服務出現問題，整個服務都會掛點。
因此，可以結合zookeeper去使用。
nginx和zookeeper搭配使用，詳情見：
nginx 負載均衡 Nginx負載均衡策略
nginx提供的負載均衡策略有2種 內建策略和擴充套件策略。內建策略為輪詢 預設 加權輪詢，ip hash，第三方。upstream mysvr1 輪詢 每個請求按照時間順序逐一的分配到每乙個後台伺服器上。如果某台伺服器宕機了，將會自動的剔除宕機的服務。nginx預設就是輪詢其權重都預設為1，伺服器...
nginx負載均衡
nginx 的 upstream目前支援 4 種方式的分配 1 輪詢 預設 每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。2 weight 指定輪詢機率，weight和訪問比率成正比，用於後端伺服器效能不均的情況。3 ip hash 每個請求按訪問ip的hash...
nginx負載均衡
nginx s stop quick exit nginx s quit graceful quit nginx s reload changing configuration,starting a new worker,quitting an old worker gracefully nginx...