高性能服務(wù)器Nginx（四）------負(fù)載均衡

在上一篇博客我們介紹了 Nginx 一個(gè)很重要的功能——代理，包括正向代理和反向代理。這兩個(gè)代理的核心區(qū)別是：正向代理代理的是客戶端，而反向代理代理的是服務(wù)器。其中我們又重點(diǎn)介紹了反向代理，以及如何通過 Nginx 來實(shí)現(xiàn)反向代理。

那么了解了Nginx的反向代理之后，我們要通過Nginx的反向代理實(shí)現(xiàn)另一個(gè)重要功能——負(fù)載均衡。

1、負(fù)載均衡的由來

早期的系統(tǒng)架構(gòu)，基本上都是如下形式的：

　　客戶端發(fā)送多個(gè)請(qǐng)求到服務(wù)器，服務(wù)器處理請(qǐng)求，有一些可能要與數(shù)據(jù)庫進(jìn)行交互，服務(wù)器處理完畢后，再將結(jié)果返回給客戶端。

這種架構(gòu)模式對(duì)于早期的系統(tǒng)相對(duì)單一，并發(fā)請(qǐng)求相對(duì)較少的情況下是比較適合的，成本也低。但是隨著信息數(shù)量的不斷增長(zhǎng)，訪問量和數(shù)據(jù)量的飛速增長(zhǎng)，以及系統(tǒng)業(yè)務(wù)的復(fù)雜度增加，這種架構(gòu)會(huì)造成服務(wù)器相應(yīng)客戶端的請(qǐng)求日益緩慢，并發(fā)量特別大的時(shí)候，還容易造成服務(wù)器直接崩潰。很明顯這是由于服務(wù)器性能的瓶頸造成的問題，那么如何解決這種情況呢？

我們首先想到的可能是升級(jí)服務(wù)器的配置，比如提高CPU執(zhí)行頻率，加大內(nèi)存等提高機(jī)器的物理性能來解決此問題，但是我們知道摩爾定律的日益失效，硬件的性能提升已經(jīng)不能滿足日益提升的需求了。最明顯的一個(gè)例子，天貓雙十一當(dāng)天，某個(gè)熱銷商品的瞬時(shí)訪問量是極其龐大的，那么類似上面的系統(tǒng)架構(gòu)，將機(jī)器都增加到現(xiàn)有的頂級(jí)物理配置，都是不能夠滿足需求的。那么怎么辦呢？

上面的分析我們?nèi)サ袅嗽黾臃?wù)器物理配置來解決問題的辦法，也就是說縱向解決問題的辦法行不通了，那么橫向增加服務(wù)器的數(shù)量呢？這時(shí)候集群的概念產(chǎn)生了，單個(gè)服務(wù)器解決不了，我們?cè)黾臃?wù)器的數(shù)量，然后將請(qǐng)求分發(fā)到各個(gè)服務(wù)器上，將原先請(qǐng)求集中到單個(gè)服務(wù)器上的情況改為將請(qǐng)求分發(fā)到多個(gè)服務(wù)器上，將負(fù)載分發(fā)到不同的服務(wù)器，也就是我們所說的負(fù)載均衡。

　　負(fù)載均衡完美的解決了單個(gè)服務(wù)器硬件性能瓶頸的問題，但是隨著而來的如何實(shí)現(xiàn)負(fù)載均衡呢？客戶端怎么知道要將請(qǐng)求發(fā)送到那個(gè)服務(wù)器去處理呢？

2、Nginx實(shí)現(xiàn)負(fù)載均衡

Nginx 服務(wù)器是介于客戶端和服務(wù)器之間的中介，通過上一篇博客講解的反向代理的功能，客戶端發(fā)送的請(qǐng)求先經(jīng)過 Nginx ，然后通過 Nginx 將請(qǐng)求根據(jù)相應(yīng)的規(guī)則分發(fā)到相應(yīng)的服務(wù)器。

　　主要配置指令為上一講的 pass_proxy 指令以及 upstream 指令。負(fù)載均衡主要通過專門的硬件設(shè)備或者軟件算法實(shí)現(xiàn)。通過硬件設(shè)備實(shí)現(xiàn)的負(fù)載均衡效果好、效率高、性能穩(wěn)定，但是成本較高。而通過軟件實(shí)現(xiàn)的負(fù)載均衡主要依賴于均衡算法的選擇和程序的健壯性。均衡算法又主要分為兩大類：

靜態(tài)負(fù)載均衡算法：主要包括輪詢算法、基于比率的加權(quán)輪詢算法或者基于優(yōu)先級(jí)的加權(quán)輪詢算法。

動(dòng)態(tài)負(fù)載均衡算法：主要包括基于任務(wù)量的最少連接優(yōu)化算法、基于性能的最快響應(yīng)優(yōu)先算法、預(yù)測(cè)算法及動(dòng)態(tài)性能分配算法等。

靜態(tài)負(fù)載均衡算法在一般網(wǎng)絡(luò)環(huán)境下也能表現(xiàn)的比較好，動(dòng)態(tài)負(fù)載均衡算法更加適用于復(fù)雜的網(wǎng)絡(luò)環(huán)境。

例子：

①、普通輪詢算法

這是Nginx 默認(rèn)的輪詢算法。

例子：兩臺(tái)相同的Tomcat服務(wù)器，通過 localhost:8080 訪問Tomcat1，通過 localhost:8081訪問Tomcat2，現(xiàn)在我們要輸入 localhost 這個(gè)地址，可以在這兩個(gè)Tomcat服務(wù)器之間進(jìn)行交替訪問。

一、分別修改兩個(gè)Tomcat服務(wù)器的端口為8080和8081。然后再修改Tomcat的首頁，使得訪問這兩個(gè)頁面時(shí)能夠區(qū)分。如下：

修改端口號(hào)文件為 server.xml ：

修改首頁的路徑為：webapps/ROOT/index.jsp

　　修改完成之后，分別啟動(dòng)這兩個(gè)Tomcat服務(wù)器，然后分別輸入相應(yīng)的地址端口號(hào)：

輸入地址：localhost:8081

輸入地址：localhost:8080

　　二、修改 nginx 的配置文件 nginx.conf

upstream OrdinaryPolling {
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
    }
    server {
        listen       80;
        server_name  localhost;

        location / {
            proxy_pass http://OrdinaryPolling;
            index  index.html index.htm index.jsp;

        }
    }

三、啟動(dòng) nginx。然后在瀏覽器輸入localhost 地址，觀看頁面變化：

②、基于比例加權(quán)輪詢 　　上述兩臺(tái)Tomcat服務(wù)器基本上是交替進(jìn)行訪問的。但是這里我們有個(gè)需求：

由于Tomcat1服務(wù)器的配置更高點(diǎn)，我們希望該服務(wù)器接受更多的請(qǐng)求，而 Tomcat2 服務(wù)器配置低，希望其處理相對(duì)較少的請(qǐng)求。

那么這時(shí)候就用到了加權(quán)輪詢機(jī)制了。

nginx.conf 配置文件如下：

upstream OrdinaryPolling {
    server 127.0.0.1:8080 weight=5;
    server 127.0.0.1:8081 weight=2;
    }
    server {
        listen       80;
        server_name  localhost;

        location / {
            proxy_pass http://OrdinaryPolling;
            index  index.html index.htm index.jsp;

        }
    }

其實(shí)對(duì)比上面不加權(quán)的輪詢方式，這里在 upstream 指令中多了一個(gè) weight 指令。該指令用于配置前面請(qǐng)求處理的權(quán)重，默認(rèn)值為 1。

也就是說：第一種不加權(quán)的普通輪詢，其實(shí)其加權(quán)值 weight 都為 1。

下面我們看頁面相應(yīng)結(jié)果：

明顯 8080 端口號(hào)出現(xiàn)的次數(shù)更多，試驗(yàn)的次數(shù)越多越接近我們配置的比例。

③、基于IP路由負(fù)載 　　我們知道一個(gè)請(qǐng)求在經(jīng)過一個(gè)服務(wù)器處理時(shí)，服務(wù)器會(huì)保存相關(guān)的會(huì)話信息，比如session，但是該請(qǐng)求如果第一個(gè)服務(wù)器沒處理完，通過nginx輪詢到第二個(gè)服務(wù)器上，那么這個(gè)服務(wù)器是沒有會(huì)話信息的。

最典型的一個(gè)例子：用戶第一次進(jìn)入一個(gè)系統(tǒng)是需要進(jìn)行登錄身份驗(yàn)證的，首先將請(qǐng)求跳轉(zhuǎn)到Tomcat1服務(wù)器進(jìn)行處理，登錄信息是保存在Tomcat1 上的，這時(shí)候需要進(jìn)行別的操作，那么可能會(huì)將請(qǐng)求輪詢到第二個(gè)Tomcat2上，那么由于Tomcat2 沒有保存會(huì)話信息，會(huì)以為該用戶沒有登錄，然后繼續(xù)登錄一次，如果有多個(gè)服務(wù)器，每次第一次訪問都要進(jìn)行登錄，這顯然是很影響用戶體驗(yàn)的。

這里產(chǎn)生的一個(gè)問題也就是集群環(huán)境下的 session 共享，如何解決這個(gè)問題？

通常由兩種方法：

1、第一種方法是選擇一個(gè)中間件，將登錄信息保存在一個(gè)中間件上，這個(gè)中間件可以為 Redis 這樣的數(shù)據(jù)庫。那么第一次登錄，我們將session 信息保存在 Redis 中，跳轉(zhuǎn)到第二個(gè)服務(wù)器時(shí)，我們可以先去Redis上查詢是否有登錄信息，如果有，就能直接進(jìn)行登錄之后的操作了，而不用進(jìn)行重復(fù)登錄。

2、第二種方法是根據(jù)客戶端的IP地址劃分，每次都將同一個(gè) IP 地址發(fā)送的請(qǐng)求都分發(fā)到同一個(gè) Tomcat 服務(wù)器，那么也不會(huì)存在 session 共享的問題。

而 nginx 的基于 IP 路由負(fù)載的機(jī)制就是上訴第二種形式。大概配置如下：

upstream OrdinaryPolling {
    ip_hash;
    server 127.0.0.1:8080 weight=5;
    server 127.0.0.1:8081 weight=2;
    }
    server {
        listen       80;
        server_name  localhost;

        location / {
            proxy_pass http://OrdinaryPolling;
            index  index.html index.htm index.jsp;

        }
    }

注意：我們?cè)?upstream 指令塊中增加了 ip_hash 指令。該指令就是告訴 nginx 服務(wù)器，同一個(gè) IP 地址客戶端發(fā)送的請(qǐng)求都將分發(fā)到同一個(gè) Tomcat 服務(wù)器進(jìn)行處理。

④、基于服務(wù)器響應(yīng)時(shí)間負(fù)載分配

根據(jù)服務(wù)器處理請(qǐng)求的時(shí)間來進(jìn)行負(fù)載，處理請(qǐng)求越快，也就是響應(yīng)時(shí)間越短的優(yōu)先分配。

upstream OrdinaryPolling {
    server 127.0.0.1:8080 weight=5;
    server 127.0.0.1:8081 weight=2;
    fair;
    }
    server {
        listen       80;
        server_name  localhost;

        location / {
            proxy_pass http://OrdinaryPolling;
            index  index.html index.htm index.jsp;

        }
    }

通過增加了 fair 指令。

⑤、對(duì)不同域名實(shí)現(xiàn)負(fù)載均衡

通過配合location 指令塊我們還可以實(shí)現(xiàn)對(duì)不同域名實(shí)現(xiàn)負(fù)載均衡。

upstream wordbackend {
    server 127.0.0.1:8080;
    server 127.0.0.1:8081;
    }

    upstream pptbackend {
    server 127.0.0.1:8082;
    server 127.0.0.1:8083;
    }

    server {
        listen       80;
        server_name  localhost;

        location /word/ {
            proxy_pass http://wordbackend;
            index  index.html index.htm index.jsp;

        }
    location /ppt/ {
            proxy_pass http://pptbackend;
            index  index.html index.htm index.jsp;

        }
    }