nginx負載平衡策略與配置

這篇文章主要介紹了nginx負載平衡策略和配置，有著一定的參考價值，現在分享給大家，有需要的朋友可以參考一下

前言

先來簡單了解一下什麼是負載平衡，單從字面上的意思來理解就可以解釋N台伺服器平均分擔負載，不會因為某台伺服器負載高宕機而某台伺服器閒置的狀況。那麼負載平衡的前提就是要有多台伺服器才能實現，也就是兩台以上。負載平衡是高並發、大流量網站必須實現的技術。

環境

採用兩機負載平衡部署

  測試網域名稱  ：a.com

  A伺服器IP: 10.1.108.31 (#主機伺服器)

  B##伺服器 IP: 192.168.112.128

#部署想法

##  A

#伺服器做為主伺服器，網域直接解析到A伺服器（10.1.108.31 ）上，由A#伺服器負載均衡到自身（10.1.108.31 ）與B伺服器（192.168.112.128 ）上。

需要負載平衡的項目

#nodejs web

項目，項目名稱 social，連接埠6602。

分別在

A伺服器與B伺服器上啟動social 專案（如何啟動nodejs 專案在此不做介紹），在A伺服器上安裝 nginx（如何安裝在此不做介紹，B伺服器不需要安裝）。

部署

網域解析

由於不是真實環境，網域就隨便使用一個

a.com來當測試，所以a.com的解析只能在hosts檔案設定。

開啟：

C:\Windows\System32\drivers\etc\hosts##在最後加上

10.1.108.31  a.com

#

儲存退出，然後啟動指令模式ping下看看是否已設定成功

從截圖上看已成功將a.com解析到10.1.108.31

##配置

nginx.conf在

nginx

安裝目錄的

##conf

目錄下，開啟

nginx.conf

檔案#在http##片段加入以下程式碼

upstream a.com {

            server 127.0.0.1:6602;

            server 192.168.112.128:6602;

        }

server {

        listen       80;

        location / {

            proxy_pass http://a.com;      #设置反向代理的地址

            proxy_connect_timeout 2;      #代理服务器超时时间，秒

        }

註：2個節點，其中一個宕機了，

nginx

還是會分發請求給它，直到超時，沒有回應，然後發給另一個節點。預設1分鐘內不會再發請求，一分鐘後重複上述動作。這樣的結果是網站時快時慢，設定

proxy_connect_timeout

#為

2

秒，縮短超時時間，使其不會太慢。 儲存配置，啟動nginx#，造訪a.com##            1                          圖2如上圖所示，訪問了兩次

a.com，分別返回了

A

伺服器和

B

#伺服器中是資料。顯示

nginx負載平衡配置成功。 #erre

user    www-data;                        #运行用户worker_processes  4;                   #启动进程,通常设置成和cpu的核数相等

rrreelnginx配置詳解

worker_cpu_affinity 0001 0010 0100 1000;   #为每个进程绑定cpu内核，参考下面注解1

rrree
##1.worker_cpu_affinity
註解

#Nginx##預設沒有開啟利用多核心CPU,我們可以透過增加worker_cpu_affinity配置參數來充分利用多核心CPU。 CPU是任務處理，運算最關鍵的資源，CPU核越多，效能就越好。 配置Nginx多核心CPU,worker_cpu_affinity使用方法與範例2核心

CPU

#，開啟## ####2######個程式#########worker_processes     2;###worker_cpu_affinity 01 10;######

01表示啟用第一個CPU內核，10表示啟用第二個CPU內核
worker_cpu_affinity 01 10;表示開啟兩個行程，第一個行程對應著第一個CPU內核，第二個行程對應第二個CPU內核。

2核CPU,開啟4個行程
worker_processes     4;
worker_cpu_affinity 01 10 01 10;

開啟了四個進程，它們分別對應著開啟2個CPU核心

#4核CPU，開戶4個程序
worker_processes     4;
worker_cpu_affinity 0001 0010 0100 1000;

#0001表示啟用第一個CPU內核，0010表示啟用第二個CPU內核，依此類推

##4 核心CPU，開啟2個流程worker_processes     2;worker_cpu_affinity 0101 1010;

0101表示開啟第一個和第三個內核，1010
表示開啟第二個與第四個內核
2個行程對應四個核心
worker_cpu_affinity設定是寫在/etc/nginx/nginx.conf裡面的。
2核是 01，四核是0001，8核是00000001，有多少個核，就有幾位數，1表示該核心開啟，0表示該核心關閉。

8核CPU，開戶8個流程

worker_processes     8;worker_cpu_affinity 00000001 0000010 00000100 00001000 00010000 0010000001000000 10000000;

#0001##第一個CPU

##0001##第一個CPU##0001

第一個CPU##0001

第一個CPU010。 #worker_processes最多開啟8個，8個以上效能提升不會再提升了，而且穩定性變得更低，所以8個進程夠用了。

2.連線處理方式#nginx 支援多種連線處理方法，使用哪種方法取決於所使用的系統。系統支援多種方法時，nginx會自動選擇最高效的方法。如果需要，可以透過use指令指定使用的方法。 select:#1.Socket數量限制
: 此模式可操作的Socket數由FD_SETSIZE決定#,#核心預設32*32=1024. 2.#操作限制:透過遍歷FD_SETSIZE( 1024)個

Socket######來完成調度######,######不管哪個#####Socket### ###是活躍的######,######都遍歷一遍######. ######

poll:

#1.Socket#數量幾乎無限制:該模式下的Socket#對應的fd列表由一個陣列來保存,大小不限(#預設4k). 
2.操作限制:相同#Select. 

epoll:

##Linux 2.6以上版本
#1.Socket數量無限制:同Poll 2.#操作無限制:#基於核心提供的反射模式,有活躍Socket,

核心存取該

Socket的callback,

不需要遍歷輪詢

.

############################# ##kqueue ######：###############與######epoll######相差不大，原理相同，用於作業系統：######FreeBSD 4.1 , OpenBSD 2.9 , NetBSD 2.0, and MacOS X######

select模式低效率的原因
#select 模式低效是由select的定義所決定的，與作業系統實作無關，任何核心在實作select時必須做輪循，才能知道這些socket的情況，這是會消耗 cpu的。此外，當你擁有一個很大socket集的時候，儘管任一時間只有小部分的socket#是 "活躍"的，但每次你都必須將所有的socket#填入到一個FD_SET中，這也會消耗一些cpu，並且當select返回後，處理業務時你可能還需要做“上下文映射”#，同樣也會有一些效能影響，因此 select比epoll相對低效。
epoll的適用情境就是大量的socket，但活躍多不是很高的情況。

3.tcp_nodelay和tcp_nopush區別

tcp_nodelayNginx的 TCP_NODELAY 選項使得在開啟一個新的

socket

時增加了

TCP_NODELAY

選項。 但這時會造成一種情況：終端應用程式每產生一次操作就會發送一個包，而典型情況下一個套件會擁有一個位元組的資料以及

40

個位元組長的封包頭，於是產生4000%的過載，很輕易地就能令網路發生壅塞。 為了避免這種情況，

TCP######堆疊實作了等待資料###### 0.2#####秒鐘，因此操作後它不會發送一個資料包，而是將這段時間內的資料打成一個大的包。 ######

這個機制是由Nagle演算法保證。

Nagle化後來成了一種標準並且立即在網際網路上實現。現在它已經成為預設配置了，但有些場合下把這個選項關掉也是合乎需要的。

現在假設某個應用程式發出了一個請求，希望發送小塊資料。我們可以選擇立即發送資料或等待產生更多的資料然後再一次發送兩種策略。

如果我們馬上發送數據，那麼互動性的以及客戶/伺服器型的應用程式將會大大受益。如果請求立即發出那麼回應時間也會快一些。

以上運算可以透過設定套接字的 TCP_NODELAY = on 選項來完成，這樣就停用了 Nagle 演算法。     

另一種情況則需要我們等到資料量達到最大時才透過網路一次傳送全部數據，這種資料傳輸方式有益於大量資料的通訊效能，典型的應用就是檔案伺服器。

Nginx 在 keepalive 的連線中使用 TCP_NODELAY # 。 keepalive 連線會在資料發送後仍保持連線狀態，並且還允許透過它發送更多資料。

這樣就可以少實例化許多 socked 連線以及每次連線的三次握手過程。

tcp_nopush

#在 nginx 中， tcp_nopush 配置和 tcp_nodelay 互斥。它可以配置一次發送資料的包大小。

也就是說，它不是按時間累計  0.2 秒後發送包，而是當包累計到一定大小後就發送。

在 nginx 中，tcp_nopush 必須和# sendfile

搭配使用。

4.負載平衡

#nginx

#支援下面幾種負載平衡機制：

1）round-robin

：輪詢。以輪詢方式將請求分配到不同伺服器上，預設採用輪詢方式。 ######

2）least-connected：最少连接数。将下一个请求分配到连接数最少的那台服务器上。

3）ip-hash ：基于客户端的IP地址。散列函数被用于确定下一个请求分配到哪台服务器上。

在一些要求需要更长的时间才能完成的应用情况下，最少连接可以更公平地控制应用程序实例的负载。使用最少连接负载均衡，nginx不会向负载繁忙的服务器上分发请求，而是将请求分发到负载低的服务器上。配置如下：

upstream mysvr {

   least-connected
  server 192.168.8.1:3128
  server 192.168.8.2:80
  server 192.168.8.3:80
}

以上是nginx負載平衡策略與配置的詳細內容。更多資訊請關注PHP中文網其他相關文章！