使用ActiveJob和Sidekiq相比仅使用Sidekiq的优势

Question

我正在阅读一些在线教程，告诉我们如何使用ActiveJob和Sidekiq。但我不知道为什么我们应该这样做。我看到Sidekiq拥有ActiveJob的所有功能。

此外，在Sidekiq文档中：这里

警告：通过ActiveJob进行作业重试，您将失去许多 Sidekiq功能：

1. Web UI可见性（重试选项卡将为空）
2. 您无法使用Sidekiq :: RetrySet API迭代重试。
3. Sidekiq的日志不会包含任何故障或回溯。
4. 错误不会报告给Sidekiq的全局错误处理程序
5. 许多高级Sidekiq功能（例如批处理）将无法与AJ重试一起使用。

那是一个信号，使我认为我们不应该在ActiveJob中使用Sidekiq。我对ActiveJob的理解是否错误？使用ActiveJobs和sidekiq时是否有任何优势？

谢谢

- Trần Kim Dự

---

那个维基页面只是告诉你不要使用ActiveJob的重试功能而已，它并没有告诉你不要使用ActiveJob。 - Sergio Tulentsev

@SergioTulentsev 非常感谢。根据您的评论和Tony Vincent的回答，我可以理解了一张图片。在您的意见中，您更喜欢在SIdekiq之上使用ActiveJob吗？（因为在这种情况下，我们必须接受此解决方案中的某些弱点），例如重试工作。谢谢 - Trần Kim Dự

我使用ActiveJob而不是Sidekiq。 - Sergio Tulentsev

Answer 1

就我而言，ActiveJob 的主要特点是支持 GlobalId。与之相比： Sidekiq:

class SomeJob
  include Sidekiq::Worker
  def perform(record_id)
    record = Record.find(record_id)
    record.do_something
  end
end
SomeJob.perform_async(record.id)

ActiveJob:

class SomeJob < ApplicationJob
  def perform(record)
    record.do_something
  end
end

SomeJob.perform_later(record)

非常方便，而且更加干净！

关于重试 - 是的，这是一个问题，我不知道为什么在ActiveJob中忽视了将底层系统配置参数授予每个任务的功能。目前，可以使用gem activejob-retry作为解决方法：

class SomeJob
  include ActiveJob::Retry.new(strategy: :exponential, limit: 0)
end

这会禁用ActiveJob的重试，而Sidekiq的重试仍然起作用。可以通过 Sidekiq.default_worker_options['retry'] = 2 在配置文件中配置Sidekiq的重试。

更新：

在Sidekiq 6.0中已经修复了重试问题。

- Lev Lukomsky

Answer 2

从rails ActiveJob 指南

主要目的是确保所有Rails应用程序都有一个工作基础设施。然后，我们可以在其上构建框架功能和其他宝石，而不必担心各种作业运行程序（如Delayed Job和Resque）之间的API差异。选择您的排队后端变得更加关注操作，然后您将能够在不必重写作业的情况下在它们之间切换。

基本上，ActiveJob的作用是标准化作业队列的API接口。这将帮助您轻松地从一个作业后端切换到另一个作业后端。

当您使用ActiveJob与Sidekiq时，您可以受益于sidekiq提供的好处，但真正的收获是当您发现另一个队列器最适合您的应用程序时，ActiveJob允许您通过一行代码切换到您选择的作业队列器。

# application.rb
config.active_job.queue_adapter = :sidekiq

- Tony Vincent

---

非常感谢。但是如果我们在Sidekiq上使用ActiveJob，会有一些重试作业的缺点（在Sidekiq文档中提到）。您认为在这种情况下我们应该优先使用ActiveJob（并失去一些其他有用的功能）吗？谢谢。 - Trần Kim Dự

@TrầnKimDự 这完全取决于您自己的决定。问问自己，您真的需要Sidekiq的retry标签吗？您是否需要Sidekiq批处理等功能？如果是，请选择Sidekiq，毕竟Sidekiq是一个维护良好的项目。 - Tony Vincent

如果您正在部署到Heroku，您可以在与应用程序相同的服务器上使用SuckerPunch，但是Sidekiq需要另一个工作进程。 - Tony Vincent

Answer 3

Active Job是在队列技术之上的一个抽象层。

理论上，它允许您编写一个通用接口，无论您下面使用了什么。

听起来很不错，对吧？但实际上，直接使用Sidekiq可能会更好。

• 大多数Ruby/Rails商店都在全力支持Sidekiq。您永远不会将Sidekiq替换为其他排队技术，在极少情况下，如果您这样做，Active Job将不能像您想象的那样节省大量工作。
• Sidekiq和Active Job不太兼容。在旧版本中情况会更糟。除非您使用Rails 6.0.2+和Sidekiq 6.0.4，否则Active Job不会直接支持Sidekiq的重试。如果您运行的是5.1以下的Rails版本，通过Active Job进行重试将根本不起作用，除非您通过Sidekiq中间件重新发明轮子或添加另一个您真正不需要的第三方依赖。
• Active Job增加了很多开销，而这只是在基准测试中捕获的性能开销。更重要的是，还需要理解如何使用Active Job以及Sidekiq的工作方式，这增加了认知负担。即使看起来不像，多层意味着更复杂。
• 您将失去对重试和错误的可见性，因为Active Job具有其自己的重试机制。只有在Active Job进行重试并将异常传递到Sidekiq后，它们才会在Sidekiq中变得可见。
• Lev提到的GlobalId功能？这种魔法会导致更多的调查工作。最好使用显式代码，而不是隐藏行为以节省一行，并误解代码实际正在执行的操作。

- Dennis