Nginx學習----Nginx平滑重新開機+負載均衡測試

一、配置檔案中pid的作用?

上一篇Nginx學習----Nginx配置反向代理、負載均衡中，對這個pid沒有太了解

#通過 PID 檔案可以判斷是否已經有一個執行個體正在運作。防止意外啟動多個程序執行個體
pid   /var/run/nginx.pid;

重裝了nginx,本來測試kill -HUP pid 重新讀取配置檔案，不小心将啟動指令執行了兩次，準備kill的時候發現：

[[email protected] nginx]# ps -ef|grep nginx
root      968928       1  0 09:17 ?        00:00:00 nginx: master process sbin/nginx -c conf/nginx.conf
nobody    968929  968928  0 09:17 ?        00:00:00 nginx: worker process
root      968959       1  0 09:23 ?        00:00:00 nginx: master process sbin/nginx -c conf/nginx.conf
nobody    968960  968959  0 09:23 ?        00:00:00 nginx: worker process
root      968962  968870  0 09:23 pts/2    00:00:00 grep --color=auto nginx

于是配置pid檔案路徑，重新執行上述步驟：

注意：将預設關閉的打開即可，或者指定路徑，如 /var/run/nginx.pid;

# pid        logs/nginx.pid;

啟動前可以test下配置檔案的正确性

sbin/nginx -t -c conf/nginx.conf
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful

多次啟動後：

[[email protected] nginx]# sbin/nginx -c conf/nginx.conf             
[[email protected] nginx]# sbin/nginx -c conf/nginx.conf
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

檢視程序：

[[email protected] nginx]# ps -ef|grep nginx
root      969091       1  0 10:01 ?        00:00:00 nginx: master process sbin/nginx -c conf/nginx.conf
nobody    969092  969091  0 10:01 ?        00:00:00 nginx: worker process
root      969102  968985  0 10:07 pts/3    00:00:00 grep --color=auto nginx

一、Nginx平滑重新開機

重新開機包括：

重新開機服務： service nginx restart
快速停止或關閉Nginx：nginx -s stop
正常停止或關閉Nginx，不接受新的連接配接請求，等待舊的連接配接請求處理完畢再關閉：nginx -s quit
配置檔案修改重裝載指令1：nginx -s reload
配置檔案修改重裝載指令2：kill -HUP nginxPid

我們來讨論下 kill -HUP nginxPid（同reload）

當 nginx 接收到 HUP 信号，它會嘗試先解析配置檔案（如果指定配置檔案，就使用指定的，否則使用預設的），成功的話，就應用新的配置檔案（例如：重新打開日志檔案或監聽的套接字）。之後，nginx 運作新的工作程序并從容關閉舊的工作程序。通知工作程序關閉監聽套接字但是繼續為目前連接配接的客戶提供服務。所有用戶端的服務完成後，舊的工作程序被關閉。如果新的配置檔案應用失敗，nginx 将繼續使用舊的配置進行工作。

摘抄自：Nginx文檔

在重載前，要先測試一下配置檔案：

/usr/sbin/nginx -t -c /etc/nginx/nginx.conf

測試邏輯

在nginx啟動時，修改/usr/local/nginx/html/index.html，複制一份為index2.html，并将其在nginx.conf中配置到index的左側。test配置檔案有效性，kill -HUP nginxPid 的同時浏覽器不斷重新整理，頁面内容會從index.html轉為index2.html，此時ps檢視nginx的pid，并沒有發生變化
重複測試上述步驟，cd到nginx目錄下，sbin/nginx -c conf/nginx.conf -s reload 方式，效果同上，且此時ps檢視nginx的pid，并沒有發生變化。

腳本快捷指令

一般生産環境會使用腳本啟動，如下：下載下傳位址

也可以通過vim建立：

[[email protected] ~]# vim /etc/init.d/nginx

NGINX=/usr/local/nginx/sbin/nginx
PID=/usr/local/nginx/logs/nginx.pid
start()
{
	if [ -f $PID ] 
	then
		echo "nginx已經啟動!"
	else
		$NGINX
		echo "nginx啟動成功!"
	fi
}
stop()
{
	if [ -f $PID ]
	then
		killall -s QUIT nginx
		echo "nginx已經關閉!"
	else
		echo "nginx未啟動!"
	fi
}
restart()
{	
	if [ -f $PID ]
	then
		stop
	fi
	start
}
reload()
{
 kill -s HUP $(cat $PID)
}
case $1 in
"start") start
	;;
"stop") stop
	;;
"restart") restart
	;;
"reload") reload
	;;
*) echo "請輸入正确的操作參數start|stop|restart|reload"
	;;
esac

建立好後需要執行chmod指令将其變為可執行檔案，如chmod 777 nginx

二、Nginx負載均衡

我們根據政策進行測試：

預設輪詢：可權重重等其他資訊
ip_hash：ip hash
least_conn：最少通路

準備部署兩個簡單項目，端口不同用于辨別服務，啟動jar

nohup java -jar hello2.jar >catalina.out  2>&1 &

nohup command > /dev/null 2>&1 &

nohup 代表忽略hup信号， & 代表以背景job形式運作 command > /dev/null 代表stdout輸出到空檔案 2>&1 中的2>代表stderr輸出，&1代表前面/dev/null的引用（檔案描述符）而已，這種寫法減少檔案IO操作，效率高

這裡/dev/null這個目錄表示黑洞，即支援寫入的空檔案。這個在nginx的配置檔案中，要想關閉error_log,隻有一種方式：把他輸出到/dev/null這個目錄下。詳見Nginx學習----Nginx配置反向代理、負載均衡

批量發送請求采用postMan,比較簡單，可以參考部落格：批量發送請求

未添加nginx之前的通路：

Nginx學習----Nginx平滑重新開機+負載均衡測試

1.預設輪詢

主要修改配置如下：下載下傳連結nginx.conf

upstream project_name {
 server 127.0.0.1:8885 weight=100 max_fails=3 fail_timeout=5s;
 server 127.0.0.1:8886 weight=100 max_fails=3 fail_timeout=5s;
}
server {
  # START BASIC CONFIG
  listen 80;

  server_name localhost
  ....
   location /login2 {
    proxy_pass        http://project_name;

注意：project_name指向的就是負載均衡的名稱

修改後，平滑重新開機：采用上一節的腳本：/etc/init.d/nginx reload

測試

：1. 通路100次，2.以是否傳回的是hello2字元串為判斷标準，如下：

Nginx學習----Nginx平滑重新開機+負載均衡測試

通過上圖，輪詢的是1：1的,現在修改權重，改為9：1，reload後重複測試，如下圖：

server 127.0.0.1:8885 weight=9 max_fails=3 fail_timeout=5s;
server 127.0.0.1:8886 weight=1 max_fails=3 fail_timeout=5s;

Nginx學習----Nginx平滑重新開機+負載均衡測試

ip_hash

修改配置：

ip_hash;
server 127.0.0.1:8885 weight=9 max_fails=3 fail_timeout=5s;
server 127.0.0.1:8886 weight=1 max_fails=3 fail_timeout=5s;

Nginx學習----Nginx平滑重新開機+負載均衡測試

由于我本地ip相同，結果都是一緻的，隻能算是個正向測試。

least_conn最少通路

least_conn算法很簡單，首選周遊後端叢集，比較每個後端的conns/weight，選取該值最小的後端。

如果有多個後端的conns/weight值同為最小的，那麼對它們采用權重輪詢算法。

server 127.0.0.1:8885 weight=2 max_fails=3 fail_timeout=5s;
server 127.0.0.1:8886 weight=1 max_fails=3 fail_timeout=5s;

Nginx學習----Nginx平滑重新開機+負載均衡測試

那nginx負載和springcloud的gateWay有什麼差別呢？

nginx的負載均衡是為了承壓，gateWay更像是業務分發，抽取各服務的通用功能

參考部落格：

Nginx可以做什麼？看完這篇你就懂了

如果其中一個服務挂了，nginx可以判斷出來而把請求都分發給正常的伺服器嗎？

Nginx學習----Nginx平滑重新開機+負載均衡測試

一、配置檔案中pid的作用?

一、Nginx平滑重新開機

測試邏輯

腳本快捷指令

二、Nginx負載均衡

1.預設輪詢

ip_hash

least_conn最少通路

繼續閱讀

nginx虛拟主機配置及負載均衡示例

歡迎使用CSDN-markdown編輯器Nginx配置檔案nginx.conf中文詳解（總結）

雲伺服器部署項目：vue-cli 部署服務配置

win7 localhost 配置 nginx ssl自簽名證書步驟報錯相關連結

（Nginx）03_Nginx原理與優化一、Nginx原理二、master-workers機制三、面試題：

（Nginx）02_Nginx配置執行個體一、Nginx的應用：反向代理實作一：二、反向代理執行個體二：三、Nginx的配置執行個體三–負載均衡：四、Nginx的配置執行個體四–動靜分離：Nginx在實際開發中的應用：

nginx配置示例

niginx的location的location詳細規則和優先級關系以及測試案例2.1比對文法2.2優先級判斷2.3練習3.1處理邏輯如何執行3.2功能測試3.3流程解析

Puppet自動化Nginx+Mongrel負載均衡配置

Ubuntu修改nginx将多個域名分别配置到伺服器不同端口

修改or隐藏nginx版本号

Nginx安全改動：隐藏Nginx版本号背景解決serve_tokens指令參考

版本号隐藏

Nginx服務優化（版本隐藏、版本号僞裝、逾時管理、程序管理、日志分割）Nginx服務優化未完待續

nginx location中斜線的位置的重要性