轉載 深刻理解Nginx及使用Nginx實現負載均衡

轉載：https://developer.51cto.com/art/202001/609322.htm

 

正向代理是代理客戶端，也就是客戶端能真正接觸到的，好比訪問外網時須要使用***軟件，在這個軟件中用戶能夠選擇鏈接哪裏的服務器。

 

 

前言

最近在部署項目時要求實現負載均衡，有趣的是發現網上一搜所有都是如下相似的配置文件

1. upstream localhost{ 
2.  server 127.0.0.1:8080 weight=1; 
3.  server 127.0.0.1:8081 weight=1; 
4.  } 
5.  server { 
6.  listen 80; 
7.  server_name localhost; 
8.  location / { 
9.  proxy_pass http://localhost; 
10.  index index.html index.htm index.jsp; 
11.   
12.  } 
13.  } 

因此打算來看看Nginx內部原理，這篇博客主要介紹Nginx如何實現反向代理以及在Nginx中負載均衡的參數使用

1、正向代理與反向代理

正向代理是代理客戶端，也就是客戶端能真正接觸到的，好比訪問外網時須要使用***軟件，在這個軟件中用戶能夠選擇鏈接哪裏的服務器。

反向代理則是代理服務端，用戶感知不到，只是客戶端把請求發到服務端的端口時，Nginx監聽到了便把該端口的請求轉發到不一樣的服務器上。就以上面配置文件來說解，當在網址中輸入http://localhost:80/時(不加80同樣時默認進入80端口，這裏爲了表示清楚)，然後Nginx監聽到80端口的請求以後，就會查找對應的location來執行。由上面的配置文件咱們能夠看出是將請求轉發到了不一樣的端口。這是在服務器中執行的，用戶不可見。

而服務端中咱們最常使用的反向代理的工具就是Nginx。

2、Nginx內部基本架構

nginx在啓動後以daemon的方式在後臺運行，會有一個master進程和多個worker進程。

master進程：主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出後(異常狀況下)，會自動從新啓動新的worker進程。

worker進程：處理基本的網絡事件了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。worker進程的個數是能夠設置的，通常咱們會設置與機器cpu核數一致，或者直接設置參數worker_processes auto;

因此Nginx基本的架構就以下：

當咱們輸入./nginx -s reload，就是來重啓nginx，./nginx -s stop，就是來中止nginx的運行，這裏面是如何作到的?執行命令時，咱們是啓動一個新的nginx進程，而新的nginx進程在解析到reload參數後，就知道咱們的目的是控制nginx來從新加載配置文件了，它會向master進程發送信號。master進程在接到信號後，會先從新加載配置文件，而後再啓動新的worker進程，並向全部老的worker進程發送信號，告訴他們能夠光榮退休了。新的worker在啓動後，就開始接收新的請求，而老的worker在收到來自master的信號後，就再也不接收新的請求，而且在當前進程中的全部未處理完的請求處理完成後，再退出。因此使用上面命令重啓Nginx的時候服務是不中斷的。

3、Nginx如何處理客戶端請求

首先來解釋一下上面的架構圖：每一個worker進程都是從master進程分支過來的，在master進程裏面，先創建好須要監聽的socket以後，而後再分支出多個worker進程。全部worker進程的listenfd(socket中listenfd是指客戶端鏈接本機時的fd,是用來和客戶端通訊用的)會在新鏈接到來時變得可讀，爲保證只有一個進程處理該鏈接，全部worker進程在註冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程註冊listenfd讀事件，在讀事件裏調用accept接受該鏈接。

在Nginx中worker進程之間是平等的，每一個進程，處理請求的機會也是同樣的。當Nginx監聽80端口時，一個客戶端的鏈接請求過來，每一個進程都有可能處理這個鏈接，上面說到是每一個worker進程都會去搶注listenfd讀事件。當一個worker進程在accept這個鏈接以後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開鏈接，這樣一個完整的請求就是這樣的了。這裏須要注意的是一個請求，徹底由worker進程來處理，並且只在一個worker進程中處理。

下面兩幅流程圖能很好的幫咱們理解

4、Nginx如何處理事件而且實現高併發

Nginx內部採用了異步非阻塞的方式來處理請求，也就是說，Nginx是能夠同時處理成千上萬個請求的。

異步非阻塞：當一個網絡請求過來時，咱們並不依賴於這個請求才能作後續操做，那麼這個請求就是異步操做，也就是調用者在沒有獲得結果以前一樣能夠執行後續的操做。非阻塞就是當前進程/線程沒有獲得請求調用的結果時也不會妨礙到進程/線程後續的操做。能夠看出異步和非阻塞的對象是不一樣的。

5、Nginx負載均衡的算法及參數

round robin(默認)：輪詢方式，依次將請求分配到後臺各個服務器中，適用於後臺機器性能一致的狀況，若服務器掛掉，能夠自動從服務列表中剔除

weight：根據權重來分發請求到不一樣服務器中，能夠理解爲比例分發，性能較高服務器分多點請求，較低的則分少點請求

IP_hash：根據請求者ip的hash值將請求發送到後臺服務器中，保證來自同一ip的請求被轉發到固定的服務器上，解決session問題

1. upstream localhost {  
2. ip_hash;  
3. server 127.0.0.1:8080;  
4. server 127.0.0.1:8080;  
5. }  

上面是最基本的三種算法，咱們還能夠經過改變參數來自行配置負載均衡

1. upstream localhost{  
2. ip_hash;  
3. server 127.0.0.1:9090 down;  
4. server 127.0.0.1:8080 weight=2;  
5. server 127.0.0.1:6060;  
6. server 127.0.0.1:7070 backup;  
7. } 

參數列表以下：