網站首頁 編程語言 正文
跟著上面這篇博客進行操作即可。關閉防火墻,讓本地可以通過瀏覽器訪問Nginx
服務。
[root@localhost ~]# systemctl stop firewalld
信號量
查看信號量:
[root@localhost ~]# kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX
有64
種信號量,以下是幾種常用的信號量:
-
SIGINT
、SIGTERM
:快速關閉。 -
SIGQUIT
:從容關閉(優雅的關閉進程,即等請求結束后再關閉)。 -
SIGHUP
:平滑重啟,重新加載配置文件 (平滑重啟,修改配置文件之后不用重啟服務器)。 -
SIGUSR1
:重新讀取日志文件,在切割日志文件時用途較大。 -
SIGUSR2
:平滑升級可執行程序 ,nginx
升級時候用。 -
SIGWINCH
:從容關閉工作進程。
Nginx熱部署
Nginx
是一個多進程的高性能反向代理服務器,包含一個master
進程和多個worker
進程(worker
進程的數量可以通過nginx.conf
配置文件中的worker_processes
參數進行設置,默認1
個),這樣可以充分利用多核處理器。
默認1
個worker
進程。
并且master
進程和worker
進程是父子進程關系。
Nginx
工作模式為多進程,Nginx
在啟動之后會有一個master
進程和多個worker
進程(默認1
個),多個worker
子進程將監聽master
父進程監聽的端口(參考父子進程的關系),并行處理請求。master
父進程主要用來管理worker
子進程(管理真正提供服務的worker
進程,向worker
進程發送信號,監控worker
進程的運行狀態,當worker
進程異常退出后,會重新啟動新的worker
進程),讀取并驗證配置信息,master
進程不會對用戶請求提供服務,而用戶請求是由worker
進程進行處理。
Nginx
是通過信號量來控制,比如停止和重啟Nginx
。信號量是進程間通信的一種機制,master
主進程控制多個worker
子進程,也是通過信號量。
現在來演示Nginx
是怎么實現熱部署的,博主通過修改Nginx
的配置文件來模擬Nginx
的升級(先copy
一份副本)。
[root@localhost ~]# cd /usr/local/nginx/conf/ [root@localhost conf]# ll 總用量 68 -rw-r--r--. 1 root root 1077 12月 20 20:24 fastcgi.conf -rw-r--r--. 1 root root 1077 12月 20 20:24 fastcgi.conf.default -rw-r--r--. 1 root root 1007 12月 20 20:24 fastcgi_params -rw-r--r--. 1 root root 1007 12月 20 20:24 fastcgi_params.default -rw-r--r--. 1 root root 2837 12月 20 20:24 koi-utf -rw-r--r--. 1 root root 2223 12月 20 20:24 koi-win -rw-r--r--. 1 root root 5231 12月 20 20:24 mime.types -rw-r--r--. 1 root root 5231 12月 20 20:24 mime.types.default -rw-r--r--. 1 root root 2656 12月 20 21:26 nginx.conf -rw-r--r--. 1 root root 2656 12月 20 20:24 nginx.conf.default -rw-r--r--. 1 root root 636 12月 20 20:24 scgi_params -rw-r--r--. 1 root root 636 12月 20 20:24 scgi_params.default -rw-r--r--. 1 root root 664 12月 20 20:24 uwsgi_params -rw-r--r--. 1 root root 664 12月 20 20:24 uwsgi_params.default -rw-r--r--. 1 root root 3610 12月 20 20:24 win-utf [root@localhost conf]# cp nginx.conf nginx_old.conf [root@localhost conf]# vim nginx.conf
由于還沒有給Nginx
進行熱部署,現在訪問http://192.168.1.199/
還是原來的Nginx
頁面。
查看Nginx
的進程:
[root@localhost conf]# ps -ef | grep nginx root 14964 1 0 22:25 ? 00:00:00 nginx: master process ./nginx nobody 14965 14964 0 22:25 ? 00:00:00 nginx: worker process root 15016 1521 0 23:07 pts/0 00:00:00 grep --color=auto nginx
給master
進程發送SIGUSR2
信號,讓Nginx
平滑升級可執行程序。可以看到Nginx
重新啟動了一組master
進程和worker
進程,而新master
進程是舊master
進程的子進程(通過父子進程的繼承關系,新master
進程可以很方便地繼承舊master
進程的相關資源)。
[root@localhost conf]# kill -s SIGUSR2 14964 [root@localhost conf]# ps -ef | grep nginx root 14964 1 0 22:25 ? 00:00:00 nginx: master process ./nginx nobody 14965 14964 0 22:25 ? 00:00:00 nginx: worker process root 15019 14964 0 23:18 ? 00:00:00 nginx: master process ./nginx nobody 15020 15019 0 23:18 ? 00:00:00 nginx: worker process root 15022 1521 0 23:19 pts/0 00:00:00 grep --color=auto nginx
并且Nginx
在日志目錄中存儲了新舊pid
文件(保存了新舊master
進程的ID
)。
[root@localhost conf]# ll ../logs 總用量 16 -rw-r--r--. 1 root root 2729 12月 20 23:20 access.log -rw-r--r--. 1 root root 708 12月 20 23:18 error.log -rw-r--r--. 1 root root 6 12月 20 23:18 nginx.pid -rw-r--r--. 1 root root 6 12月 20 22:25 nginx.pid.oldbin [root@localhost conf]# cat ../logs/nginx.pid 15019 [root@localhost conf]# cat ../logs/nginx.pid.oldbin 14964
給舊master
進程發送SIGWINCH
信號,讓舊master
進程關閉舊worker
進程。
[root@localhost conf]# kill -s SIGWINCH 14964 [root@localhost conf]# ps -ef | grep nginx root 14964 1 0 22:25 ? 00:00:00 nginx: master process ./nginx root 15019 14964 0 23:18 ? 00:00:00 nginx: master process ./nginx nobody 15020 15019 0 23:18 ? 00:00:00 nginx: worker process root 15030 1521 0 23:27 pts/0 00:00:00 grep --color=auto nginx
現在訪問http://192.168.1.199/
,會響應404
。
而訪問http://192.168.1.199/nacos
,會訪問到Nacos
服務。
如果升級版本沒有問題,就可以給舊master
進程發送SIGQUIT
信號,讓舊master
進程關閉,這樣就只剩下新master
進程和新worker
進程,實現了Nginx
的熱部署。
[root@localhost conf]# kill -s SIGQUIT 14964 [root@localhost conf]# ps -ef | grep nginx root 15019 1 0 23:18 ? 00:00:00 nginx: master process ./nginx nobody 15020 15019 0 23:18 ? 00:00:00 nginx: worker process root 15034 1521 0 23:31 pts/0 00:00:00 grep --color=auto nginx
如果升級版本有問題,需要回滾到之前的版本,就可以給舊master
進程發送SIGHUP
信號,因為博主重新進行了測試,所以進程號都變了,但很顯然舊master
進程重新創建了舊worker
進程,并且進行版本升級的master
和worker
進程沒有被關閉。
[root@localhost conf]# kill -s SIGHUP 15084 [root@localhost conf]# ps -ef | grep nginx root 15084 1 0 12月20 ? 00:00:00 nginx: master process ./nginx root 15106 15084 0 12月20 ? 00:00:00 nginx: master process ./nginx nobody 15107 15106 0 12月20 ? 00:00:00 nginx: worker process nobody 15131 15084 0 00:02 ? 00:00:00 nginx: worker process root 15141 1521 0 00:09 pts/0 00:00:00 grep --color=auto nginx
給新master
進程發送SIGQUIT
信號,讓新master
進程關閉,這樣就只剩下舊master
進程和新創建的舊worker
進程,實現了回滾。
[root@localhost conf]# kill -s SIGQUIT 15106 [root@localhost conf]# ps -ef | grep nginx root 15084 1 0 12月20 ? 00:00:00 nginx: master process ./nginx nobody 15131 15084 0 00:02 ? 00:00:00 nginx: worker process root 15159 1521 0 00:25 pts/0 00:00:00 grep --color=auto nginx
回滾成功。
還需要對版本回滾(即博主這里的配置文件回滾,不然下次重啟就會出問題)。
[root@localhost conf]# cp -f nginx_old.conf nginx.conf cp:是否覆蓋"nginx.conf"? y
為什么給舊master
進程發送SIGHUP
信號,舊master
進程重新創建的worker
進程沒有重新讀取配置文件?下面是官方的說明:
Send the HUP signal to the old master process. The old master process will start new worker processes without re-reading the configuration. After that, all new processes can be shut down gracefully, by sending the QUIT signal to the new master process.
向舊
master
進程發送SIGHUP
信號。舊master
進程將啟動新worker
進程,而無需重新讀取配置。之后,通過向新master
進程發送SIGQUIT
信號,所有新進程都可以正常關閉。
如果不存在新進程的情況下(只有一組master
、worker
進程),修改配置文件,再向master
進程發送SIGHUP
信號,看是否會重新加載配置文件。
[root@localhost conf]# kill -s SIGHUP 15084
很顯然配置文件被重新加載了,由于博主還沒有看源碼,只能猜測Nginx
的實現(如果說錯了,請大家評論補充),Nginx
應該是根據當前是否在進行熱部署(存在新master
進程),來決定SIGHUP
信號是否需要重新加載配置文件。
原文鏈接:https://blog.csdn.net/qq_37960603/article/details/122050480
相關推薦
- 2022-06-29 徹底掌握C語言strcat函數的用法_C 語言
- 2022-04-19 賭你會懵的C語言指針進階數組場景解析_C 語言
- 2022-05-21 redis數據一致性的實現示例_Redis
- 2022-06-06 基于VSTS的Xamarin.Android持續集成步驟詳解_Android
- 2022-10-03 python接口自動化使用requests庫發送http請求_python
- 2023-06-21 Rust?Atomics?and?Locks并發基礎理解_Rust語言
- 2022-08-05 call(), apply(), bind()有什么區別?
- 2022-05-31 Android實現調用手機攝像頭錄像限制錄像時長_Android
- 最近更新
-
- window11 系統安裝 yarn
- 超詳細win安裝深度學習環境2025年最新版(
- Linux 中運行的top命令 怎么退出?
- MySQL 中decimal 的用法? 存儲小
- get 、set 、toString 方法的使
- @Resource和 @Autowired注解
- Java基礎操作-- 運算符,流程控制 Flo
- 1. Int 和Integer 的區別,Jav
- spring @retryable不生效的一種
- Spring Security之認證信息的處理
- Spring Security之認證過濾器
- Spring Security概述快速入門
- Spring Security之配置體系
- 【SpringBoot】SpringCache
- Spring Security之基于方法配置權
- redisson分布式鎖中waittime的設
- maven:解決release錯誤:Artif
- restTemplate使用總結
- Spring Security之安全異常處理
- MybatisPlus優雅實現加密?
- Spring ioc容器與Bean的生命周期。
- 【探索SpringCloud】服務發現-Nac
- Spring Security之基于HttpR
- Redis 底層數據結構-簡單動態字符串(SD
- arthas操作spring被代理目標對象命令
- Spring中的單例模式應用詳解
- 聊聊消息隊列,發送消息的4種方式
- bootspring第三方資源配置管理
- GIT同步修改后的遠程分支