(如下學習筆記內容均摘自參考連接,僅供我的查閱)html
1、inotify文件系統監控特性linux
Inotify 是一個 Linux 內核特性,它監控文件系統,而且及時向專門的應用程序發出相關的事件警告,好比刪除、讀、寫和卸載操做等。inotify是Linux內核提供的一個文件系統變化通知機制,從2.6.13版本的內核開始提供,好比你在建立一個文件時它能夠通知你哪一個文件被建立了,刪除文件時通知你哪一個文件被刪除了,修改文件時通知你哪一個文件被修改了,關閉文件時哪一個文件被關閉了,是可寫關閉仍是不可寫關閉等等。nginx
2、Nginx配置熱更新git
NginX採用Master/Worker的多進程模型,Master進程負責整個NginX進程的管理。主要包括:熱更新、停機、日誌重啓等。github
NginX的配置修改以後,在不影響當前服務的狀況下進行更新。docker
信號: HUP後端
過程: 分爲Master部分和Worker部分。服務器
Matser進程:app
1> 經過ngx_signal_hanlder解析出獲取的信號,置ngx_reconfigure=1,標識Master要進行配置熱更新操做。負載均衡
2> 調用ngx_init_cycle初始化新的cycle(從新加載nginx.conf以及各模塊的初始化)。
3> 調用ngx_start_worker_process啓動新的Worker子進程,子進程標識just_respwan=1(NGX_PROCESS_JUST_RESPAWN)表示剛啓動,區分新舊進程。
4> 調用ngx_start_cache_manager啓動新的cache manager子進程和cache loader子進程。子進程標識just_respawn=1(NGX_PROCESS_JUST_RESPAWN)表示剛啓動,區分新舊進程。
5> 睡眠100毫秒以後,調用ngx_signal_worker_process優雅的關閉老的worker、cache manager和cache loader進程。注意:只向just_respawn=0的進程進行發送信號。
Worker進程:
1> 經過ngx_signal_handler解析出爲QUIT信號,置ngx_quit=1
2> 調用ngx_close_listening_sockets關閉監聽端口。設置ngx_exting=1
3> 若是定時器紅黑樹中爲空,執行ngx_worker_process_exit退出。
3. Nginx可執行程序熱更新
Nginx可執行程序升級後,在不影響當前服務的狀況下進行更新。
步驟1:信號:USR2
過程:
Master進程:
1> 經過ngx_signal_handler解析獲取信號,置ngx_change_binary=1。
2> 調用ngx_new_binary=ngx_exec_new_binary 函數啓動新的binary的NginX。(期間:須要進行老的環境變量的拷貝、socket句柄的傳遞、pid文件的拷貝等)。
此時,系統中同時存在兩個Nginx(新、老)同時提供服務。
Woker進程:
無操做
步驟2:信號:WINCH
過程:
Master進程:
1> 經過ngx_signal_handler解析獲取信號,置ngx_noaccept=1。
2> 置ngx_noaccepting=1,調用ngx_signal_worker_processes向子進程發送QUIT信號。即Worker進程優雅的退出。
若是此時沒啥問題就能夠直接關閉老的NginX Master進程了。(若是有問題,還有相似過程的回滾操做...)
3、Nginx可執行程序熱更新流程步驟
步驟一、升級nginx二進制文件,須要先將新的nginx可執行文件替換原有舊的nginx文件,而後給nginx master進程發送USR2信號,告知其開始升級可執行文件;nginx master進程會將老的pid文件增長.oldbin後綴,而後拉起新的master和worker進程,並寫入新的master進程的pid。
步驟二、在此以後,全部工做進程(包括舊進程和新進程)將會繼續接受請求。這時候,須要發送WINCH信號給nginx master進程,master進程將會向worker進程發送消息,告知其須要進行graceful shutdown,worker進程會在鏈接處理完以後進行退出。
步驟三、通過一段時間以後,將會只會有新的worker進程處理新的鏈接。
注意,舊master進程並不會關閉它的listen socket;由於若是出問題後,須要回滾,master進程須要法從新啓動它的worker進程。
步驟四、若是升級成功,則能夠向舊master進程發送QUIT信號,中止老的master進程;若是新的master進程(意外)退出,那麼舊master進程將會去掉本身的pid文件的.oldbin後綴。
nginx熱更新相關信號
master進程相關信號
USR2 升級可執行文件
WINCH 優雅中止worker進程
QUIT 優雅中止master進程
worker進程相關信號
TERM, INT 快速退出進程
QUIT 優雅中止進程
什麼是graceful shutdown
本文中的graceful shutdown是指server再也不處理新的鏈接,可是進程不會當即退出,待全部鏈接斷開後再退出進程。
總結一下在nginx 二進制文件熱升級時用的命令
cd /usr/local/nginx
cp nginx nginx_bak
mv /data/nginx/nginx ./nginx #須要使用mv來更新二進制文件
./nginx -t #嘗試啓動,查看其加載配置文件等初始化功能是否正常
netstat -anp | grep -E "80|443" | grep nginx #檢查鏈接狀態
kill -USR2 `cat /usr/local/nginx/nginx.pid` #升級nginx可執行文件,此時會有兩組nginx master和worker進程
kill -WINCH `cat /usr/local/nginx/nginx.pid.oldbin` #新的可執行文件啓動ok,且可以正常處理數據流,告知老的master進程去通知其worker進程進行優雅退出
...
kill -QUIT `cat /usr/local/nginx/nginx.pid.oldbin` #待全部的老的nginx worker進程優雅退出後(處理完鏈接),中止老的master進程
TODO:nginx還會有依賴的so文件的熱升級–其實更應該屬於後臺進程的so文件熱升級流程,我在使用它的時候也踩過坑–主要緣由仍是操做不規範,對so其加載運行原理不夠熟悉致使
熱升級
實際上,靜態語言後端server有一套固定的熱升級(單進程)流程,其基本流程以下:
若須要支持熱升級的是多進程,那麼nginx的熱升級過程是最值得參考的
一、經過調用 fork/exec 啓動新的版本的進程,
二、子進程調用接口獲取從父進程繼承的 socket 文件描述符從新監聽 socket
三、在此過程當中,不會對用戶請求形成任何中斷。
nginx的熱升級流程也是相似,只不過因爲nginx工做是多進程,故它會先啓動新版本的一組master/worker進程;而後中止老的worker進程,讓其不處理鏈接,由新的worker進程來處理鏈接;升級完畢後,便可退出老的master進程,熱升級完成。
4、Nginx upstream中 backup備份服務器的做用
Nginx 的 upstream 配置的時候,能夠配置備份服務器 backup。
upstream backend {
server 192.168.198.128:8080 weight=1;
server 192.168.198.128:8090 weight=4;
server 192.168.198.128:8091 backup;
}
backup : marks the server as a backup server. It will be passed requests when the primary servers are unavailable.(標記爲備用服務器。當主服務器不可用之後,請求會被傳給這些服務器。)
這意思就是,只有當你的服務器掛掉的時候纔會使用備份服務器,正常狀況下不會訪問到備份服務器。
在全部正常服務器都掛掉時,系統依然高可用,這就是備份服務器的用處!
5、《Kubernetes集羣中的Nginx配置熱更新方案》原理:
Nginx自身是支持配置熱更新的,經過nginx -s reload命令能夠實現這一點。咱們要實現的就是:當Kubernetes集羣中的Service發生變化時,好比新建立一個Service或刪除了一個Service,這些Service在Nginx反向代理中的路由配置須要同步更新並生效。所以,這個過程的場景大體以下:
5.1管理員經過命令或程序經過API操做K8s集羣建立或刪除Service;
5.2監聽API Server Event的某個程序獲取該Event,並從API Server讀取最新Service數據,從新生成/etc/nginx/conf.d/default.conf;
5.3 /etc/nginx/conf.d/default.conf文件的變更觸發文件變動事件,監聽該事件的腳本調用「nginx -s reload」命令實現Nginx的配置熱更新。
6、Nginx Proxy
nginx-proxy sets up a container running nginx and docker-gen. docker-gen generates reverse proxy configs for nginx and reloads nginx when containers are started and stopped.
See Automated Nginx Reverse Proxy for Docker for why you might want to use this.
Usage
To run it:
$ docker run -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
Then start any containers you want proxied with an env var VIRTUAL_HOST=subdomain.youdomain.com
$ docker run -e VIRTUAL_HOST=foo.bar.com ...
參考連接:
inotify
https://baike.baidu.com/item/inotify/8361039
inotify -- Linux 2.6 內核中的文件系統變化通知機制(2005年)
https://www.ibm.com/developerworks/cn/linux/l-inotifynew/
inotify-tools命令使用講解(安裝及監控例子)
https://www.cnblogs.com/wajika/p/6396748.html
Nginx中文文檔
http://nginx.org/en/docs/http/ngx_http_upstream_module.html
http://tengine.taobao.org/nginx_docs/cn/docs/
http://tengine.taobao.org/nginx_docs/cn/docs/http/ngx_http_core_module.html#server
http://tengine.taobao.org/nginx_docs/cn/docs/http/ngx_http_upstream_module.html
http://tengine.taobao.org/nginx_docs/cn/docs/http/ngx_http_proxy_module.html
http://tengine.taobao.org/nginx_docs/cn/docs/http/ngx_http_index_module.html
http://tengine.taobao.org/nginx_docs/cn/docs/http/ngx_http_access_module.html
http://tengine.taobao.org/nginx_docs/cn/docs/control.html
NginX進程管理-熱更新
https://blog.csdn.net/huzelin1008/article/details/43193991
nginx-proxy
https://github.com/jwilder/nginx-proxy
http://jasonwilder.com/blog/2014/03/25/automated-nginx-reverse-proxy-for-docker/
Kubernetes集羣中的Nginx配置熱更新方案
https://tonybai.com/2016/11/17/nginx-config-hot-reloading-approach-for-kubernetes-cluster/
利用 Nginx 負載均衡實現 Web 服務器更新不影響訪問
https://blog.csdn.net/liyongshun82/article/details/52787115
從nginx熱更新聊一聊Golang中的熱更新(上)
https://blog.csdn.net/qq_15437667/article/details/83513457
nginx多進程模型之配置熱加載
https://blog.csdn.net/brainkick/article/details/7176405
HAProxy文檔
https://cbonte.github.io/haproxy-dconv/1.8/intro.html
HAProxy用法詳解 全網最詳細中文文檔
http://www.ttlsa.com/linux/haproxy-study-tutorial/
https://www.cnblogs.com/puremans/p/6428644.html