我正在开发一个 Web 应用程序,该应用程序将任务提交给主/工作系统,该系统将任务分包给一系列工作实例中的任何一个。工作队列主机作为一个单独的进程(完全在一台单独的机器上)运行,任务通过 HTTP/REST 请求提交给主机。将任务提交到工作队列后,客户端应用程序可以提交另一个 HTTP 请求以获取有关任务的状态信息。
对于我的 Web 应用程序,我希望它提供某种进度条 View ,让用户了解任务处理进度。实现这一点的明显方法是一个 AJAX 进度表小部件,它定期轮询工作队列以了解已提交任务的状态。我的问题是,有没有更好的方法可以在不频繁轮询的情况下完成此任务?
我考虑过让客户端 Web 应用程序打开一个服务器套接字,它可以在该套接字上监听来自工作主机的通知。另一个类似的想法是使用 XMPP 或类似的状态通知协议(protocol)。 (当然,无论哪种方式,主/从系统都需要更新以提供通知,但我拥有相关代码,因此可以自己进行任何必要的更新。)
关于设置这样的通知系统的最佳方式有什么想法吗?所涉及的额外努力是否值得,或者简单的轮询解决方案是否可行?
最佳答案
轮询
客户端不断轮询服务器以获取响应的状态。
优点
- 真正的 RESTful 意味着可缓存和可扩展。
缺点
- 如果您不想过多地轮询您的服务器,那么这不是最好的响应。
持久连接
在响应完成之前,服务器不会关闭与客户端的 HTTP 连接。服务器可以使用 HTTP 多部分通过此连接发送中间状态。
Comet是实现此行为的最著名框架。
优点
- 最佳响应能力,来自服务器的近乎实时的通知。
缺点
- 网络服务器上的连接限制是有限的,保持连接打开的时间过长可能会给您的服务器带来负载,最坏的情况是使服务器面临拒绝服务攻击。
客户端作为服务器
让服务器发布状态更新和对客户端的响应,就好像它是另一个 RESTful 应用程序一样。
优点
- 最重要的是,无论是在服务器端还是在客户端,都不会浪费任何资源来等待响应。
缺点
- 您需要一个完整的 HTTP 服务器和客户端上的 Web 应用程序堆栈
- 默认情况下“根本没有传入连接”的防火墙和路由器会成为阻碍。
请随意编辑以添加您的想法或新方法!
关于ajax - 来自 HTTP/REST 服务的进度通知,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1043883/