Nginx實現(xiàn)負載均衡和反向代理的方法
Nginx概述
http://nginx.org/en/download.html
Nginx是由俄羅斯人研發(fā)的,應(yīng)對Rambler的網(wǎng)站,并且2004年發(fā)布的第一個版本。
Nginx是lgor Sysoev為俄羅斯訪問量第二的rambler.ru站點設(shè)計開發(fā)的。從2004年發(fā)布至今,憑借開源的力量,已經(jīng)接近成熟與完善。
Nginx功能豐富,可作為HTTP服務(wù)器,也可作為反向代理服務(wù)器,郵件服務(wù)器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。并且支持很多第三方的模塊擴展。
Nginx的穩(wěn)定性、功能集、示例配置文件和低系統(tǒng)資源的消耗讓他后來居上,在全球活躍的網(wǎng)站中有12.18%的使用比率,大約為2220萬個網(wǎng)站。
Nginx的特點:
- 穩(wěn)定性極強。 7*24小時不間斷運行。
- Nginx提供了非常豐富的配置實例。
- 占用內(nèi)存小,并發(fā)能力強(官方給的數(shù)據(jù)是5w)
- 負載均衡策略
- 動靜態(tài)分離
- 擅長處理靜態(tài)資源,tomcat擅長處理動態(tài)資源
Nginx作用
正向代理

正向代理是給客戶端做代理,客戶端清楚要訪問的目標服務(wù)器。
正向代理服務(wù)器作用如下
- 訪問原來無法訪問的資源
- 用作緩存,加速訪問速度
- 對客戶端訪問授權(quán),上網(wǎng)進行認證
- 代理可以記錄用戶訪問記錄(上網(wǎng)行為管理),對外隱藏用戶信息
反向代理

反向代理給服務(wù)端做代理,客戶但不知道要訪問那臺服務(wù)器。
反向代理服務(wù)器作用如下:
- 保護內(nèi)網(wǎng)安全
- 負載均衡
- 緩存,減少服務(wù)器的壓力
負載均衡
將多個請求均勻的分配到多臺服務(wù)器上,減輕每臺服務(wù)器的壓力,提高服務(wù)的吞吐量。
Nginx提供的負載均衡策略有2種:
內(nèi)置策略:輪詢,權(quán)重,Ip hash。
擴展策略:fair(會根據(jù)后端服務(wù)器的響應(yīng)時間來分配請求,以實現(xiàn)更加均衡的負載分配。fair策略會優(yōu)先將請求發(fā)送到響應(yīng)時間較短的服務(wù)器上,從而提高整體性能和穩(wěn)定性。)
Ip hash算法:對客戶端請求的ip進行hash操作,然后根據(jù)hash結(jié)果將同一個客戶端ip的請求分發(fā)給同一臺服務(wù)器進行處理,可以解決session不共享的問題
動靜分離

? 動靜分離是指在web服務(wù)器架構(gòu)中,將靜態(tài)頁面與動態(tài)頁面或者靜態(tài)內(nèi)容接口和動態(tài)內(nèi)容接口分開不同系統(tǒng)訪問的架構(gòu)設(shè)計方法,進而提升整個服務(wù)訪問性能和可維護性。
1、代理服務(wù)器和靜態(tài)服務(wù)器即為一臺服務(wù)器上,這里只是為了明顯區(qū)分動靜分離所處服務(wù)器的不同;
2、靜態(tài)服務(wù)器中,存放的資源主要是源代碼文件、圖片、屬性、樣式以及其它所有非動態(tài)的資源文件;
3、調(diào)度規(guī)則,即為代理服務(wù)器,這里是Nginx的服務(wù)器調(diào)度規(guī)則;
4、動態(tài)服務(wù)器,其種類比較繁多,可以是Apache、Tomcat、IIS以及其它Web服務(wù)器,它們一般分別隸屬于一臺服務(wù)器;
Nginx的安裝 -->Docker
安裝Nginx
使用Docker-Compose安裝
version: '3.1'
services:
nginx:
restart: always
image: daocloud.io/library/nginx:latest
container_name: nginx
ports:
- 80:80
Nginx的配置文件
關(guān)于Nginx的核心配置文件nginx.conf
worker_processes 1;
error_log /var/log/nginx/error.log warn;
# 以上統(tǒng)稱為全局塊,
# worker_processes他的數(shù)值越大,Nginx的并發(fā)能力就越強
# error_log 代表Nginx的錯誤日志存放的位置
events {
worker_connections 1024;
}
# events塊
# worker_connections他的數(shù)值越大,Nignx并發(fā)能力越強
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
# location塊
# root:將接收到的請求根據(jù)/usr/share/nginx/html去查找靜態(tài)資源
# index: 默認去上述的路徑中找到index.html或者index.htm
}
# server塊
# listen: 代表Nginx監(jiān)聽的端口號
# localhost:代表Nginx接收請求的ip
}
# http塊
# include代表引入一個外部的文件 -> /mime.types中放著大量的媒體類型
# include /etc/nginx/conf.d/*.conf; -> 引入了conf.d目錄下的以.conf為結(jié)尾的配置文件
修改docker-compose文件
為了方便修改Nginx配置,修改yml文件
version: '3.1'
services:
nginx:
restart: always
image: daocloud.io/library/nginx:latest
container_name: nginx
ports:
- 80:80
volumes:
- /opt/docker_nginx/conf.d/:/etc/nginx/conf.d
Nginx源碼安裝
1、下載nginx源碼包
wget http://nginx.org/download/nginx-1.20.1.tar.gz
2、解壓
tar -zxf nginx-1.20.1.tar.gz
3、安裝c/c++的編譯器
yum install gcc yum install gcc-c++ yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel
因為下載的包是源碼包,需要編譯,安裝后才能使用。而nginx是c寫的,因此需要安裝c/c++的編譯器


如上,gcc已經(jīng)安裝完畢,下面來安裝nginx
4、安裝nginx
1、進入nginx目錄 2、 ./configure 3、make install

5、安裝成功后的位置
nginx默認會按照在/usr/local/nginx中

nginx常用命令
./nginx 啟動 ./nginx -s stop 停止 ./nginx -s reload 重啟(重新加載nginx配置文件) ./nginx -v 查看nginx版本號
nginx配置文件
配置文件位置

配置文件結(jié)構(gòu)詳情
########### 每個指令必須有分號結(jié)束。#################
#user administrator administrators; #配置用戶或者組,默認為nobody nobody。
worker_processes 1; #允許生成的進程數(shù),默認為1
#pid /nginx/pid/nginx.pid; #指定nginx進程運行文件存放地址
error_log log/error.log debug; #制定日志路徑,級別。這個設(shè)置可以放入全局塊,http塊,server塊,級別以此為:debug|info|notice|warn|error|crit|alert|emerg
events {
accept_mutex on; #設(shè)置網(wǎng)路連接序列化,防止驚群現(xiàn)象發(fā)生,默認為on
multi_accept on; #設(shè)置一個進程是否同時接受多個網(wǎng)絡(luò)連接,默認為off
#use epoll; #事件驅(qū)動模型,select|poll|kqueue|epoll|resig|/dev/poll|eventport
worker_connections 1024; #最大連接數(shù),默認為512
}
http {
include mime.types; #文件擴展名與文件類型映射表
default_type application/octet-stream; #默認文件類型,默認為text/plain
#access_log off; #取消服務(wù)日志
log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定義格式
access_log log/access.log myFormat; #combined為日志格式的默認值
sendfile on; #允許sendfile方式傳輸文件,默認為off,可以在http塊,server塊,location塊。
sendfile_max_chunk 100k; #每個進程每次調(diào)用傳輸數(shù)量不能大于設(shè)定的值,默認為0,即不設(shè)上限。
keepalive_timeout 65; #連接超時時間,默認為75s,可以在http,server,location塊。
upstream mysvr {
server 127.0.0.1:7878;
server 192.168.10.121:3333 backup; #熱備
}
error_page 404 https://www.baidu.com; #錯誤頁
error_page 500 https://www.jd.com; #錯誤頁
server {
keepalive_requests 120; #單連接請求上限次數(shù)。
listen 4545; #監(jiān)聽端口
server_name 127.0.0.1; #監(jiān)聽地址
location ~*^.+$ { #請求的url過濾,正則匹配,~為區(qū)分大小寫,~*為不區(qū)分大小寫。
#root path; #根目錄
#index vv.txt; #設(shè)置默認頁
proxy_pass http://mysvr; #請求轉(zhuǎn)向mysvr 定義的服務(wù)器列表
deny 127.0.0.1; #拒絕的ip
allow 172.18.5.54; #允許的ip
}
}
}
1、全局塊 2、events塊 3、http塊 a)server塊 1)location塊
- 全局塊:配置影響nginx全局的指令。一般有運行nginx服務(wù)器的用戶組,nginx進程pid存放路徑,日志存放路徑,配置文件引入,允許生成worker process數(shù)等。
- events塊:配置影響nginx服務(wù)器或與用戶的網(wǎng)絡(luò)連接。有每個進程的最大連接數(shù),選取哪種事件驅(qū)動模型處理連接請求,是否允許同時接受多個網(wǎng)路連接,開啟多個網(wǎng)絡(luò)連接序列化等。
- http塊:可以嵌套多個server,配置代理,緩存,日志定義等絕大多數(shù)功能和第三方模塊的配置。如文件引入,mime-type定義,日志自定義,是否使用sendfile傳輸文件,連接超時時間,單連接請求數(shù)等。
- server塊:配置虛擬主機的相關(guān)參數(shù),一個http中可以有多個server。
- location塊:配置請求的路由,以及各種頁面的處理情況。
Nginx的反向代理【重點】
基于Nginx實現(xiàn)反向代理
準備一個目標服務(wù)器。
啟動了之前的tomcat服務(wù)器。
編寫default.conf配置文件,通過Nginx訪問到tomcat服務(wù)器。
# 監(jiān)聽80端口
server{
listen 80;
server_name localhost;
# 基于反向代理訪問到Tomcat服務(wù)器
location / {
proxy_pass http://192.168.199.109:8081/;
}
}
關(guān)于Nginx的location路徑映射
優(yōu)先級關(guān)系如下:
(location=) > (location /aa/bb/cc) > (location ~)
# 1. 精確匹配
location = / {
# 精準匹配,主機名后面不能帶任何的字符串,等號決定匹配的內(nèi)容,比如:http://baidu.com
}
# 案例
# 用戶訪問# http:192.168.193.88/abc nginx
#會自動代理到 http://192.168.193.88:8080/
location =/abc {
proxy_pass http://192.168.193.88:8080/;
}
# 2. 通用匹配
location /xxx {
# 匹配所有以/xxx開頭的路徑,比如:http://baidu.com/xxx
}
# 案例
# 用戶訪問訪問 http://192.168.193.88/qfjava/webdemo/index.jsp
#會自動代理到 http://192.168.193.88:8080/webdemo/index.jsp
location /qfjava {
proxy_pass http://192.168.193.88:8080/;
}
# 3. 正則匹配
location ~ /xxx {
# 匹配所有以/xxx開頭的路徑
}
# 4. 匹配開頭路徑
location ^~ /images/ {
# 匹配所有以/images開頭的路徑
}
# 5. 匹配后綴
location ~* \.(gif|jpg|png)$ {
# 匹配以gif或者jpg或者png為結(jié)尾的路徑
}
# 6. 全部通配
location / {
# 匹配全部路徑
}
Nginx負載均衡【重點】
Nginx為我們默認提供了三種負載均衡的策略:
- 輪詢:將客戶端發(fā)起的請求,平均的分配給每一臺服務(wù)器
- 權(quán)重:會將客戶端的請求,根據(jù)服務(wù)器的權(quán)重值不同,分配不同的數(shù)量。
- ip_hash:基于發(fā)起請求的客戶端的ip地址不同,他始終會將請求發(fā)送到指定的服務(wù)器上。
輪詢
想實現(xiàn)Nginx輪詢負載均衡機制只需要在配置文件中添加以下內(nèi)容
upstream 名字 { # 給空格
server ip:port; # 給分號 server 192.168.193.66:8080
server ip:port;
...
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://upstream的名字/; # 給分號
}
}
權(quán)重
實現(xiàn)權(quán)重的方式
# 名字中不要出現(xiàn)下?lián)Q線
upstream 名字 {
server ip:port weight=權(quán)重比例; # server 192.168.193.66:8080 weight=8;
server ip:port weight=權(quán)重比例; # server 192.168.193.66:8080 weight=2;
...
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://upstream的名字/;
}
}
ip_hash
ip_hash實現(xiàn)
upstream 名字 {
ip_hash;
server ip:port;
server ip:port;
...
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://upstream的名字/;
}
}
fair
fair 模塊(第三方)來實現(xiàn)負載均衡,fair 采用的不是內(nèi)建的算法,而是可以根據(jù)頁面大小、響應(yīng)時間智能的進行負載均衡。
upstream 名字 {
server ip:port;
server ip:port;
fair;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://upstream的名字/;
}
}
upstream模塊中的常用參數(shù)
upstream linuxe_backend {
server 192.168.1.110 down; #該節(jié)點不可用
server 192.168.1.120 backup; #其他節(jié)點掛了后該節(jié)點自動上線
server 192.168.1.130 max_failes=1 fail_timeout=10s weight=5;
server backend1.linuxe.cn 8080 weight=3 max_conns=10;
}
server:負載均衡后端服務(wù)器的IP或域名,不寫端口的話默認是80。高并發(fā)場景用域名,再通過DNS進行負載均衡 weight:后端服務(wù)器權(quán)重,默認為1,權(quán)重越大接收的請求越多。例:weight=5 max_fails:檢查節(jié)點的健康狀態(tài)并允許請求失敗的次數(shù),達到該次數(shù)就將節(jié)點下線。默認為1,0表示禁止失敗嘗試。例:max_fails=2 fail_timeout:max_fails失敗次數(shù)達到限制后暫停該節(jié)點服務(wù)的時間,默認是10秒。例:fail_timeout=10s backup:熱備配置,當(dāng)服務(wù)池中所有服務(wù)器均出現(xiàn)問題后會自動上線backup服務(wù)器 down:標志服務(wù)器不可用,不參與負載均衡。這個參數(shù)通常配合IP_HASH使用 max_conns:限制最大連接數(shù),通常對后端服務(wù)器硬件不一致的情況進行配置
Nginx動靜分離【重點】
動靜分離是指在web服務(wù)器架構(gòu)中,將靜態(tài)頁面與動態(tài)頁面或者靜態(tài)內(nèi)容接口和動態(tài)內(nèi)容接口分開不同系統(tǒng)訪問的架構(gòu)設(shè)計方法,進而提升整個服務(wù)訪問性能和可維護性。
動:必須依賴服務(wù)器返回,比如Controller,數(shù)據(jù)庫相關(guān)操作。
靜:不需要依賴容器的比如css/js/html或者圖片等文件
Nginx的并發(fā)能力公式:
? worker_processes * worker_connections / 4 | 2 = Nginx最終的并發(fā)能力
動態(tài)資源需要/4,靜態(tài)資源需要/2.
Nginx通過動靜分離,來提升Nginx的并發(fā)能力,更快的給用戶響應(yīng)。
動態(tài)資源代理
使用proxy_pass動態(tài)代理
# 配置如下
location / {
proxy_pass 服務(wù)器的路徑;
}
靜態(tài)資源代理
使用root或者alias靜態(tài)代理
server{
listen 80;
server_name localhost;
location /html {
root data; // 在data/html下面找文件
index a.html; # 配置默認頁面
}
location /images {
root data; // 在data/images下面找文件
autoindex on; # 地址欄訪問 http://192.168.193.88/images/
}
}
root 和alias指令區(qū)
location /img/ {
alias /var/www/image/;
}
若按照上述配置的話,則訪問/img/目錄里面的文件時,ningx會自動去/var/www/image/目錄找文件
location /img/ {
root /var/www/image;
}
若按照這種配置的話,則訪問/img/目錄下的文件時,nginx會去/var/www/image/img/目錄下找文件
alias是一個目錄別名的定義,root則是最上層目錄的定義。
還有一個重要的區(qū)別是alias后面必須要用“/”結(jié)束,否則會找不到文件的。。。而root則可有可無
權(quán)限項目部署
# 權(quán)限服務(wù)器集群
upstream rbac {
server 172.30.77.207:8082;
server 172.30.77.207:8083;
}
server {
listen 80;
server_name localhost;
location / { # 反向代理到后端服務(wù)器
proxy_pass http://rbac;
}
location /rbac { # 權(quán)限項目前端相關(guān)靜態(tài)頁面
root data;
index index.html;
}
}
前端頁面訪問:http://www.2105.com/rbac/login.html
后臺接口訪問:http://www.2105.com/user/page
后臺接口取消上下文路徑,多個應(yīng)用可以根據(jù)端口號或者location來區(qū)分。
Nginx高可用
什么是高可用
高可用HA(High Availability)是分布式系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一,它通常是指,通過設(shè)計減少系統(tǒng)不能提供服務(wù)的時間。
假設(shè)系統(tǒng)一直能夠提供服務(wù),我們說系統(tǒng)的可用性是100%。
如果系統(tǒng)每運行100個時間單位,會有1個時間單位無法提供服務(wù),我們說系統(tǒng)的可用性是99%。很多公司的高可用目標是4個9,也就是99.99%,這就意味著,系統(tǒng)的年停機時間為8.76個小時。

在生產(chǎn)環(huán)境上很多時候是以
Nginx做反向代理對外提供服務(wù),但是一天Nginx難免遇見故障,如:服務(wù)器宕機。當(dāng)Nginx宕機那么所有對外提供的接口都將導(dǎo)致無法訪問。
雙機熱備+自動故障轉(zhuǎn)移
這種方案是國內(nèi)企業(yè)中最為普遍的一種高可用方案,雙機熱備其實就是指一臺服務(wù)器在提供服務(wù),另一臺為某服務(wù)的備用狀態(tài),當(dāng)一臺服務(wù)器不可用另外一臺就會頂替上去。
有了雙機熱備方案之后,還不夠,每次出現(xiàn)故障需要人工介入恢復(fù)勢必會增加系統(tǒng)的不可服務(wù)實踐。所以,又往往是通過自動故障轉(zhuǎn)移來實現(xiàn)系統(tǒng)的高可用。
Nginx如何解決高可用的

Nginx解決高可用需要準備兩臺nginx,一個是主(Master)服務(wù)器,一個是備(backup)服務(wù)器,使用keepalived基于主和備可以創(chuàng)建出一臺虛擬服務(wù)器供客戶端調(diào)用。虛擬服務(wù)器接收到請求會先把請求交給主服務(wù)器處理,如果主服務(wù)器宕機就把請求交給備服務(wù)器處理。
Keepalived是什么
Keepalived軟件起初是專為LVS(Linux Virtual Server,Linux虛擬服務(wù)器)負載均衡軟件設(shè)計的,用來管理并監(jiān)控LVS集群系統(tǒng)中各個服務(wù)節(jié)點的狀態(tài),后來又加入了可以實現(xiàn)高可用的VRRP (Virtual Router Redundancy Protocol ,虛擬路由器冗余協(xié)議)功能。因此,Keepalived除了能夠管理LVS軟件外,還可以作為其他服務(wù)(例如:Nginx、Haproxy、MySQL等)的高可用解決方案軟件
Keepalived實現(xiàn)Nginx高可用
安裝前需要準備好兩臺虛擬器,兩臺都需要安裝nginx和keepalived。
192.168.147.10(主)
192.168.147.11(備)
1、安裝keepalived
yum -y install keepalived # 配置文件在/etc/keepalived/keepalived.conf
2、修改主服務(wù)器keepalived.conf
# 檢測腳本
vrrp_script chk_http_port {
script "/usr/local/src/check_nginx_pid.sh" #心跳執(zhí)行的腳本,檢測nginx是否啟動
interval 2 #(檢測腳本執(zhí)行的間隔,單位是秒)
weight 2 #權(quán)重
}
#vrrp 實例定義部分
vrrp_instance VI_1 {
state MASTER # 指定keepalived的角色,MASTER為主,BACKUP為備
interface ens33 # 當(dāng)前進行vrrp通訊的網(wǎng)絡(luò)接口卡(當(dāng)前centos的網(wǎng)卡) 用ifconfig查看你具體的網(wǎng)卡
virtual_router_id 66 # 虛擬路由編號,主從要一直
priority 100 # 優(yōu)先級,數(shù)值越大,獲取處理請求的優(yōu)先級越高
advert_int 1 # 檢查間隔,默認為1s(vrrp組播周期秒數(shù))
track_script {
chk_http_port #(調(diào)用檢測腳本)
}
virtual_ipaddress {
192.168.147.88 # 定義虛擬ip(VIP),可多設(shè),每行一個
}
}
virtual_ipaddress 里面可以配置vip,在線上通過vip來訪問服務(wù)。
interface需要根據(jù)服務(wù)器網(wǎng)卡進行設(shè)置通常查看方式ip addr
3、修改備服務(wù)器配置文件
檢測腳本
vrrp_script chk_http_port {
script "/usr/local/src/check_nginx_pid.sh" #心跳執(zhí)行的腳本,檢測nginx是否啟動
interval 2 #(檢測腳本執(zhí)行的間隔)
weight 2 #權(quán)重
}
#vrrp 實例定義部分
vrrp_instance VI_1 {
state BACKUP # 指定keepalived的角色,MASTER為主,BACKUP為備
interface ens33 # 當(dāng)前進行vrrp通訊的網(wǎng)絡(luò)接口卡(當(dāng)前centos的網(wǎng)卡) 用ifconfig查看你具體的網(wǎng)卡
virtual_router_id 66 # 虛擬路由編號,主從要一直
priority 99 # 優(yōu)先級,數(shù)值越大,獲取處理請求的優(yōu)先級越高
advert_int 1 # 檢查間隔,默認為1s(vrrp組播周期秒數(shù))
track_script {
chk_http_port #(調(diào)用檢測腳本)
}
virtual_ipaddress {
192.168.147.88 # 定義虛擬ip(VIP),可多設(shè),每行一個
}
}
4、檢測腳本
/usr/local/src/check_nginx_pid.sh
#檢測nginx是否啟動了
A=`ps -C nginx --no-header |wc -l`
if [ $A -eq 0 ];then #如果nginx沒有啟動就啟動nginx
systemctl start nginx #重啟nginx
if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then #nginx重啟失敗,則停掉keepalived服務(wù),進行VIP轉(zhuǎn)移
killall keepalived
fi
fi
5、腳本授權(quán)
chmod 700 check_nginx_pid.sh # 腳本必須通過授權(quán),不然沒權(quán)限訪問
6、啟動keepalived
systemctl start keepalived

搭建高可用需要注意一下幾點
1、keepalived啟動先ngixn必須是啟動成功的,否則keepalived啟動不了
2、nginx停止后keepalived也會停止
3、主宕機后啟動順序是先啟動nginx,在啟動keepalived
7、測試順序
1、主備都啟動時訪問速虛擬主機請求會交給主處理
2、把主中的nginx關(guān)閉后,請求會交給備服務(wù)器處理
Keepalived實現(xiàn)自動故障轉(zhuǎn)移
Keepalived高可用服務(wù)之間的故障切換轉(zhuǎn)移,是通過VRRP來實現(xiàn)的。
在Keepalived服務(wù)正常工作時,主Master節(jié)點會不斷地向備節(jié)點發(fā)送(多播的方式)心跳消息,用以告訴備Backup節(jié)點自己還活著,當(dāng)主Master節(jié)點發(fā)生故障時,就無法發(fā)送心跳消息,備節(jié)點也就因此無法繼續(xù)檢測到來自主Master節(jié)點的心跳了,于是調(diào)用自身的接管程序,接管主Master節(jié)點的 IP資源及服務(wù)。而當(dāng)主 Master節(jié)點恢復(fù)時,備Backup節(jié)點又會釋放主節(jié)點故障時自身接管的IP資源及服務(wù),恢復(fù)到原來的備用角色。
Nginx的進程模型
Nginx啟動成功默認會有兩個進程,master和work。


Master進程
master進程主要用來管理worker進程,具體包括如下4個主要功能:
1、接收來自外界的信號。
2、向各worker進程發(fā)送信號。
3、監(jiān)控woker進程的運行狀態(tài)。
4、當(dāng)woker進程退出后(異常情況下),會自動重新啟動新的woker進程
5、熱加載ngixn配置文件
master進程充當(dāng)整個進程組與用戶的交互接口,同時對進程進行監(jiān)護。它不需要處理網(wǎng)絡(luò)事件,不負責(zé)業(yè)務(wù)的執(zhí)行,只會通過管理worker進程來實現(xiàn)重啟服務(wù)、平滑升級、更換日志文件、配置文件實時生效等功能。
? 我們要控制nginx,只需要通過kill向master進程發(fā)送信號就行了。比如kill -HUP pid,則是告訴nginx,從容地重啟nginx,我們一般用這個信號來重啟nginx,或重新加載配置,因為是從容地重啟,因此服務(wù)是不中斷的。
? kill -HUP 是用來向指定進程發(fā)送一個HUP信號,許多程序在收到HUP信號時,會重新讀取配置文件
master進程在接收到HUP信號后是怎么做的呢?
1)首先master進程在接到信號后,會先重新加載配置文件,然后再啟動新的worker進程,并向所有老的worker進程發(fā)送信號,告訴他們可以光榮退休了。
2)新的worker在啟動后,就開始接收新的請求,而老的worker在收到來自master的信號后,就不再接收新的請求,并且在當(dāng)前進程中的所有未處理完的請求處理完成后,再退出。
work進程
? work進程主要用來處理網(wǎng)絡(luò)請求,像網(wǎng)絡(luò)事件,則是放在worker進程中來處理了。多個worker進程之間是對等的,他們同等競爭來自客戶端的請求,各進程互相之間是獨立的。一個請求,只可能在一個worker進程中處理,一個worker進程,不可能處理其它進程的請求。worker進程的個數(shù)是可以設(shè)置的(默認是1),一般我們會設(shè)置與機器cpu核數(shù)一致,這里面的原因與nginx的進程模型以及事件處理模型是分不開的。
? worker進程之間是平等的,每個進程,處理請求的機會也是一樣的
當(dāng)我們提供80端口的http服務(wù)時,一個連接請求過來,每個work進程都有可能處理這個連接,怎么做到的呢?
Nginx采用異步非阻塞的方式來處理網(wǎng)絡(luò)事件,類似于Libevent,具體過程如下:
1)接收請求:首先,每個worker進程都是從master進程fork過來,在master進程建立好需要listen的socket(listenfd)之后,然后再fork出多個worker進程。所有worker進程的listenfd會在新連接到來時變得可讀,每個work進程都可以去accept這個socket(listenfd)。當(dāng)一個client連接到來時,所有accept的work進程都會受到通知,但只有一個進程可以accept成功,其它的則會accept失敗。為保證只有一個進程處理該連接,Nginx提供了一把共享鎖accept_mutex來保證同一時刻只有一個work進程在accept連接。所有worker進程在注冊listenfd讀事件前搶accept_mutex,搶到互斥鎖的那個進程注冊listenfd讀事件,在讀事件里調(diào)用accept接受該連接。
2)處理請求:當(dāng)一個worker進程在accept這個連接之后,就開始讀取請求,解析請求,處理請求,產(chǎn)生數(shù)據(jù)后,再返回給客戶端,最后才斷開連接,這樣一個完整的請求就是這樣的了。
? 我們可以看到,一個請求,完全由worker進程來處理,而且只在一個worker進程中處理。worker進程之間是平等的,每個進程,處理請求的機會也是一樣的。
以上就是Nginx實現(xiàn)負載均衡和反向代理的方法的詳細內(nèi)容,更多關(guān)于Nginx負載均衡和反向代理的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
nginx實現(xiàn)根據(jù)URL轉(zhuǎn)發(fā)請求的實戰(zhàn)經(jīng)歷
這篇文章主要給大家介紹了一次關(guān)于nginx實現(xiàn)根據(jù)URL轉(zhuǎn)發(fā)請求的實戰(zhàn)經(jīng)歷,文中通過示例代碼介紹的非常詳細,對大家學(xué)習(xí)或者使用nginx具有一定的參考學(xué)習(xí)價值,需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧2019-11-11
通過nginx反向代理來調(diào)試代碼的實現(xiàn)
這篇文章主要介紹了通過nginx反向代理來調(diào)試代碼的實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-01-01
Nginx服務(wù)器中設(shè)置禁止訪問文件或目錄的方法
這篇文章主要介紹了Nginx服務(wù)器中設(shè)置禁止訪問文件或目錄的方法,對于協(xié)同遠程管理服務(wù)器的情況來講很有實用性,需要的朋友可以參考下2015-07-07
canary環(huán)境使用nginx實現(xiàn)原理分析
文章介紹了通過Nginx實現(xiàn)前端頁面多環(huán)境的配置方法,根據(jù)請求頭或Cookie中的`canary`值判斷轉(zhuǎn)發(fā)地址,文章還指出現(xiàn)有方法的不足,如需要修改配置和重啟Nginx,不易操作且容易出錯,最后,文章提到可以通過Nginx支持Rust特性進行改進,并計劃后續(xù)研究更新2026-01-01
Nginx在高并發(fā)架構(gòu)中配置靜態(tài)文件地址的實戰(zhàn)指南
在高并發(fā)架構(gòu)中,Nginx不僅僅是一個Web服務(wù)器,更是整個系統(tǒng)的流量守門人和性能加速器,為什么你的網(wǎng)站明明用了Nginx,卻依然感覺慢?為什么一上并發(fā)就出現(xiàn)502/504錯誤,今天,我們就深入剖析如何通過精準配置Nginx靜態(tài)文件參數(shù),需要的朋友可以參考下2026-01-01

