Heroku 如何在复杂作业中处理状态为resque的SIGTERM

我一直在Heroku上使用resque，它会不时用SIGTERM打断你的工作

到目前为止，我已经用一个简单的方法处理了这个问题：

def process(options)
  do_the_job
rescue Resque::TermException
  self.defer options
end

我们已经开始使用resque status，这样我们就可以跟踪作业，但是上面的方法显然打破了这一点，因为当作业实际被推迟到另一个作业时，它将显示已完成

我目前的想法是，不必在resque中延迟当前作业，而是需要另一个作业来重新排列由于SIGTERM而失败的作业

诀窍在于有些工作更复杂：

def process(options)
  do_part1 unless options['part1_finished']
  options['part1_finished']
  do_part2
rescue Resque::TermException
  self.defer options
end

---

当重复执行do_part1时，简单地删除rescue并重试这些作业将导致异常。

更深入地了解resque status是如何工作的，一种可能的解决方法是直接使用resque status将使用的相同参数重新执行重新队列

def process
  do_part1 unless options['part1_finished']
  options['part1_finished']
  do_part2
rescue Resque::TermException
  Resque.enqueue self.class, uuid, options
  raise DeferredToNewJob
end

当然，这是未记录的，因此可能与resque status的未来版本不兼容

有一个后退：在该作业失败和新作业恢复之间，第一个作业的状态将由resque status报告。 这就是我重新引发新异常的原因-否则，在新员工拿起旧作业之前，作业状态将显示为已完成，这可能会混淆正在监视和等待作业完成的流程

通过引发一个新的异常DeferredToNewJob，作业状态将临时显示失败，这在前端更容易处理，并且可以自动从resque失败队列中清除特定的异常

更新

resque status为故障处理程序提供

支持。如果将具有此名称的方法定义为类上的实例方法，我们可以使其更简单

这是我对失败的看法

def on_failure(e)
  if e.is_a? DeferredToNewJob
    tick('Waiting for new job')
  else
    raise e
  end
end

有了它，作业基本上不会花时间在失败状态下，让进程监视它的状态。
此外，如果resque status找到此处理程序，则它不会将异常引发到resque，因此不会将其添加到失败队列中