8

我想知道在新代码推送后优雅地重新启动 delay_job 消费者的最佳方法是什么？我正在使用 capistrano 推送代码，并且我知道有要重新启动的命令，但是如果当前有作业正在运行，则该命令要么挂起（并且我的部署需要永远），要么它强制退出当前正在运行的作业并且我丢失了数据。

理想情况下，我希望我的部署像这样发生：

  1. 现有的延迟作业使用者正在使用版本 1 代码运行
  2. 我运行cap deploy并将版本 2 代码推送到新服务器
  3. 在部署期间，我们触摸一个文件来告诉delayed_job 在处理完当前作业后重新启动。这可以通过多种不同的方式完成，但我认为这类似于如何优雅地重新启动乘客
  4. 现有的delayed_job 消费者继续使用版本1 代码完成当前作业
  5. 当前作业完成，delayed_job 消费者看到它需要重新启动自己才能继续处理作业
  6. delay_job 消费者自动重启，现在运行版本 2 代码
  7. delay_job 消费者继续处理作业，现在在版本 2 代码上运行

我试图通过检查代码的当前版本在作业运行之前插入一些代码以重新启动，但每次我这样做时，它都会死掉并且实际上并没有重新启动任何东西。下面的示例代码：

def before(job)
  # check to make sure that the version of code here is the right version of code
  live_git_hash = LIVE_REVISION
  local_git_hash = LOCAL_REVISION

  if live_git_hash != local_git_hash
    # get environment to reload in
    environment = Rails.env # production, development, staging

    # restart the delayed job system
    %x("export RAILS_ENV=#{environment} && ./script/delayed_job restart")
  end
end

它检测到它很好，但它在 shell 调用中死掉了。有任何想法吗？

谢谢！

4

1 回答 1

5

想出了一个可行的解决方案。

我有一个基类，我所有的延迟作业都继承自被调用BaseJob：

class BaseJob
  attr_accessor :live_hash

  def before(job)
    # check to make sure that the version of code here is the right version of code
    resp = HTTParty.get("#{Rails.application.config.root_url}/revision")
    self.live_hash = resp.body.strip
  end

  def should_perform()
    return self.live_hash == GIT_REVISION
  end

  def perform()
    if self.should_perform == true
      self.safe_perform()
    end
  end

  def safe_perform()
    # override this method in subclasses
  end

  def success(job)
    if self.should_perform == false
      # log stats here about a failure

      # enqueue a new job of the same kind
      new_job = DelayedJob.new
      new_job.priority = job.priority
      new_job.handler = job.handler
      new_job.queue = job.queue
      new_job.run_at = job.run_at
      new_job.save
      job.delete

      # restart the delayed job system
      %x("export RAILS_ENV=#{Rails.env} && ./script/delayed_job stop")
    else
      # log stats here about a success
    end
  end

end

所有基类都继承自BaseJob并重写safe_perform以实际完成它们的工作。关于上述代码的一些假设：

  • Rails.application.config.root_url指向您的应用程序的根目录（即：www.myapp.com）
  • 有一个公开的路由称为/revision（即：www.myapp.com/revision）
  • 有一个全局常量GIT_REVISION，你的应用知道

我最终做的是将输出git rev-parse HEAD放在一个文件中并用代码推送它。它会在启动时加载，因此它可以在 web 版本以及延迟作业消费者中使用。

当我们通过 Capistrano 部署代码时，我们不再停止、启动或重新启动 delay_job 消费者。我们在每分钟运行的消费者节点上安装一个 cronjob，并确定延迟作业进程是否正在运行。如果没有，那么将产生一个新的。

作为所有这些的结果，满足以下所有条件：

  • 推送代码不再等待delayed_job 重新启动/强制终止。推送新代码时，正在运行的现有作业将被单独保留。
  • 如果消费者正在运行旧代码，我们可以检测作业何时开始。作业重新排队，消费者自杀。
  • 当一个delayed_job 死掉时，一个新的将通过一个带有新代码的cronjob 产生（由于启动delayed_job 的性质，它有新代码）。
  • 如果您对杀死 delay_job 消费者感到偏执，请安装一个 nagios 检查，它与 cron 作业执行相同的操作，但会在 delay_job 进程未运行 5 分钟时提醒您。
于 2013-11-20T05:18:20.823 回答