三大主流軟體負載均衡器對比(lvs、nginx、haproxy)
（資料來自網路，做了部分的補充說明）
lvs:
1. 抗負載能力強，效能高，能達到f5的60%，對記憶體和cpu資源消耗比較低
2. 工作在網路4層，通過vrrp協議(僅作**之用)，具體的流量是由linux核心來處理，因此沒有流量的產生。
3. 穩定，可靠性高，自身有完美的熱備方案(keepalived+lvs)
4. 不支援正則處理，不能做動靜分離。
5. 支援多種負載均衡演算法：rr(輪詢)，wrr(帶權輪詢)、lc(最小連線)、wlc(帶權最小連線)
6. 配置相對複雜，對網路依賴比較大，穩定性很高。
7. lvs工作模式有4種：
(1) nat 位址轉換
(2) dr 直接路由
(3) tun 隧道
(4) full-nat
nginx:
1. 工作在網路7層，可以針對http應用做一些分流的策略，比如針對網域名稱，目錄結構
2. nginx對網路的依賴較小，理論上能ping通就能進行負載功能
3. nginx安裝配置比較簡單，測試起來很方便
4. 也可以承擔較高的負載壓力且穩定，nginx是為解決c10k問題而誕生的
5. 對後端伺服器的健康檢查，只支援通過埠來檢測，不支援通過url來檢測
6. nginx對請求的非同步處理可以幫助節點伺服器減輕負載壓力
7. nginx僅能支援http、https和email協議，這樣就在適用範圍較小。
8. 不支援session的直接保持，但能通過ip_hash來解決。對big request header的支援不是很好。
9. nginx還能做web伺服器即cache功能。
第6點補充：
什麼是nginx的非同步處理：
squid同步處理：瀏覽器發起請求，而後請求會立刻被轉到後端，於是在瀏覽器和後台之間就建立了乙個通道。從請求發起直到請求完成，這條通道都是一直存在的。
nginx非同步處理：瀏覽器發起請求，請求不會立刻轉到後端，而是請求資料(header)先收到nignx上，然後nginx再把這個請求發到後端，後端處理完成後把資料返回到nginx上，nginx將資料流發到瀏覽器。
使用非同步處理的好處：
1. 假設使用者執行乙個上傳檔案操作，因為使用者網速又比較慢，因此需要花半個小時才能把檔案傳到伺服器。squid的同步**在使用者開始上傳後就和後台建立了連線，半小時後檔案上傳結束，由此可見，後台伺服器連線保持了半個小時；而nginx非同步**就是先將此檔案收到nginx上，因此僅僅是nginx和使用者保持了半小時連線，後台伺服器在這半小時內沒有為這個請求開啟連線，半小時後使用者上傳結束，nginx才將上傳內容發到後台，nginx和後台之間的頻寬是很充裕的，所以只花了一秒鐘就將請求傳送到了後台，由此可見，後台伺服器連線保持了一秒。同步傳輸花了後台伺服器半個小時，非同步傳輸只花一秒，可見優化 程度很大。
2. 在上面這個例子中，假如後台伺服器因為種種原因重啟了，上傳檔案就自然中斷了，這對使用者來說是非常惱火的一件事情，想必各位也有上傳檔案傳到一半被中斷的 經歷。用nginx**之後，後台伺服器的重啟對使用者上傳的影響減少到了極點，而nginx是非常穩定的並不需要常去重啟它，即使需要重啟，利用kill -hup就可以做到不間斷重啟nginx。
3. 非同步傳輸可以令負載均衡器更有保障，為什麼這麼說呢？在其它的均衡器（lvs/haproxy/apache等）裡，每個請求都是只有一次機會的，假如用 戶發起乙個請求，結果該請求分到的後台伺服器剛好掛掉了，那麼這個請求就失敗了；而nginx因為是非同步的，所以這個請求可以重新發往下乙個後台，下乙個 後台返回了正常的資料，於是這個請求就能成功了。還是用使用者上傳檔案這個例子，假如不但用了nginx**，而且用了負載均衡，nginx把上傳檔案發往 其中一台後台，但這台伺服器突然重啟了，nginx收到錯誤後，會將這個上傳檔案發到另一台後台，於是使用者就不用再花半小時上傳一遍。
4. 假如使用者上傳乙個10gb大小的檔案，而後台伺服器沒有考慮到這個情況，那麼後台伺服器豈不要崩潰了。用nginx就可以把這些東西都攔在nginx上，通過nginx的上傳檔案大小限制功能來限制，另外nginx效能非常有保障，就放心的讓網際網路上那些另類的使用者和nginx對抗去吧。
用非同步傳輸會造成問題：
後台伺服器有提供上傳進度的功能的話，用了nginx**就無法取得進度，這個需要使用nginx的乙個第三方模組來實現。
第8點補充：
nginx upstream支援的分配策略及原理：
1. 輪詢(預設)：每個請求按照順序逐一分配到不同的後端伺服器。如後端伺服器down掉，就切換到另一台並剔除down的後端主機
2. weight：指定輪詢機率，weight和訪問比率成正比，用於後端伺服器效能不均的情況。
3. ip_hash：每個請求按照訪問ip的hash結果分配，不同ip的請求被分配到後端不同的伺服器上，可以解決session的問題。
haproxy:
1. 支援兩種**模式：tcp（四層）和http（七層），支援虛擬主機；
2. 能夠補充nginx的一些缺點比如session的保持，cookie的引導等工作
3. 支援url檢測後端的伺服器出問題的檢測會有很好的幫助。
4. 更多的負載均衡策略比如：動態加權輪循(dynamic round robin)，加權源位址雜湊(weighted source hash)，加權url雜湊和加權引數雜湊(weighted parameter hash)已經實現
5. 單純從效率上來講haproxy更會比nginx有更出色的負載均衡速度。
6. haproxy可以對mysql進行負載均衡，對後端的db節點進行檢測和負載均衡。
7. 支援負載均衡演算法：round-robin（輪循）、weight-round-robin（帶權輪循）、source（原位址保持）、ri（請求url）、rdp-cookie（根據cookie）
8. 不能做web伺服器即cache。
三大主流軟體負載均衡器適用業務場景：
1. **建設初期，可以選用nginx、haproxy作為反向**負載均衡(流量不大時，可以不選用負載均衡)，因為其配置簡單，效能也能滿足一般業務場景。如果考慮到負載均衡器是有單點問題，可以採用nginx+keepalived/haproxy+keepalived避免負載均衡器自身的單點問題。
2. **併發到達一定程度後，為了提高穩定性和**效率，可以使用lvs，畢竟lvs比nginx/haproxy要更穩定，**效率也更高。
注：nginx與haproxy比較：nginx只支援七層，使用者量最大，穩定性比較可靠。haproxy支援四層和七層，支援更多的負載均衡演算法，支援session等。
衡量負載均衡器好壞的幾個重要的因素：
1. 會話率 ：單位時間內的處理的請求數
2. 會話併發能力：併發處理能力
3. 資料率：處理資料能力
Nginx LVS的負載均衡演算法
靜態 根據lvs本身自由的固定的演算法分發使用者請求。輪詢 round robin 簡寫 rr 輪詢演算法假設所有的伺服器處理請求的能力都一樣的，排程器會把所有的請求平均分配給每個真實伺服器 同nginx的輪詢類似 加權輪詢 weight round robin 簡寫 wrr 安裝權重比例分配使用者...
nginx 負載均衡 Nginx負載均衡策略
nginx提供的負載均衡策略有2種 內建策略和擴充套件策略。內建策略為輪詢 預設 加權輪詢，ip hash，第三方。upstream mysvr1 輪詢 每個請求按照時間順序逐一的分配到每乙個後台伺服器上。如果某台伺服器宕機了，將會自動的剔除宕機的服務。nginx預設就是輪詢其權重都預設為1，伺服器...
軟負載均衡和F5負載均衡（硬負載均衡）區別
分割線，以下是原文內容 負載均衡 建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴充套件 網路裝置 和伺服器 的頻寬 增加 吞吐量 加強網路資料處理能力 提高網路的靈活性和可用性。負載均衡，英文名稱為load balance，其意思就是分攤到多個操作單元上進行執行，例如web 伺服器 ftp...