大型網站架構系列：負載均衡詳解（3）

本次分享大綱

1. 軟件負載均衡概述
2. Ngnix負載均衡
3. Lvs負載均衡
4. Haproxy負載均衡
5. 本次分享總結

1、軟件負載均衡概述

硬件負載均衡性能優越，功能全面，可是價格昂貴，通常適合初期或者土豪級公司長期使用。所以軟件負載均衡在互聯網領域大量使用。經常使用的軟件負載均衡軟件有Nginx，Lvs，HaProxy等。本文參考大量文檔，部分爲直接拷貝，參考出處見負載均衡詳解（4）。

2、Ngnix負載均衡

Ngnix是一款輕量級的Web服務器/反向代理服務器，工做在七層Http協議的負載均衡系統。具備高性能、高併發、低內存使用等特色。是一個輕量級的Http和反向代理服務器。Nginx使用epoll and kqueue做爲開發模型。可以支持高達 50,000 個併發鏈接數的響應。

操做系統：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）

開發語言：C

併發性能：官方支持每秒5萬併發，實際國內通常到每秒2萬併發，有優化到每秒10萬併發的。具體性能看應用場景。

2.1.特色

1.模塊化設計：良好的擴展性，能夠經過模塊方式進行功能擴展。

2.高可靠性：主控進程和worker是同步實現的，一個worker出現問題，會馬上啓動另外一個worker。

3.內存消耗低：一萬個長鏈接（keep-alive）,僅消耗2.5MB內存。

4.支持熱部署：不用中止服務器，實現更新配置文件，更換日誌文件、更新服務器程序版本。

5.併發能力強：官方數據每秒支持5萬併發；

6.功能豐富：優秀的反向代理功能和靈活的負載均衡策略

2.2.功能

2.2.1基本功能

• 支持靜態資源的web服務器。
• http,smtp,pop3協議的反向代理服務器、緩存、負載均衡；
• 支持FASTCGI（fpm）
• 支持模塊化，過濾器（讓文本能夠實現壓縮，節約帶寬）,ssl及圖像大小調整。
• 內置的健康檢查功能
• 基於名稱和ip的虛擬主機
• 定製訪問日誌
• 支持平滑升級
• 支持KEEPALIVE
• 支持url rewrite
• 支持路徑別名
• 支持基於IP和用戶名的訪問控制。
• 支持傳輸速率限制，支持併發數限制。

2.2.2擴展功能

2.2.3性能

Nginx的高併發，官方測試支持5萬併發鏈接。實際生產環境能到2-3萬併發鏈接數。10000個非活躍的HTTP keep-alive 鏈接僅佔用約2.5MB內存。三萬併發鏈接下，10個Nginx進程，消耗內存150M。淘寶tengine團隊測試結果是「24G內存機器上，處理併發請求可達200萬」。

2.3架構

2.3.1Nginx的基本工做模式

 

一個master進程，生成一個或者多個worker進程。可是這裏master是使用root身份啓動的，由於nginx要工做在80端口。而只有管理員纔有權限啓動小於低於1023的端口。master主要是負責的做用只是啓動worker，加載配置文件，負責系統的平滑升級。其它的工做是交給worker。那麼當worker被啓動以後，也只是負責一些web最簡單的工做，而其餘的工做都是有worker中調用的模塊來實現的。

模塊之間是以流水線的方式實現功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現完成的。好比：第一個模塊只負責分析請求首部，第二個模塊只負責查找數據，第三個模塊只負責壓縮數據，依次完成各自工做。來實現整個工做的完成。

他們是如何實現熱部署的呢？實際上是這樣的，咱們前面說master不負責具體的工做，而是調用worker工做，他只是負責讀取配置文件，所以當一個模塊修改或者配置文件發生變化，是由master進行讀取，所以此時不會影響到worker工做。在master進行讀取配置文件以後，不會當即的把修改的配置文件告知worker。而是讓被修改的worker繼續使用老的配置文件工做，當worker工做完畢以後，直接當掉這個子進程，更換新的子進程，使用新的規則。

2.3.2Nginx支持的sendfile機制

Sendfile機制，用戶將請求發給內核，內核根據用戶的請求調用相應用戶進程，進程在處理時須要資源。此時再把請求發給內核（進程沒有直接IO的能力），由內核加載數據。內核查找到數據以後，會把數據複製給用戶進程，由用戶進程對數據進行封裝，以後交給內核，內核在進行tcp/ip首部的封裝，最後再發給客戶端。這個功能用戶進程只是發生了一個封裝報文的過程，卻要繞一大圈。所以nginx引入了sendfile機制，使得內核在接受到數據以後，再也不依靠用戶進程給予封裝，而是本身查找本身封裝，減小了一個很長一段時間的浪費，這是一個提高性能的核心點。

 

以上內容摘自網友發佈的文章，簡單一句話是資源的處理，直接經過內核層進行數據傳遞，避免了數據傳遞到應用層，應用層再傳遞到內核層的開銷。

目前高併發的處理，通常都採用sendfile模式。經過直接操做內核層數據，減小應用與內核層數據傳遞。

2.3.3Nginx通訊模型（I/O複用機制）

開發模型：epoll和kqueue。

支持的事件機制：kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。

支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用數據的數量，錯誤代碼.

支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.

以上概念較多，你們自行百度或谷歌，知識領域是網絡通訊（BIO,NIO,AIO）和多線程方面的知識。

2.4均衡策略

nginx的負載均衡策略能夠劃分爲兩大類：內置策略和擴展策略。內置策略包含加權輪詢和ip hash，在默認狀況下這兩種策略會編譯進nginx內核，只需在nginx配置中指明參數便可。擴展策略有不少，如fair、通用hash、consistent hash等，默認不編譯進nginx內核。因爲在nginx版本升級中負載均衡的代碼沒有本質性的變化，所以下面將以nginx1.0.15穩定版爲例，從源碼角度分析各個策略。

2.4.1. 加權輪詢（weighted round robin）

輪詢的原理很簡單，首先咱們介紹一下輪詢的基本流程。以下是處理一次請求的流程圖：

 

圖中有兩點須要注意，第一，若是能夠把加權輪詢算法分爲先深搜索和先廣搜索，那麼nginx採用的是先深搜索算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其餘機器低，纔開始將請求分給下一個高權重的機器；第二，當全部後端機器都down掉時，nginx會當即將全部機器的標誌位清成初始狀態，以免形成全部的機器都處在timeout的狀態，從而致使整個前端被夯住。

2.4.2. ip hash

ip hash是nginx內置的另外一個負載均衡的策略，流程和輪詢很相似，只是其中的算法和具體的策略有些變化，以下圖所示：

 

2.4.3. fair

fair策略是擴展策略，默認不被編譯進nginx內核。其原理是根據後端服務器的響應時間判斷負載狀況，從中選出負載最輕的機器進行分流。這種策略具備很強的自適應性，可是實際的網絡環境每每不是那麼簡單，所以要慎用。

2.4.4 通用hash、一致性hash

這兩種也是擴展策略，在具體的實現上有些差異，通用hash比較簡單，能夠以nginx內置的變量爲key進行hash，一致性hash採用了nginx內置的一致性hash環，能夠支持memcache。

2.5場景

Ngnix通常做爲入口負載均衡或內部負載均衡，結合反向代理服務器使用。如下架構示例，僅供參考，具體使用根據場景而定。

2.5.1入口負載均衡架構

 

Ngnix服務器在用戶訪問的最前端。根據用戶請求再轉發到具體的應用服務器或二級負載均衡服務器（LVS）

2.5.2內部負載均衡架構

 

LVS做爲入口負載均衡，將請求轉發到二級Ngnix服務器，Ngnix再根據請求轉發到具體的應用服務器。

2.5.3Ngnix高可用

 

分佈式系統中，應用只部署一臺服務器會存在單點故障，負載均衡一樣有相似的問題。通常可採用主備或負載均衡設備集羣的方式節約單點故障或高併發請求分流。

Ngnix高可用，至少包含兩個Ngnix服務器，一臺主服務器，一臺備服務器，之間使用Keepalived作健康監控和故障檢測。開放VIP端口，經過防火牆進行外部映射。

DNS解析公網的IP實際爲VIP。