一、軟件負載均衡概述

硬件負載均衡性能優(yōu)越，功能全面，但是價格昂貴，一般適合初期或者土豪級公司長期使用。因此軟件負載均衡在互聯(lián)網領域大量使用。常用的軟件負載均衡軟件有Nginx，Lvs，HaProxy等。本文參考大量文檔，部分為直接拷貝，參考出處見負載均衡詳解（4）。

二、Ngnix負載均衡

Ngnix是一款輕量級的Web服務器/反向代理服務器，工作在七層Http協(xié)議的負載均衡系統(tǒng)。具有高性能、高并發(fā)、低內存使用等特點。是一個輕量級的Http和反向代理服務器。Nginx使用epoll and kqueue作為開發(fā)模型。能夠支持高達 50,000 個并發(fā)連接數(shù)的響應。
操作系統(tǒng)：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）
開發(fā)語言：C
并發(fā)性能：官方支持每秒5萬并發(fā)，實際國內一般到每秒2萬并發(fā)，有優(yōu)化到每秒10萬并發(fā)的。具體性能看應用場景。

2.1.特點

1.模塊化設計：良好的擴展性，可以通過模塊方式進行功能擴展。
2.高可靠性：主控進程和worker是同步實現(xiàn)的，一個worker出現(xiàn)問題，會立刻啟動另一個worker。
3.內存消耗低：一萬個長連接（keep-alive）,僅消耗2.5MB內存。
4.支持熱部署：不用停止服務器，實現(xiàn)更新配置文件，更換日志文件、更新服務器程序版本。
5.并發(fā)能力強：官方數(shù)據(jù)每秒支持5萬并發(fā)；
6.功能豐富：優(yōu)秀的反向代理功能和靈活的負載均衡策略

2.2.功能

2.2.1基本功能

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

2.2.2擴展功能

2.2.3性能

Nginx的高并發(fā)，官方測試支持5萬并發(fā)連接。實際生產環(huán)境能到2-3萬并發(fā)連接數(shù)。10000個非活躍的HTTP keep-alive 連接僅占用約2.5MB內存。三萬并發(fā)連接下，10個Nginx進程，消耗內存150M。淘寶tengine團隊測試結果是“24G內存機器上，處理并發(fā)請求可達200萬”。

2.3架構

2.3.1 Nginx的基本工作模式

一個master進程，生成一個或者多個worker進程。但是這里master是使用root身份啟動的，因為nginx要工作在80端口。而只有管理員才有權限啟動小于低于1023的端口。master主要是負責的作用只是啟動worker，加載配置文件，負責系統(tǒng)的平滑升級。其它的工作是交給worker。那么當worker被啟動之后，也只是負責一些web最簡單的工作，而其他的工作都是有worker中調用的模塊來實現(xiàn)的。
模塊之間是以流水線的方式實現(xiàn)功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現(xiàn)完成的。比如：第一個模塊只負責分析請求首部，第二個模塊只負責查找數(shù)據(jù)，第三個模塊只負責壓縮數(shù)據(jù)，依次完成各自工作。來實現(xiàn)整個工作的完成。
他們是如何實現(xiàn)熱部署的呢？其實是這樣的，我們前面說master不負責具體的工作，而是調用worker工作，他只是負責讀取配置文件，因此當一個模塊修改或者配置文件發(fā)生變化，是由master進行讀取，因此此時不會影響到worker工作。在master進行讀取配置文件之后，不會立即的把修改的配置文件告知worker。而是讓被修改的worker繼續(xù)使用老的配置文件工作，當worker工作完畢之后，直接當?shù)暨@個子進程，更換新的子進程，使用新的規(guī)則。

2.3.2Nginx支持的sendfile機制

Sendfile機制，用戶將請求發(fā)給內核，內核根據(jù)用戶的請求調用相應用戶進程，進程在處理時需要資源。此時再把請求發(fā)給內核（進程沒有直接IO的能力），由內核加載數(shù)據(jù)。內核查找到數(shù)據(jù)之后，會把數(shù)據(jù)復制給用戶進程，由用戶進程對數(shù)據(jù)進行封裝，之后交給內核，內核在進行tcp/ip首部的封裝，最后再發(fā)給客戶端。這個功能用戶進程只是發(fā)生了一個封裝報文的過程，卻要繞一大圈。因此nginx引入了sendfile機制，使得內核在接受到數(shù)據(jù)之后，不再依靠用戶進程給予封裝，而是自己查找自己封裝，減少了一個很長一段時間的浪費，這是一個提升性能的核心點。

以上內容摘自網友發(fā)布的文章，簡單一句話是資源的處理，直接通過內核層進行數(shù)據(jù)傳遞，避免了數(shù)據(jù)傳遞到應用層，應用層再傳遞到內核層的開銷。
目前高并發(fā)的處理，一般都采用sendfile模式。通過直接操作內核層數(shù)據(jù)，減少應用與內核層數(shù)據(jù)傳遞。

2.3.3Nginx通信模型（I/O復用機制）

開發(fā)模型：epoll和kqueue。
支持的事件機制：kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。
支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用數(shù)據(jù)的數(shù)量，錯誤代碼.
支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.
以上概念較多，大家自行百度或谷歌，知識領域是網絡通信（BIO,NIO,AIO）和多線程方面的知識。

2.4均衡策略

nginx的負載均衡策略可以劃分為兩大類：內置策略和擴展策略。內置策略包含加權輪詢和ip hash，在默認情況下這兩種策略會編譯進nginx內核，只需在nginx配置中指明參數(shù)即可。擴展策略有很多，如fair、通用hash、consistent hash等，默認不編譯進nginx
內核。由于在nginx版本升級中負載均衡的代碼沒有本質性的變化，因此下面將以nginx1.0.15穩(wěn)定版為例，從源碼角度分析各個策略。

2.4.1. 加權輪詢（weighted round robin）

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

圖中有兩點需要注意，第一，如果可以把加權輪詢算法分為先深搜索和先廣搜索，那么nginx采用的是先深搜索算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其他機器低，才開始將請求分給下一個高權重的機器；第二，當所有后端機器都down掉時，nginx會立即將所有機器的標志位清成初始狀態(tài)，以避免造成所有的機器都處在timeout的狀態(tài)，從而導致整個前端被夯住。

2.4.2. ip hash

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

2.4.3. fair

fair策略是擴展策略，默認不被編譯進nginx內核。其原理是根據(jù)后端服務器的響應時間判斷負載情況，從中選出負載最輕的機器進行分流。這種策略具有很強的自適應性，但是實際的網絡環(huán)境往往不是那么簡單，因此要慎用。

2.4.4 通用hash、一致性hash

這兩種也是擴展策略，在具體的實現(xiàn)上有些差別，通用hash比較簡單，可以以nginx內置的變量為key進行hash，一致性hash采用了nginx內置的一致性hash環(huán)，可以支持memcache。

2.5場景

Ngnix一般作為入口負載均衡或內部負載均衡，結合反向代理服務器使用。以下架構示例，僅供參考，具體使用根據(jù)場景而定。

2.5.1入口負載均衡架構

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

2.5.2內部負載均衡架構

LVS作為入口負載均衡，將請求轉發(fā)到二級Ngnix服務器，Ngnix再根據(jù)請求轉發(fā)到具體的應用服務器。

2.5.3Ngnix高可用

分布式系統(tǒng)中，應用只部署一臺服務器會存在單點故障，負載均衡同樣有類似的問題。一般可采用主備或負載均衡設備集群的方式節(jié)約單點故障或高并發(fā)請求分流。
Ngnix高可用，至少包含兩個Ngnix服務器，一臺主服務器，一臺備服務器，之間使用Keepalived做健康監(jiān)控和故障檢測。開放VIP端口，通過防火墻進行外部映射。
DNS解析公網的IP實際為VIP。

總結

以上是生活随笔為你收集整理的软件负载均衡的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。