优雅的重启uwsgi 告别uwsgi reload过程中造成的无法请求、请求延迟等问题

[uwsgi]#使用优雅重启
lazy-apps = true
#监听monitor文件 当monitor文件发生改变是重启uwsgi
touch-chain-reload = /home/monitor
#据说可以用touch-reload=路径 来监听某个路径下是否有文件发生了改动
#个人认为还是监听某个不相干的文件比较好  每次需要重启的时候直接touch这个文件就行了

在uwsgi配置文件中加入上面的命令即可优雅的重启uwsgi了

 

在使用uwsgi+django过程中，接口少的时候看不出什么。当接口多并且请求也很多的时候 uwsgi --reload 这种操作就体现出他的短板了。有一次我在app下新增了个接口执行uwsgi --reload的时候突然发现之前的接口在请求中要么无响应要么等待时间特别的长

于是在网上一堆扒拉终于发现原来uwsgi可以“优雅的重启” 好吧！是我孤陋寡闻了

 

 

---------------------------------------------

以下内容来自网络

原文链接：https://blog.csdn.net/asas043/article/details/102443649

 

 

传统重启弊端：
后台上线功能，以往的做法是当有对代码进行更改，需要将新代码提供给用户时，将uwsgi服务器重新启动以使更改生效，但这个重启过程会将所有uwsgi的worker进程强行kill掉，然后再重新启动这些worker，导致的结果：

worker正在处理的请求无法正常处理完，
重启过程中uwsgi无法正常接收请求，请求报502的错误，特别是由于某些原因重启时间可能很久
从stop uwsgi到start uwsgi需要一定时间，这期间就损害了用户的体验：

在网站上看到服务不可用的错误
在请求处理中用户等待很久
服务重启遇到程序bug，导致重启失败

 

优雅重启过程：
优雅的重启是一门艺术，优雅重启的方式有多种，但经过测试，链式重启是最优选择之一，且实现起来非常方便

链式重启的实现过程是一个接一个工人依次重新加载启动，直到所有工人都重新加载完毕。比如你有五个工人，工人A，工人B，工人C...，当你触发链式重启时：

若工人A此刻正在处理请求，链式重启允许它完成此次请求，工人A开始重新加载最新代码
如果工人A顺利完成加载，此时工人A接收到的请求都由最新代码处理，而其他4个工人则依然运行旧代码
工人A顺利完成加载后，依次由工人B开始重新加载最新代码，重复此操作，直到每个工人都获取新代码。链式重启过程完成
如果前一个工人没有加载成功，那么后一个工人也不会进行重启加载，这就意味着，如果程序有bug，其他工人都不会受到任何影响，依然能正常接收请求，这点非常棒，与传统野蛮重启方式相比有明显优势