服务端当前使用方式
直接通过svc发送SIGINT/SIGKILL信号
直接触发real_run脚本中的相关信号通知
使用简单
每次重启所有进程(包括master)，重启完成为全新的进程
不等待已有请求完成直接结束旧进程，
新进程ready前所有新请求将无法处理，相当于服务down掉一段时间(秒级)–-靠nginx实现fail over
Standard (default/boring) graceful reload (aka SIGHUP)
直接发送SIGHUP信号
master进程本身不重启,等待已有请求处理结束后结束worker
新worker ready前，所有新请求将进入等待队列
使用简单
不会存在不一致状态
基本重置了所有进程状态
等待队列满了之后的新请求将直接报错
新请求可能需要等待较长时间
Workers reloading in lazy-apps mode
write w to The Master FIFO
wait for running workers and then restart each of them.
avoids restarting the whole instance.
和standar方式一样新请求需要进入队列等待
write c to The Master FIFO
已有请求处理完成后reload 一个worker，新worker ready后才重启下一个worker
新请求无需进入等待队列等待，多个worker之中始终有可以接受请求的worker在工作
逐个worker重启降低机器短时负载
只能处理worker代码更新的重启，无法更改uwsgi option配置
需要多个worker配置才能有较好效果
Zerg mode
配置 zerg server 或者 zerg pool(绑定unix socket)
首先spawn 新worker，ready后shutdown 旧worker(具体参见下面的Zerg Dance-自动化这一过程的一种实现)
基本已经算是0停机reload
允许master配置不同的option重启
需要一个额外的进程
相对没那么容易管理
reload时需要拷贝整个uWSGI栈
The Zerg Dance: Pausing instances 通过配置3个Master FIFOs+ uWSGI 高级hooks实现开启新进程，暂停(pause)旧进程
truly zero-downtime reload.
需要使用高级的uWSGI和Unix技术，配置较为复杂
综合考虑，链式重启的方式配置简单，而且在多worker的情况下已经完全能够避免异常1与异常2问题的产生，考虑到实际上更改uWSGI配置的频率非常之低–偶尔需要按照旧有方式有损重启master进程也可以接受，因而采用链式重启实现uWSGI配置的优雅重启即可，实际只需要在原.xml配置文件中加上 (对应.ini文件、命令行参数加上master-fifo也一样) ，表示通过/tmp/uwsgi_api.fifo 管道传输命令，需要重启时执行 echo c > /tmp/uwsgi_api.fifo 即可。
旧配置：
新配置：
PS: 在网上搜索到已经有人分享过 uWSGI平滑重启的方式，多篇文章来源看上去都是同一篇–uwsgi graceful reload，所采用的也是链式重启，都是通过配置 在.ini配置文件中添加：touch-chain-reload=XXX/settings.py <span class="hljs-attr"> <span>实现，即每次通过touch 某个代码文件的方式实现触发自动重启，后面链式重启逻辑本质都是一样的，只在于我这里是通过管道发送重启命令，而前者是通过监控代码文件状态实现。个人认为通过命名管道方式触发重启更可控一些，这样能将重启操作本身与代码状态这两个本就不应该相关内容的事务隔离开来，而且采用touch方式，任何时候线上只要一发生代码更新--git pull新代码、cp覆盖新代码乃至编辑修改代码（应极力避免）--无论是有意无意，都将触发reload，这不一定是操作者本身想要的，而通过管道方式，则很明确该操作就是需要重启server。</span></span>
Original: https://www.cnblogs.com/AcAc-t/p/uWSGI_graceful_reload.html
Author: 及时
Title: uWSGI服务实现优雅重启(graceful reload)的方式
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/578247/
转载文章受原作者版权保护。转载请注明原作者出处！