Node.js 设计方法。服务器定期从客户端轮询

Question

我正在尝试学习 Node.js 和适当的设计方法。

我已经实现了一个小型 API 服务器（使用 express），它根据使用 API 的客户端请求从多个远程站点获取一组数据。

这个过程可能需要一些时间（几个 fecth / await），所以我希望用户知道他的要求如何。我已经阅读了有关 socket.io / websockets 的信息，但对于这种情况来说，这可能是一种矫枉过正的解决方案。

所以我做的是：

• 对于每个客户端请求，都会生成一个 requestID 并返回给客户端。
• 使用该 ID，客户端可以随时查询 API（通过另一个端点）以了解其请求状态。
• 在客户端页面上使用 setTimeout() 和一些 DOM 操作，我可以每 X 更新和显示当前请求状态，例如投票方法。

虽然解决方案运行良好，即使有多个客户端同时连接，也许有更好的解决方案？有什么我没有考虑的警告吗？

Answer 1

TL;DR 您使用的方法很好，尽管它可能无法很好地扩展。 Websockets 是解决同一问题的不同方法，但同样可能无法很好地扩展。

您已经确定了在网站上进行实时（或接近）更新的基本上仅有的两个选项：

1. 轮询服务器 - 客户端定期请求信息
2. 使用 Websockets - 服务器可以在发生某些事情时将更新推送到客户端

有几件事需要考虑。

1. “实时”更新有多重要？如果用户可以等待几秒钟（或更长时间），则进行轮询。
2. 服务器可以处理什么样的负载？如果负载是一个问题，那么 Websockets 可能是要走的路。

最后一个问题确实是问题的症结所在。如果您希望有几个或几十个客户端使用此功能，那么任何一种解决方案都可以正常工作。

如果您预计有数千个或更多的连接，那么轮询开始成为一个问题，因为现在我们正在讨论对服务器的许多重复请求。当然，如果间隔更长，负载会更低。

据我了解，Websockets 的开销较低，但当您谈论大量客户端时仍然可能是一个问题。同样，大量客户端意味着服务器正在管理大量打开的连接。

大型服务处理此问题的方式是设计它们的应用程序，使其可以分布在许多相同的服务器上，并且您连接的服务器由负载平衡器管理。无论是轮询还是 Websockets 都是如此。