在与很多用户打交道时实际使用延迟后台作业

Question

当后台作业启动时，它被发送到工作人员处理队列的后面;一个任务清除，另一个开始。我想我有这个权利，除了在某些情况下我不明白它的实际意义。当然，如果你是一家使用延迟工作每周发送15,000次新闻简报的公司，那就很合理。但是，当你有一个甚至100个用户的应用程序，其中一些任务足够长以便需要后台工作（例如发送/获取可能需要一分钟的电子邮件），那么每个用户将不得不排队等待另一个用户被清除（在案件中有一名工人）。

这是我不确定我是否正确的部分。我正在谈论相同的工作，但单独为每个用户。这算作每个用户的工作吗？如果我有100个用户，我是否需要为每个人的流程保留100名员工，以免被阻止？

我试过使用delayed_job来模拟，实际上当我用不同的帐户登录时，我必须等到另一个用户的电子邮件被发送，直到我的电子邮件被发送。尽管插件工作迅速而简单，但我认为这不是正确的方法。

我也尝试过使用Ajax，但由于它是一个HTTP请求，它在加载模式下绑定浏览器，直到它从服务器获得响应（即使使用async: true）。不知道我是否过快地排除了这一问题，但我正在寻找更优雅的服务器解决方案。

有没有办法实现这样的后台工作？ （我听说过不同的，主要是商业解决方案承诺等待时间很少，但我有兴趣完全消除用户之间的队列）。如果没有，是否有方法可以在不等待响应的情况下发出ajax请求？我意识到我的问题是完全不同的，但两者似乎都是解决这个问题的恰当方法。

Answer 1

Resque是一个后台处理引擎，可以支持多个队列。

方式，你可以这样做：

1. 组的任务分解成队列，关于它们的优先级是有意义的。如果您需要快速响应时间，请在“前台”队列中使用它。慢？（如发送/接收电子邮件）可以在“背景”队列
2. 每位用户设置一个队列（你需要有很多很多工人此）

这太问题也给出了办法use delayed_jobs with multiple queues/tables

Answer 2

delayed_job和其他消息队列的用途是异步处理核心应用程序之外的作业。由于我依赖外部应用程序（有时是第三方API，如Gmail）发送邮件，因此我总是使用队列发送电子邮件，而且我无法保证可用性和运行效率。

因此，对于您的用例，即使用户很少，我也强烈建议将电子邮件卸载至delayed_job。这会加速你的前端（ajax），并且在失败时也会给你重试。您可以让多个工作人员处理队列，但除非您的发送电子邮件花费很长时间（超过几秒？），否则应该不需要您的号码。

是的，在大多数情况下，我会为每个用户创建单独的作业，即使该消息可能是相同的。如果电子邮件应用程序/ API具有批量发送功能，并且您可以通过在几个呼叫中发送大型有效负载来显着减少呼叫数量，那么我只能一起处理它们。