【问题标题】:How to correctly use Resque workers?如何正确使用 Resque 工作者?
【发布时间】:2015-08-19 00:50:01
【问题描述】:

我在 Rails 应用程序中有以下任务要做:

  • 下载视频
  • 在给定持续时间(例如:00:02 - 00:09)之间使用 FFMPEG 修剪视频
  • 将视频转换为给定格式
  • 将转换后的视频移至文件夹

因为我想在后台作业中实现这一点,所以我使用了 1 个处理队列的 resque worker。

对于第一份工作,我创建了一个这样的队列 @queue = :download_video 完成了它的任务,在任务结束时,我将通过调用 Resque.enqueue(ConvertVideo, name, itemId) 继续下一个任务。通过这种方式,我创建了一个队列链,当一个任务完成时进入队列。

这是非常错误的,因为如果第一个作业开始将其他作业排入队列(一个从另一个作业),那么所有工作都会被 1 个工作人员阻塞,直到第一个排队作业列表完成。

这应该如何优化?我尝试将更多的工人添加到这种排队工作的方式中,但结果是错误的且不可预测的。

另一方面是每个作业都在数据库中保存一个状态,我需要以正确的顺序处理作业。

每个工人是否应该从上面做一项工作并且至少有 4 名工人?如果我将数量翻倍到 8 名工人,会不会有所改善?

【问题讨论】:

    标签: ruby-on-rails background-process resque


    【解决方案1】:

    您考虑过使用sidekiq 吗?

    如 Sidekiq 文档中所述:

    resque 使用 redis 进行存储,在单线程进程中处理消息。与delayed_job相比,redis的要求使其设置起来有点困难,但redis作为队列比SQL数据库要好得多。单线程意味着并行处理 20 个作业需要 20 个进程,这可能会占用大量内存。

    sidekiq 使用 redis 进行存储,并在多线程进程中处理作业。它与 resque 一样容易设置,但在原始处理速度方面更有效。您的工作代码确实需要是线程安全的。

    所以你应该有两种工作:下载视频和转换视频,任何下载视频工作都应该并行完成(如果你愿意,你可以限制)然后每个都存储在一个队列中(“中间队列") 在被多个并行转换作业转换之前。

    希望对您有所帮助,此链接很好地解释了 Sidekiq 中的最佳实践:https://github.com/mperham/sidekiq/wiki/Best-Practices

    【讨论】:

      【解决方案2】:

      正如@Ghislaindj 所说,Sidekiq 可能是一种替代方案——主要是因为它提供了控制执行顺序的插件。

      查看此列表:

      https://github.com/mperham/sidekiq/wiki/Related-Projects#execution-ordering

      不过,是的,您应该使用不同的队列和更多特定于队列的工作人员。因此,您有一组工作人员都在 :download_video 队列上工作,然后您的其他工作人员连接到 :convert_video 队列等。

      如果您想继续使用 Resque,另一种方法是使用延迟执行,因此当您将后续作业排入队列时,您需要指定延迟参数。

      Resque.enqueue_in(10.seconds, ConvertVideo, name, itemId)

      在 Resque 中使用延迟执行的缺点是它需要 resque-scheduler 包,因此您要引入一个新的依赖项:

      https://github.com/resque/resque-scheduler

      为了比较,Sidekiq 已延迟执行本机可用。

      【讨论】:

        【解决方案3】:

        您是否考虑过将所有四项任务合并为一项?在这种情况下,您可以拥有任意数量的工人,一个人就可以完成这项工作。它将非常可预测地工作,您甚至可以知道完成任务需要多少时间。当其中一个子任务比所有其他子任务花费的时间更长并且它堆积在队列中时,您也不会遇到问题。

        【讨论】:

          猜你喜欢
          • 2021-04-26
          • 2012-07-09
          • 2019-03-19
          • 2010-12-16
          • 2012-01-25
          • 1970-01-01
          • 2016-06-25
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多