Question

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

模型和范围有效，控制器中的逻辑工作，电子邮件 text.erb 文件中的条件有效，用户是读者或订阅者，可以设置他们的e - “我的帐户”页面上的邮件首选项：[文章＆amp;更新，只是文章，没有电子邮件等]。设置延迟作业并在后台处理所有作业，使前端始终保持良好和快速，并且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进入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千而不是十/三时，这种做事会破坏服务器吗？

Answer 1

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

我认为，您还应该查看3 jobs processed的{{1}}功能。

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

在处理大量工作时，它们优于handle_asynchronously。 delayed_job简单易用，但可能会出现规模问题。

请参阅this以获取概述。

这是Delayed Job，Rails和Mandrill的预期行为吗？

1 个答案: