【问题标题】:Put retried sidekiq jobs at the beginning of queue将重试的 sidekiq 作业放在队列的开头
【发布时间】:2020-12-13 13:32:24
【问题描述】:

我有大约 100000 个工作的 sidekiq 队列。有些作业失败了,这没关系,因为它们通常在被 sidekiq 重试时会成功。

但是,来自 RetrySet 的那些作业被添加到我们队列的末尾。很长一段时间后才再次处理作业。

如何将重试的作业放在队列的开头,以便优先处理?

【问题讨论】:

  • 我认为您的具体要求是不可能的。实际上,如果这些作业具有高优先级,您应该将它们推送到单独的队列中。
  • 所有作业具有相同的优先级。只是如果他们失败并被重试,他们应该被优先考虑

标签: ruby sidekiq


【解决方案1】:

我不认为有一个很好的答案,因为如果我记得正确的 Sidekiq 队列使用 Redis 列表,那么就有 FIFO 的期望。重试的作业会在同一个队列中排队,这意味着它们将始终排在最后。

一种不太好且不是我推荐的方法是添加另一个队列并将作业重试发送给它:

# config/sidekiq.yml
---
:queues:
  - default
  - my_worker_retries

设置worker不重试:

class MyWorker
  include Sidekiq::Worker
  sidekiq_options retry: false
end

确保您的工作人员可预见地引发错误,如下所示:

class MyWorker
  include Sidekiq::Worker
  sidekiq_options retry: false

  def perform(arg)
    raise ArgumentError
  end
end

添加一些逻辑来处理该异常,然后通过新创建的队列再次运行此作业:

class MyWorker
  include Sidekiq::Worker
  sidekiq_options retry: false

  def perform(arg)
    begin
      raise ArgumentError
    rescue ArgumentError => error
      MyWorker.set(queue: :my_worker_retries).perform_async(arg)
    end
  end
end

这意味着任何失败并在 my_worker_retries 队列中排队的作业都可能陷入无限循环 - 作业失败,获救,排队,再次失败 - 更糟糕的是,因为你不是利用 Sidekiq 内置的重试队列机制,没有退避算法来确保重试不会以您的 CPU 可以处理的速度触发。

整个东西都很脆弱。

您可以尝试通过传递一个指示此作业已重试多少次的参数来防止这种情况发生,这样您就可以在某个次数后停止:

class MyWorker
  include Sidekiq::Worker
  sidekiq_options retry: false

  MAX_RETRIES = 5

  def perform(arg, retries = 0)
    raise 'Too many retries' if retries >= MAX_RETRIES

    begin
      raise ArgumentError
    rescue ArgumentError => error
      MyWorker.set(queue: :my_worker_retries).perform_async(arg, retries + 1)
    end
  end
end

您可以扩展它以拥有自己的退避算法:

MyWorker.set(queue: :my_worker_retries).perform_in((retries + 1).hours, arg, retries + 1)

这些都不是理想的,但它确实回答了这个问题。我当然希望有比这更好的解决方案。

有一些 Sidekiq 扩展可能会起作用,例如 https://github.com/chartmogul/sidekiq-priority_queue,但我之前没有使用过。

【讨论】:

  • 感谢 anothermh 分享您的方法。我宁愿阻止使用 sidekiq 重试机制。我害怕自己做这件事的讨厌的虫子
猜你喜欢
  • 2013-06-16
  • 1970-01-01
  • 2014-12-03
  • 1970-01-01
  • 2020-08-30
  • 2018-09-27
  • 2013-11-14
  • 2016-03-01
  • 1970-01-01
相关资源
最近更新 更多