一種NGINX伺服器負載均衡的實現方法及系統與流程

2023-05-06 07:20:11 1

本發明涉及計算機網絡通信領域，特別涉及一種NGINX伺服器負載均衡的實現方法及系統。

背景技術：

伺服器集群的出現解決了海量Web並發訪問問題。然而現實應用中，伺服器集群往往出現負載不均衡的問題：一部分伺服器高負載運行，而另一部分伺服器卻處於空閒。

NINGX伺服器作為一種高性能的負載均衡伺服器在伺服器集群中有著廣泛的應用。其實現負載均衡的主要方法是輪詢法，即均勻地選擇後端伺服器處理請求。而對於伺服器性能有差異的情況，則可採用加權輪詢的方法，使得分配伺服器的比率與其權值成正比。由於請求的業務內容不同，對伺服器資源的需求也不一樣，考慮請求的業務類型，現有的負載均衡方法是一組伺服器處理對應的一類業務。但是，當某類業務請求較多時，會造成對應的一組伺服器處於高負載，而其他組的伺服器則處於空閒狀態。

技術實現要素：

有鑑於此，本發明的目的在於提供一種NGINX伺服器負載均衡的實現方法及系統，通過觸髮式的機制動態地監測後端伺服器的負載狀態，結合業務類型來判斷伺服器處理各類業務的能力，根據伺服器當前的負載狀態和業務處理能力，合理地選擇後端伺服器處理請求，以到達負載均衡的目的。

為達到上述目的，本發明提供如下技術方案：

一種NGINX伺服器負載均衡的實現方法，該方法包括以下步驟：

NGINX伺服器通過觸髮式機制更新後端伺服器集群的資源信息；所述資源信息包括伺服器的CPU利用率、內存利用率、磁碟I/O利用率及網絡帶寬利用率；

所述NGINX伺服器接收到客戶端的HTTP請求後，採用負載均衡算法選擇後端伺服器處理該HTTP請求，並將伺服器處理結果返回給客戶端；

所述負載均衡算法為根據不同的業務類型及後端伺服器集群的資源信息，計算後端伺服器在各種業務類型下的負載值，選擇該HTTP請求所屬的業務類型中負載值最小的後端伺服器處理該HTTP請求。

進一步，所述負載均衡算法具體包括以下步驟：

根據各種業務類型對後端伺服器的CPU利用率、內存利用率、磁碟I/O利用率及網絡帶寬利用率等資源信息配置不同的權值；

計算所述後端伺服器在各種業務類型中的負載均衡因子，所述負載均衡因子用於反映後端伺服器Si在業務類型j中負載情況；

選擇HTTP請求所屬的業務類型中負載均衡因子最小的後端伺服器處理該HTTP請求。

進一步，所述NGINX伺服器通過觸髮式機制更新後端伺服器集群的資源信息，通過以下方式實現：

所述NGINX伺服器向後端伺服器分配請求任務後，所述NGINX伺服器主動發送獲取資源信息的請求，後端伺服器響應該請求，NGINX伺服器更新該後端伺服器的資源信息和負載狀況。

進一步，所述NGINX伺服器通過觸髮式機制更新後端伺服器集群的資源信息，通過以下方式實現：

所述後端伺服器完成某請求任務後，向NGINX伺服器發送當前的後端伺服器的資源信息，NGINX伺服器更新該後端伺服器的資源信息和負載狀況。

進一步，所述業務類型包括計算密集型、多媒體處理型、內容傳輸型和資料庫訪問型。

一種NGINX伺服器負載均衡系統，包括客戶端、NGINX伺服器、後端伺服器集群；

所述客戶端用於向伺服器發出HTTP請求，所述HTTP請求經過負責負載均衡的NGINX伺服器，再轉發到後端的伺服器集群；

所述NGINX伺服器用於接收客戶端的HTTP請求，分析請求URL的業務類型，然後根據業務類型和後端伺服器集群資源信息，採用負載均衡算法選擇後端伺服器處理該HTTP請求，並將後端伺服器處理結果返回給客戶端；

所述後端伺服器集群為性能各異的伺服器，用於處理NGINX伺服器分配的請求，並將處理結果返回給NGINX伺服器；同時，動態地向NGINX伺服器反饋自身資源信息。

進一步，所述NGINX伺服器包括URL分析模塊、資源信息採集模塊、調度算法模塊；

所述URL分析模塊用於根據請求URL，分析HTTP請求的業務類型，：所述業務類型包括計算密集型、多媒體處理型、內容傳輸型和資料庫訪問型；

所述資源信息採集模塊用於動態地獲取後端伺服器集群的資源信息並予以保存；

所述調度算法模塊用於根據當前HTTP請求的業務類型及後端伺服器集群的資源信息，選擇後端伺服器處理該HTTP請求。

進一步，所述資源信息採集模塊採用權利要求3或4所述的方法獲取後端伺服器集群的資源信息並予以保存。

進一步，所述調度算法模塊採用負載均衡算法選擇後端伺服器處理該HTTP請求，然後將伺服器處理結果返回給客戶端；

所述負載均衡算法為根據不同的業務類型及後端伺服器集群的資源信息，計算後端伺服器在各種業務類型下的負載值，選擇該HTTP請求所屬的業務類型中負載值最小的後端伺服器處理該HTTP請求。

本發明的有益效果在於：本發明提供的一種NGINX伺服器負載均衡的實現方法及系統，通過觸髮式的機制動態地監測後端伺服器的實時資源信息，並採用負載均衡算法結合業務類型及後端伺服器的負載狀態合理地選擇後端伺服器處理請求，以到達負載均衡的目的。與現有技術相比具有以下優勢：

1.採用負載均衡算法合理地選擇後端伺服器，適用於後端伺服器性能不同的業務系統，而無須事先給各伺服器分配權值。

2.後端伺服器無須為按業務類型分類，避免了伺服器只處理某類型業務造成的負載不均衡。

3.通過觸髮式機制更新各後端伺服器資源信息，避免了周期性收集時，周期過長信息更新不及時和周期過短增加負荷等問題。

附圖說明

為了使本發明的目的、技術方案和有益效果更加清楚，本發明提供如下附圖進行說明：

圖1為本發明所述伺服器負載均衡系統組織結構圖；

圖2為本發明所述方法的流程圖。

具體實施方式

下面將結合附圖，對本發明的優選實施例進行詳細的描述。

本發明提供的一種NGINX伺服器負載均衡系統，如圖1所示，主要包括客戶端、NGINX伺服器和後端伺服器集群。

客戶端：用戶通過終端設備，向伺服器發出各種HTTP請求，該請求會先經過負責負載均衡的NGINX伺服器，再轉發到後端的伺服器集群。

NGINX伺服器：負責接收客戶端的HTTP請求，首先分析請求URL的業務類型，然後根據業務類型和動態收集的後端伺服器集群資源信息，採用負載均衡算法選擇合理的後端伺服器處理該HTTP請求，最後將伺服器處理結果返回給客戶端。

後端伺服器集群：由性能各異的伺服器組成，負責處理NGINX伺服器分配的請求，並將處理結果返回給NGINX伺服器。同時，動態地向NGINX伺服器反饋自身負載情況。

其中，NGINX伺服器為負載均衡系統最核心的部分，NGINX伺服器主要包括URL分析模塊、資源信息採集模塊、調度算法模塊。

URL分析模塊：該模塊用於根據請求URL，分析HTTP請求的業務類型。常見的業務類型包括計算密集型、多媒體處理型、內容傳輸型和資料庫訪問型；不同類型的業務對伺服器資源信息的需求也不一樣。

計算密集型：如電子商務類的Web業務請求，由於安全通信的需求，涉及大量的加解密操作，需要消耗大量的CPU。

多媒體處理型：如需要伺服器提高音頻和視頻的流媒體服務，需要佔用伺服器大量的內存和CPU資源。

內容傳輸型：如大文件的傳輸請求，對伺服器的帶寬要求較高。

資料庫訪問型：該類型的業務來自用戶的資料庫動態查詢，需要伺服器密集的磁碟訪問，對磁碟I/O資源要求比較高。

資源信息採集模塊：主要用於通過觸髮式機制動態地採集後端伺服器集群的資源信息，以及對伺服器處理能力的動態預測。資源信息包括伺服器的CPU利用率、內存利用率、磁碟I/O利用率及網絡帶寬利用率。

區別於現有技術中的周期性採集方法，本模塊採用了動態觸髮式的資源信息採集方法。該方法包括了兩種資源信息更新機制：

主動更新：當NGINX伺服器向後端伺服器分配請求任務後，NGINX伺服器發送獲取資源信息的請求，後端伺服器響應該請求，NGINX伺服器主動更新該後端伺服器的資源信息和負載狀況，並據此更新該後端伺服器處理能力。

被動更新：當後端伺服器完成某請求任務後，向NGINX伺服器發送當前的伺服器資源信息，NGINX伺服器接收到該信息後，資源信息採集模塊更新該後端伺服器的資源信息和負載狀況，並據此更新該後端伺服器處理能力。

具體而言，資源信息採集模塊的主要工作如下：

伺服器負載均衡系統中包括N臺伺服器，用符號i(1≤i≤N)標記，則該NGINX伺服器的後端伺服器集群可表示為S＝[S1,S2,…,SN]。

請求的業務類型總數為n,可表示j,1≤j≤n。

資源信息分別表示t時刻，伺服器Si的CPU，內存，磁碟I/O以及網絡帶寬的利用率，且時，表示t時刻,伺服器Si的某項資源利用率達到100％，已無可用資源；時，表示t時刻,伺服器Si的某項資源利用率為0，該項資源完全可用。

表示第j類業務對伺服器Si各項資源的平均需求，用該伺服器的資源利用率刻畫，如表示該項業務平均需佔用伺服器Si內存50％的資源。

假設t時刻，伺服器Si的資源信息為Ri(t),

(1)主動更新後，即伺服器Si的資源信息為Ri(t+Δt)，則該伺服器的資源利用率變化為

根據分配的業務類型，按如下方式更新

如果(初始值)，

否則，

(2)被動更新後，伺服器Si的資源信息為Ri(t+Δt)，則該伺服器的資源利用率變化為

類似地，根據主動更新時的規則更新

調度算法模塊：該模塊負責根據當前的HTTP請求的業務類型和後端伺服器資源信息，採用負載均衡算法選擇後端伺服器處理該HTTP請求。

用戶可根據各種業務類型對系統的CPU，內存，磁碟I/O以及網絡帶寬等資源配置不同的權值

在本方法中，對於給定的伺服器Si，業務類型j和當前的定義如下負載均衡因子：

則對於伺服器集群S，從小到大構成如下隊列：

對於n種業務類型的系統，該模塊則需要負責維持Q1,Q2,…,Qn，n個隊列。由於n的值比較小，因此不會給NGINX伺服器帶來很大的負擔。

當新的請求到來時，NGINX伺服器根據請求的業務類型，選擇位於對應的隊列最前端的伺服器處理該請求。

當NGINX伺服器分配給伺服器Si一個j類型的業務請求或者後端伺服器Si處理完一個j類型的業務請求後，調度算法模塊將最新的資源信息，更新值，並採用插值法更新其在隊列Qj中的位置。

在具體實施例中，如圖2所示，本發明所提供的一種NGINX伺服器負載均衡的實現方法，具體包括以下步驟：

S1：客戶端發送HTTP請求；

S2：NIGINX伺服器接收該請求，並通過URL分析模塊分析該HTTP請請求的業務類型；

S3：調度算法模塊選擇對應業務類型隊列的最前端伺服器，即處理對應業務類型中負載最小的後端伺服器，並將該請求發送給該伺服器。

S4：伺服器處理該請求。

S5：觸發資源信息主動更新機制，資源信息採集模塊向該伺服器發送獲取資源信息的請求。

S6：伺服器接收到獲取資源信息的請求後，在規定時間內，調用作業系統的接口，獲取本機的CPU、內存、磁碟I/O和網絡帶寬的利用率情況，並將結果反饋給NGINX的資源信息採集模塊。

S7：資源信息採集模塊更新伺服器的負載信息及該項業務對該伺服器性能需求，並將更新後的信息發送給調度算法模塊。

S8：調度算法模塊重新計算該伺服器的負載因子，並更新所有隊列，等待下一請求。

S9：伺服器完成該請求，將處理的結果返回NGINX伺服器。

S10：伺服器獲取完成請求後本機的CPU、內存、磁碟I/O和網絡帶寬的利用率情況，並將結果發送給NGINX的資源信息採集模塊。

S11：NGINX伺服器將處理結果返回給客戶端。

S12：資源信息採集模塊更新伺服器的負載信息及該項業務對該伺服器性能需求，並將更新後的信息發送給調度算法模塊。

S13：調度算法模塊重新計算該伺服器的負載因子，並更新所有隊列，等待下一請求。

最後說明的是，以上優選實施例僅用以說明本發明的技術方案而非限制，儘管通過上述優選實施例已經對本發明進行了詳細的描述，但本領域技術人員應當理解，可以在形式上和細節上對其作出各種各樣的改變，而不偏離本發明權利要求書所限定的範圍。