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

本次分享大綱

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

一、軟體負載均衡概述

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

二、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。