摘要:對於一個大型網站來講,負載均衡是永恆的話題。隨着硬件技術的迅猛發展,愈來愈多的負載均衡硬件設備涌現出來,如F5 BIG-IP、Citrix NetScaler、Radware等等,雖然能夠解決問題,但其高昂的價格卻每每使人望而卻步,所以負載均衡軟件仍然是大部分公司的不二之選。nginx做爲webserver的後起之秀,其優秀的反向代理功能和靈活的負載均衡策略受到了業界普遍的關注。本文將以工業生產爲背景,從設計實現和具體應用等方面詳細介紹nginx負載均衡策略。 php
關鍵字:nginx 負載均衡 反向代理 前端
隨着互聯網信息的爆炸性增加,負載均衡(load balance)已經再也不是一個很陌生的話題,顧名思義,負載均衡便是將負載分攤到不一樣的服務單元,既保證服務的可用性,又保證響應足夠快,給用戶很好的體驗。快速增加的訪問量和數據流量催生了各式各樣的負載均衡產品,不少專業的負載均衡硬件提供了很好的功能,但卻價格不菲,這使得負載均衡軟件大受歡迎,nginx就是其中的一個。 nginx
nginx第一個公開版本發佈於2004年,2011年發佈了1.0版本。它的特色是穩定性高、功能強大、資源消耗低,從其目前的市場佔有而言,nginx大有與apache搶市場的勢頭。其中不得不提到的一個特性就是其負載均衡功能,這也成了不少公司選擇它的主要緣由。本文將從源碼的角度介紹nginx的內置負載均衡策略和擴展負載均衡策略,以實際的工業生產爲案例,對比各負載均衡策略,爲nginx使用者提供參考。 web
nginx的負載均衡策略能夠劃分爲兩大類:內置策略和擴展策略。內置策略包含加權輪詢和ip hash,在默認狀況下這兩種策略會編譯進nginx內核,只需在nginx配置中指明參數便可。擴展策略有不少,如fair、通用hash、consistent hash等,默認不編譯進nginx內核。因爲在nginx版本升級中負載均衡的代碼沒有本質性的變化,所以下面將以nginx1.0.15穩定版爲例,從源碼角度分析各個策略。 算法
輪詢的原理很簡單,首先咱們介紹一下輪詢的基本流程。以下是處理一次請求的流程圖: apache
圖中有兩點須要注意,第一,若是能夠把加權輪詢算法分爲先深搜索和先廣搜索,那麼nginx採用的是先深搜索算法,即將首先將請求都分給高權重的機器,直到該機器的權值降到了比其餘機器低,纔開始將請求分給下一個高權重的機器;第二,當全部後端機器都down掉時,nginx會當即將全部機器的標誌位清成初始狀態,以免形成全部的機器都處在timeout的狀態,從而致使整個前端被夯住。 後端
接下來看下源碼。nginx源碼的目錄結構很清晰,加權輪詢所在路徑爲nginx-1.0.15/src/http/ngx_http_upstream_round_robin.[c|h],在源碼的基礎上,針對重要的、不易理解的地方我加了註釋。首先看下ngx_http_upstream_round_robin.h中的重要聲明: 數組
從變量命名中,咱們就能夠大體猜出其做用。其中,current_weight和weight的區別主要是前者爲權重排序的值,隨着處理請求會動態的變化,後者是配置值,用於恢復初始狀態。 緩存
接下來看下輪詢的建立過程,代碼以下圖所示。 服務器
這裏有個tried變量須要作些說明。tried中記錄了服務器當前是否被嘗試鏈接過。他是一個位圖。若是服務器數量小於32,則只需在一個int中便可記錄下全部服務器狀態。若是服務器數量大於32,則需在內存池中申請內存來存儲。對該位圖數組的使用可參考以下代碼:
最後是實際的策略代碼,邏輯很簡單,代碼實現也只有30行,直接上代碼。
ip hash是nginx內置的另外一個負載均衡的策略,流程和輪詢很相似,只是其中的算法和具體的策略有些變化,以下圖所示:
ip hash算法的核心實現以下圖:
從代碼中能夠看出,hash值既與ip有關又與後端機器的數量有關。通過測試,上述算法能夠連續產生1045個互異的value,這是該算法的硬限制。對此nginx使用了保護機制,當通過20次hash仍然找不到可用的機器時,算法退化成輪詢。所以,從本質上說,ip hash算法是一種變相的輪詢算法,若是兩個ip的初始hash值剛好相同,那麼來自這兩個ip的請求將永遠落在同一臺服務器上,這爲均衡性埋下了很深的隱患。
fair策略是擴展策略,默認不被編譯進nginx內核。其原理是根據後端服務器的響應時間判斷負載狀況,從中選出負載最輕的機器進行分流。這種策略具備很強的自適應性,可是實際的網絡環境每每不是那麼簡單,所以要慎用。
這兩種也是擴展策略,在具體的實現上有些差異,通用hash比較簡單,能夠以nginx內置的變量爲key進行hash,一致性hash採用了nginx內置的一致性hash環,能夠支持memcache。
本測試主要爲了對比各個策略的均衡性、一致性、容災性等,從而分析出其中的差別性,並據此給出各自的適用場景。爲了可以全面、客觀的測試nginx的負載均衡策略,咱們採用了兩個測試工具、在不一樣場景下作測試,以此來下降環境對測試結果形成的影響。首先簡單介紹測試工具、測試網絡拓撲和基本的測試流程。
easyABC是公司內部開發的性能測試工具,採用epool模型實現,簡單易上手,能夠模擬GET/POST請求,極限狀況下能夠提供上萬的壓力,在公司內部獲得了普遍的使用。因爲被測試對象爲反向代理服務器,所以須要在其後端搭建樁服務器,這裏用nginx做爲樁webserver,提供最基本的靜態文件服務。
polygraph是一款免費的性能測試工具,以對緩存服務、代理、交換機等方面的測試見長。它有規範的配置語言PGL(Polygraph Language),爲軟件提供了強大的靈活性。其工做原理以下圖所示:
polygraph提供client端和server端,將測試目標nginx放在兩者之間,三者之間的網絡交互均走http協議,只需配置ip+port便可。client端能夠配置虛擬robot的個數以及每一個robot發請求的速率,並向代理服務器發起隨機的靜態文件請求,server端將按照請求的url生成隨機大小的靜態文件作響應。這也是選用這個測試軟件的一個主要緣由:能夠產生隨機的url做爲nginx各類hash策略的key。
另外,polygraph還提供了日誌分析工具,功能比較豐富,感興趣的同窗能夠參考附錄中的相關材料。
本測試運行在5臺物理機上,其中被測對象單獨搭在一臺8核機器上,另外四臺4核機器分別搭建了easyABC、webserver樁和polygraph,以下圖所示:
首先介紹下關鍵的測試指標:
均衡性:是否可以將請求均勻的發送給後端
一致性:同一個key的請求,是否能落到同一臺機器
容災性:當部分後端機器掛掉時,是否可以正常工做
以上述指標爲指導,咱們針對以下四個測試場景分別用easyABC和polygraph進行測試:
場景1 server_*均正常提供服務;
場景2 server_4掛掉,其餘正常;
場景3 server_三、server_4掛掉,其餘正常;
場景4 server_*均恢復正常服務。
上述四個場景將按照時間順序進行,每一個場景將創建在上一個場景基礎上,被測試對象無需作任何操做,以最大程度模擬實際狀況。另外,考慮到測試工具自身的特色,在easyabc上的測試壓力在17000左右,polygraph上的測試壓力在4000左右。以上測試均保證被測試對象能夠正常工做,且無任何notice級別以上(alert/error/warn)的日誌出現,在每一個場景中記錄下server_*的qps用於最後的策略分析。
表1和圖1是輪詢策略在兩種測試工具下的負載狀況。對比在兩種測試工具下的測試結果會發現,結果徹底一致,所以能夠排除測試工具的影響。從圖表中能夠看出,輪詢策略對於均衡性和容災性均可以作到很好的知足。(點擊圖片查看大圖)
表2和圖2是fair策略在兩種測試工具下的負載狀況。fair策略受環境影響很是大,在排除了測試工具的干擾以後,結果仍然有很是大的抖動。從直觀上講,這徹底不知足均衡性。可是從另外一個角度出發,偏偏是因爲這種自適應性確保了在複雜的網絡環境中可以物盡所用。所以,在應用到工業生產中以前,須要在具體的環境中作好測試工做。(點擊圖片查看大圖)
如下圖表是各類hash策略,所不一樣的僅僅是hash key或者是具體的算法實現,所以一塊兒作對比。實際測試中發現,通用hash和一致性hash均存在一個問題:當某臺後端的機器掛掉時,原有落到這臺機器上的流量會丟失,可是在ip hash中就不存在這樣的問題。正如上文中對ip hash源碼的分析,當ip hash失效時,會退化爲輪詢策略,所以不會有丟失流量的狀況。從這個層面上說,ip hash也能夠當作是輪詢的升級版。(點擊圖片查看大圖)
圖5爲ip hash策略,ip hash是nginx內置策略,能夠看作是前兩種策略的特例:以來源ip爲key。因爲測試工具不便於模擬海量ip下的請求,所以這裏截取線上實際的狀況加以分析,以下圖所示:
圖5 ip hash策略
圖中前1/3使用輪詢策略,中間段使用ip hash策略,後1/3仍然是輪詢策略。能夠明顯的看出,ip hash的均衡性存在着很大的問題。緣由並不難分析,在實際的網絡環境中,有大量的高校出口路由器ip、企業出口路由器ip等網絡節點,這些節點帶來的流量每每是普通用戶的成百上千倍,而ip hash策略偏偏是按照ip來劃分流量,所以形成上述後果也就天然而然了。
經過實際的對比測試,咱們對nginx各個負載均衡策略進行了驗證。下面從均衡性、一致性、容災性以及適用場景等角度對比各類策略。(點擊圖片查看大圖)
以上從源碼和實際的測試數據角度分析說明了nginx負載均衡的策略,並給出了各類策略適合的應用場景。經過本文的分析不難發現,不管哪一種策略都不是萬金油,在具體的場景下應該選擇哪一種策略必定程度上依賴於使用者對這些策略的熟悉程度。但願本文的分析和測試數據可以對讀者有所幫助,更但願有愈來愈多、愈來愈好的負載均衡策略產出。
http://wiki.nginx.org/HttpUpstreamConsistentHash
http://wiki.nginx.org/HttpUpstreamFairModule