6

我有一个依赖于非常“实时”数据的 Web 应用程序 - 所以如果发生变化，它需要每 1 秒更新一次。

我想知道以下解决方案的优缺点是什么。

解决方案 1 - 大量投票

所以每隔 1 秒，我就会向服务器发送一个请求并取回一些数据。获得数据后，我会等待 1 秒钟，然后再进行所有操作。如果状态发生变化，我会检测客户端并采取适当的措施。

解决方案 2 - 大量阻止

所以我开始向服务器发出一个请求，该请求将在 30 秒后超时。服务器通过每秒检查一次来密切关注服务器上的数据。如果服务器注意到数据发生了变化，它会将数据发送回客户端，客户端会采取适当的措施。

设想

本质上，数据的大小相当小，但会根据实时事件以随机间隔发生变化。问题是，Web UI 将在 2,000 个实例的区域内运行某些东西，那么我是每秒有 2,000 个来自 UI 的请求，还是有 2,000 个需要长达 30 秒的长时间运行的请求？

非常感谢您的帮助和建议，特别是如果您处理过类似数量的 AJAX 请求。

4

3 回答 3

2

考虑一个更好的架构。在像nodeJS这样的东西中实现这种消息系统是微不足道的。消息发送将是即时的，您无需在任何一方轮询您的数据。

你不需要重写你的整个系统：数据生产者可以简单地POST更新 nodeJS 服务器而不是将它们写入文件，作为奖励，你甚至不需要在磁盘 IO 上浪费时间。

如果您在不了解任何 nodeJS 的情况下开始，您仍然可以在几个小时内完成，因为您可以直接破解聊天示例。

于 2011-05-07T14:50:31.563 回答
2

这种情况的一种常见解决方案是使用静态 json 文件。服务器端脚本会在数据更改时更新它们，并且它们由快速和轻量级的网络服务器（如 nginx）提供服务。由于文件是静态的且很小 - 网络服务器会以非常快的方式在缓存中正确执行此操作。

于 2011-05-09T01:05:29.757 回答
0

我还不能发表评论，但我同意geocar。仅使用轮询来运行实时或几乎实时的 Web 服务将是一个介于两难之间的解决方案。

您还可以查看网络套接字以允许推送，因为这听起来比每秒更新到 30 秒更好的解决方案。

祝你好运！

于 2011-05-07T14:55:10.537 回答