这是延迟作业、Rails 和 Mandrill 的预期行为吗？

Question

与this question相关，它解释了控制器中逻辑的起源，我有一个关于延迟作业的后台作业的问题，然后再将其推送到github并重新部署。

模型和范围有效，控制器中的逻辑有效，电子邮件 text.erb 文件中的条件有效，用户既可以是读者也可以是订阅者，并且可以设置他们的电子邮件-“我的帐户”页面上的邮件首选项：[文章和更新、仅文章、无电子邮件等]。延迟作业在后台设置和处理，使前端一如既往的好和快，Mandrill SMTP 正确接收所有内容并快速发送电子邮件。

article_controller 中的主要逻辑块这样做是为了将正确的电子邮件发送给正确的用户：

if @article.update(article_params) && @article.status == 'published' && @article.created_at.today?
    User.wantsarticles.editor.each do |user|
      ArticleMailer.delay.send_article_full(@article, user)
    end
    User.wantsarticles.subscribers.each do |user|
      ArticleMailer.delay.send_article_full(@article, user)
    end
    User.wantsarticles.readers.each do |user|
      ArticleMailer.delay.send_article_teaser(@article, user)
    end
    format.html { redirect_to :action => 'admin', notice: 'Article was successfully updated.' }
    format.json { render :show, status: :ok, location: @article }
    else
      format.html { redirect_to :action => 'admin', notice: 'Article was successfully updated.' }
      format.json { render :show, status: :ok, location: @article }
    end

查看 Rails 和延迟的作业日志，但是，只有少数用户 (5-10) 的测试集，当它循环通过逻辑并决定需要发送三封电子邮件时，Rails 正在做三个 INSERT INTO DJ 表，然后 DJ 为每个表执行此操作：

Job NewsitemMailer.send_article_full (id=21) RUNNING
Job NewsitemMailer.send_article_full (id=21) COMPLETED after 0.8950

然后当它完成后，它会报告：

3 jobs processed at 0.9039 j/s, 0 failed

在 Mandrill 日志中，发送的每封电子邮件都有自己的 API“成功/失败”条目。

那么：这是延迟作业的正确/预期行为吗？是否应该为每封电子邮件创建一个工作？或者以不同的方式处理它们？当我们开始做 X 千而不是 10/3 时，这种做事方式会破坏服务器吗？

Answer 1

这看起来像delayed_job 的默认行为。您有 ArticleMailer.delay 呼叫 3 次，它会将它们全部排队，因此您会看到 3 jobs processed。

我想，你也应该看看delayed_job 的handle_asynchronously 功能。

另外，如果您打算处理大量电子邮件，我建议您探索其他选项，例如 Resque 或 sidekiq 或 beanstalkd

在处理大量工作时，它们比 delayed_job 更好。 delayed_job 简单且易于设置，但可能会面临大规模的性能问题。

请参阅this 以获取概览。