从轨道活动作业guide
主要的一点是确保所有Rails应用程序都有一个合适的作业基础设施。然后我们可以在此基础上构建框架特性和其他gem，而不必担心不同作业运行器之间的API差异，如Delayed Job和Resque。然后，选择队列后端就变成了一个操作问题。您将能够在它们之间切换，而不必重写您的作业。
基本上，ActiveJob所做的就是标准化作业队列的API接口。2这将帮助你轻松地从一个作业后端转换到另一个。
当您将Sidekiq与ActiveJob一起使用时，您可以从Sidekiq提供的好处中获益，但真实的的问题是，当您发现另一个队列最适合您的应用程序时，ActiveJob允许您切换到所选的作业队列，只需一行代码

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

对我来说，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 6.0中修复了重试问题

活动作业是队列技术之上的一个抽象层。
从理论上讲，它允许你编程到一个公共接口，而不管你在下面使用什么。
听起来不错吧？实际上，直接使用Sidekiq会更好。

• 大多数Ruby/Rails商店都在使用Sidekiq。您永远不会用其他队列技术来替换Sidekiq，而且即使您这样做了，Active Job也不会像您想象的那样为您节省那么多工作。
• Sidekiq和ActiveJob不能很好地配合使用。在旧版本中更是如此。除非您使用的是Rails 6.0.2+和Sidekiq 6.0.4，否则Sidekiq重试在ActiveJob中无法立即生效。如果您使用的是Rails 5.1之前的版本，重试成功'除非你用Sidekiq中间件重新发明轮子，或者添加另一个你并不真正需要的第三方依赖项。
• Active Job增加了很多开销，而这只是性能指标评测中捕获的性能开销。更重要的是，除了理解Sidekiq的工作原理之外，还需要理解Active Job的工作原理。层次越多，复杂性就越高，即使看起来并不像。
• 由于Active Job有自己的重试机制，因此您无法看到重试和错误。只有当Active Job重试次数耗尽并将异常冒泡到Sidekiq时，它们才会在Sidekiq中可见。
• Lev提到的GlobalId功能？这种魔力会导致更多的侦探工作。更喜欢显式代码，而不是隐藏行为以保存一行代码，并误解代码实际在做什么。