零停机热重载uwsgi服务需nginx与uwsgi协同：nginx持续转发请求，uwsgi主进程接收sighup后优雅重启worker，保持socket地址不变，全程无中断、无错误。
零停机热重载 uWSGI 服务，本质不是 Nginx 单独完成的，而是 Nginx（反向代理层）与 uWSGI（应用容器层）协同配合的结果。关键在于：Nginx 不中断请求转发，uWSGI 平滑替换工作进程。整个过程对用户完全透明，无连接断开、无 502/503 错误。
核心机制：Nginx + uWSGI 各司其职
Nginx 本身不运行 Python 应用，它只负责接收客户端请求，并通过 UNIX 套接字或 TCP 转发给后端 uWSGI。因此，“热重载”实际发生在 uWSGI 层，而 Nginx 的角色是稳定中转——只要 uWSGI 保持至少一个健康 worker 接收新连接，Nginx 就不会报错。
-
uWSGI 主进程（master）持续监听信号，收到
SIGHUP或--reload指令后，会启动新 worker、等待旧 worker 处理完现存请求再退出，实现优雅重启 - Nginx 无需 reload 配置（除非你改了 upstream 或 socket 路径），它始终连接同一个 uWSGI 套接字地址，对 worker 进程更替完全无感
- 推荐使用
socket = /run/uwsgi.sock（UNIX 域套接字），比 TCP 更高效且避免端口竞争
具体操作步骤（生产推荐）
假设你已配置好 uWSGI（启用 master、processes、cheaper 等）和 Nginx（upstream 指向该 socket），只需以下命令即可完成热重载：
- 发送 HUP 信号给 uWSGI 主进程：
kill -HUP $(cat /run/uwsgi.pid)（需提前用pidfile = /run/uwsgi.pid记录 PID） - 或直接调用 uWSGI 内置重载：
uwsgi --reload /run/uwsgi.pid - 验证：
uwsgi --stats /run/uwsgi.stats查看 worker 状态变化；ss -ltp | grep uwsgi确认 socket 持续监听 - Nginx 侧无需任何操作——连接不断、日志无异常、监控指标平滑过渡
进阶保障：避免单点故障
仅靠单个 uWSGI 实例热重载仍存在极短风险窗口（如新 worker 启动失败）。建议叠加以下设计：
- 在 uWSGI 配置中启用
die-on-term = true和honour-stdin = false，确保信号响应可靠 - 配置
harakiri = 30防止长请求阻塞 worker 退出 - 结合 systemd 管理 uWSGI，使用
Type=notify+Restart=on-failure提供兜底恢复能力 - 若需更高可用性，可部署多实例 uWSGI + Nginx upstream 多节点，再逐台滚动更新
常见误区提醒
很多人误以为“Nginx reload”等于热重载 Python 服务——这是错误的。Nginx nginx -s reload 只校验并加载新配置，若配置未变则无意义；若改了 upstream 地址却没同步 uWSGI，反而会导致 502。真正的热重载对象永远是应用服务器（uWSGI/Gunicorn），Nginx 是它的稳定网关。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
