☰

重启 nginx 后端而不丢失请求

tag-icon • tag-icon nginx uwsgi
重启 nginx 后端而不丢失请求

我确信以前有人用不同的词问过这个问题，但我在 nginx 后面通过 uwsgi（emporer 模式）运行了几个 Django 站点。这都是相当标准的配置，但我发现，如果我重新启动中央 uwsgi 进程，nginx 只会发出 502 错误，而不是等待套接字可用。

我认识到这其中的大部分可能是有原因的，但人们看到 502 错误确实让我很不舒服。这肯定不是我希望客户看到的东西。所以...

  • 我可以请求 nginx 等待/重试后端吗？或者，
  • 除了显而易见的方法之外，我还能做些什么来尽量减少 uwsgi 重启造成的商业损失？

答案1

一个想法是将 nginx 默认的 502 模板替换为自动刷新客户端的页面。本质上，您只需创建一个<meta http-equiv="refresh" content="5">在标题中包含的新文件。为其添加一些友好的文本，解释该网站目前正在进行维护（或一些等效的 BS），并从您的 nginx 配置链接到它：

error_page 502  /502.html;  
location = /502.html {  
    root  /var/www/502.html;  
}

您将需要在所有站点上执行此操作（可能有一种方法可以在全球范围内执行此操作），但结果是任何看到网关超时的人现在都会看到一个看起来并不特别奇怪的页面，并且会在五秒钟内将他们带到他们最初想要的页面。

所有这些都假设后端会恢复。如果有可能无限期地关闭，您可能需要在 JS 中编写一些内容来检查 URL 本身并设置重试计数器。所有这些都相当简单，但它可能会安抚那些因网站关闭而恼火的客户。

答案2

只是一个想法，没有经过测试也不确定是否可能：

如果您在 nginx 中配置多个上游服务器，它们都指向同一个 uWSGI 实例，会怎么样？如果 nginx 无法与 uwsgi 通信，它会将请求发送到下一个上游（proxy_next_upstream 指令在这里有帮助吗？），它实际上是相同的，但可能已经启动。

相关内容