面向用户工作的后台流程?

时间:2012-03-21 00:02:38

标签: ruby-on-rails ruby delayed-job background-process resque

我正在建立的网站上的用户可以通过在框中输入并按回车来请求各种社交网络上的用户名的可用性(请参阅this website for an example)。当用户提交要检查的名称时,我必须同时从许多不同的第三方服务请求可用性。每个可用性检查都需要HTTP请求。这意味着来自用户的一个请求可以在后端触发许多HTTP请求。

现在我希望尽快将结果反馈给用户。因此,我想分别执行每个后端可用性检查,并以从第三方获取结果的速度返回结果。我还想使用后台工作进程来保持从我的服务器上发出所有这些HTTP请求的负担。

这是后台工作人员的可行用法,还是仅用于用户不等待结果的情况(例如发送电子邮件)?

这是构建此应用程序的最佳方式吗?

1 个答案:

答案 0 :(得分:2)

对我来说,这似乎是WebSocketsreactor framework组合的完美用例,例如EventMachine或node.js。

为什么选择WebSockets?

对于请求部分,这并不重要。但是,各种外部服务将以各种延迟响应,这意味着为了尽快向用户提供结果,您可能必须为每个服务启动长轮询请求(这通常会阻止进程)处理这些请求),或者使用一系列长轮询请求来获取响应。每个HTTP请求都有一些建立连接所需的开销,并且你要在HTTP头中传输比在回应本身。

另一方面,WebSocket连接建立一次,从那时起它就像一种可用于传输消息的双向管道。这些消息可以是各种服务的响应,一旦到达就会流式传输到客户端。这样可以节省大量开销,并尽快获得对用户的响应。

为什么是反应堆框架?

如果您使用后台作业来处理响应,则可能的工作进程少于请求数。这意味着一些请求必须等到工作人员准备就绪,因此如果所有请求都是并行完成的,那么用户将获得比他能得到的响应更晚的响应。异步I / O可以并行发出所有这些请求,并在用户进入时将结果返回给用户。

如果您使用后台作业队列,则还需要将结果保存在某种数据存储中,以便您的Web服务器可以轮询它以了解特定请求何时完成。服务器端轮询也会增加用户接收数据的延迟。

总结:使用reactor框架+ WebSockets不仅可以使用户体验更好,而且实现起来也更简单。查看socket.io库中的node.js:它应该能够在十几行代码中实现您的用例。