将 ActiveJob 与 Sidekiq 一起使用与单独使用 Sidekiq 相比的优势

Question

我正在在线阅读一些教程，这些教程告诉我们将 ActiveJob 与 Sidekiq 一起使用。 但我不知道我们为什么要这样做。 我看到 Sidekiq 具有 ActiveJob 的所有功能。

此外，在 Sidekiq 文档上： here

警告：通过 ActiveJob 重试作业，你会失去很多 Sidekiq 功能：

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

这是一个信号，让我觉得我们不应该将 Sidekiq 与 ActiveJob 一起使用。 我对 ActiveJob 的理解有误吗？ 将 ActiveJobs 与 sidekiq 一起使用有什么优势吗？

谢谢

Answer 1

来自 rails ActiveJob指南

重点是确保所有 Rails 应用程序都具有到位的作业基础架构。 然后，我们可以在此基础上构建框架功能和其他 gem，而不必担心各种作业运行程序（例如 Delayed Job 和 Resque）之间的 API 差异。 那么，选择您的排队后端就成为更多的操作问题。 您将能够在它们之间切换，而无需重写您的作业。

基本上，ActiveJob 所做的是标准化作业队列器的 API 接口。 这将帮助您轻松地从一个工作后端更改为另一个工作后端。

当您将 Sidekiq 与 ActiveJob 一起使用时，您可以从 sidekiq 提供的好处中受益，但真正的问题是当您找到另一个最适合您的应用程序的排队器时，ActiveJob 允许您切换到您选择的作业排队器和一个班轮

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

Answer 2

对我来说，ActiveJob 的主要特点是支持 GlobalId。 比较：

赛德克：

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

活动工作：

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.default_worker_options['retry'] = 2

更新

重试问题已在Sidekiq 6.0 中修复 🎉

Answer 3

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

从理论上讲，它允许您对通用接口进行编程，而不管您在下面使用什么。

听起来不错吧？ 嗯，在实践中，直接使用 Sidekiq 会好得多。

• 大多数 Ruby/Rails 商店都在 Sidekiq 上。 您永远不会将 Sidekiq 换成其他一些队列技术，而且万一您这样做了，Active Job 不会像您想象的那样为您节省多少工作。
• Sidekiq 和 Active Job 不能很好地协同工作。 在旧版本中情况更糟。 除非您使用的是 Rails 6.0.2+ 和 Sidekiq 6.0.4，否则 Sidekiq 重试不能与 Active Job 一起使用。 如果您使用的是 5.1 之前的 Rails 版本，则重试将根本无法通过 Active Job 进行，除非您使用 Sidekiq 中间件重新发明轮子或添加另一个您并不真正需要的第三方依赖项。
• Active Job 增加了很多开销，而这只是基准测试中捕获的性能开销。 更重要的是，除了了解 Sidekiq 的工作原理之外，还必须了解 Active Job 的工作原理，这也是认知开销。 更多的层更复杂，即使它看起来不像。
• 您无法看到重试和错误，因为 Active Job 有自己的重试机制。 只有在 Active Job 重试次数用尽并将异常冒泡到 Sidekiq 后，它们才会在 Sidekiq 中可见。
• Lev 提到的 GlobalId 功能？ 这种魔法会导致更多的侦探工作。 更喜欢显式代码，而不是隐藏行为以节省一行并误解代码实际在做什么。