背景
线上主api服务使用的是uWSGI+Django框架，循历史传承一直是通过svc守护进程运行，每次重启无外乎通过svc -k / svc -i 通知server实现重启，本质上就是通过向server发送SIGKILL/SIGINT信号实现结束旧进程，而后守护进程重新拉起新进程运行。
问题
此种重启方式每次都会导致重启时刻一小段时间(数秒--数十秒)线上server的不可用，这直接导致两个异常来源：1，旧进程直接被kill，当前正在处理未完成的请求流程也直接中断；2，旧server被kill掉，新server启动初始化ready前，完全无法处理任何新请求，直接体现为大量的niginx502响应。
针对异常1，由于SIGKILL信号直接杀死进程，所以不可避免，但是对于SIGINT信号，通过增加信号处理函数，理论上可以等server处理完全部未完成请求后再结束自身，但在收到SIGINT信号后，不应该再接收新的请求，此种方式不可能解决异常2的问题。
针对异常2，要解决出现server重启准备期间无法响应新请求的问题，只能提前将打向重启节点的流量先屏蔽掉，server重启ready后再恢复流量，通过提前一定时间屏蔽流量，等待历史请求处理完成后再重启，还可以解决掉异常1的问题。这算是保持多进程服务高可用的一种典型思路，难点在于需要能够自动化这一流程，即：a, nginx屏蔽node流量；b,一定时间后重启node服务；c，重启ready后恢复node流量。对于使用一体化分布式框架，已经打通流量控制、节点重启平台功能的大公司，这个不失为一种选择，但对于小公司来说，自动化难度较大，而如果手动操作则不但繁琐，而且很容易出错，节点增多后更是难以接受的labor work。
uWSGI优雅重启
在网上搜寻有无更好的uWSGI优雅重启方案，找到了uWSGI官方文档：
优雅重载的艺术 — uWSGI 2.0 文档
The Art of Graceful Reloading
其中提到了数种reload的方案，简单总结如下：
| 方法 | 过程 | pros | cons |
|---|---|---|---|
| 服务端当前使用方式 | 直接通过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方式一样新请求需要进入队列等待 |
| Chain reloading (lazy apps) | 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配置文件中加上 /tmp/uwsgi_api.fifo (对应.ini文件、命令行参数加上master-fifo也一样) ，表示通过/tmp/uwsgi_api.fifo 管道传输命令，需要重启时执行 echo c > /tmp/uwsgi_api.fifo 即可。
旧配置：
0.0.0.0:3000
14400
true
4
12
wsgi
true
true
6048
65536
true
30
true
新配置：
0.0.0.0:3000
14400
true
/tmp/uwsgi_api.fifo
4
12
wsgi
true
true
6048
65536
true
30
true
PS: 在网上搜索到已经有人分享过 uWSGI平滑重启的方式，多篇文章来源看上去都是同一篇--uwsgi graceful reload，所采用的也是链式重启，都是通过配置 在.ini配置文件中添加：touch-chain-reload=XXX/settings.py 实现，即每次通过touch 某个代码文件的方式实现触发自动重启，后面链式重启逻辑本质都是一样的，只在于我这里是通过管道发送重启命令，而前者是通过监控代码文件状态实现。个人认为通过命名管道方式触发重启更可控一些，这样能将重启操作本身与代码状态这两个本就不应该相关内容的事务隔离开来，而且采用touch方式，任何时候线上只要一发生代码更新--git pull新代码、cp覆盖新代码乃至编辑修改代码（应极力避免）--无论是有意无意，都将触发reload，这不一定是操作者本身想要的，而通过管道方式，则很明确该操作就是需要重启server。
