我正在网上阅读一些教程，告诉我们如何使用 ActiveJob 和 Sidekiq。但我不知道为什么我们应该这样做。我发现 Sidekiq 具有 ActiveJob 的所有功能。
此外，在Sidekiq文档上：这里
警告：通过 ActiveJob 进行作业重试，您会丢失很多 Sidekiq 功能：
- Web UI 可见性（“重试”选项卡将为空）
- 您无法使用 Sidekiq::RetrySet API 进行迭代重试。
- Sidekiq 的日志不会包含任何失败或回溯。
- 错误不会报告给 Sidekiq 的全局错误处理程序
- 许多高级 Sidekiq 功能（例如批量）将无法与 AJ 重试一起使用。
这个信号在某种程度上让我认为我们不应该将 Sidekiq 与 ActiveJob 一起使用。我对 ActiveJob 的理解有误吗？将 ActiveJobs 与 sidekiq 结合使用有什么优势吗？
谢谢
来自 Rails ActiveJob guide
重点是确保所有 Rails 应用程序都有工作 基础设施到位。然后我们就可以拥有框架功能和其他功能 gems 建立在其之上，无需担心 API 各种作业运行程序之间的差异，例如延迟作业和 雷斯克。选择队列后端变得更加可操作 那么关心。您将能够在它们之间切换，而无需 不得不重写你的工作。
ActiveJob 基本上所做的就是标准化作业队列的 API 接口。这将帮助您轻松地从一种工作后端更改为另一种工作后端。
当您将 Sidekiq 与 ActiveJob 结合使用时，您可以从 sidekiq 提供的好处中受益，但真正的问题是，当您发现另一个队列最适合您的应用程序时，ActiveJob 允许您使用单行程序切换到您选择的作业队列
# application.rb
config.active_job.queue_adapter = :sidekiq
对我来说，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)
活动作业：
class SomeJob < ApplicationJob
def perform(record)
record.do_something
end
end
SomeJob.perform_later(record)
方便又干净！
从理论上，它允许您对通用接口进行编程，无论您在底层使用什么。
听起来不错吧？嗯，在实践中，直接使用 Sidekiq 会更好。