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平衡選項沒有實際用途。

因此，無需關心代碼中的阻塞事件循環。

您至少應該始終在乎這一點。 您的代碼中可能有一些需要定期運行的內容。 如果你阻止，他們將無法運行。

通常，如果您確實在阻塞，那么您的應用程序中可能存在一些損壞或設計不佳的問題。 （當然，如果您出於某種特殊原因打算這樣做，則阻止沒有問題。這些原因很少見。）