Node.js 中的阻塞事件循环仍然存在问题吗？

Question

我想了很久。

您有 NGINX 负载均衡器，它将 Web 请求分配给特定的 node.js 实例（您可以拥有多个）。 如果其中之一长时间阻塞，则分配给它的 Web 请求正在内部等待运行并被卡住。 这发生在循环负载均衡器上。 但是你可以为 NGINX 选择“least-connections”选项，这意味着 NGINX 会将传入的 web 请求分配给 node.js 实例，它的内部连接数最少，因此 web 请求不会转到 node.js 实例，如果有更多的人在里面等待，它将转到一个，它会快速处理它们并且因为在里面等待的人较少。

因此，无需关心代码中的阻塞事件循环。

我对吗？

Answer 1

但是您可以为 NGINX 选择“最少连接”选项

假设进程 A 连接了一个客户端，进程 B 有 100 个客户端。

进程 A 可以做一些事情来阻止它接受新的连接。 无论如何，Nginx 都会将流量路由到它。 在这种情况下，Nginx 只知道它有 100 个到进程 B 的打开连接，这比进程 A 多。

在这种情况下， least-connections平衡选项没有实际用途。

因此，无需关心代码中的阻塞事件循环。

您至少应该始终在乎这一点。 您的代码中可能有一些需要定期运行的内容。 如果你阻止，他们将无法运行。

通常，如果您确实在阻塞，那么您的应用程序中可能存在一些损坏或设计不佳的问题。 （当然，如果您出于某种特殊原因打算这样做，则阻止没有问题。这些原因很少见。）