Sidekiq Rails 4.2使用活动作业还是工作者？ 有什么不同
这是我第一次异步处理作业我正在我的应用程序中实现Sidekiq进行后台处理。 我会用它来提醒电子邮件和应用内通知。 我很困惑我是否应该使用Active Job创建一个发送电子邮件或Sidekiq Worker来发送电子邮件的工作。 他们似乎做同样的事情，Rails 4.2 Active Job似乎很新……它是否取代了对Sidekiq工作者的需求？
以下是使用Active Job作业和Sidekiq Worker发送邮件代码的相同内容。 我正在使用Whenever gem进行调度。
my_mailers.rb
class MyMailers < ActionMailer::Base def some_mailer(r.user_id) @user = User.find(r.user_id) mailer_name = "ROUNDUP" @email = @user.email @subject ="subject text" mail(to: @email, subject: @subject, template_path: '/notifer_mailers', template_name: 'hourly_roundup.html', ) end end 使用Sidekiq“工人”
some_worker.rb
class SomeWorker include Sidekiq::Worker def perform() @user = User.all @reminders = @user.reminders.select(:user_id).uniq.newmade @reminders.each do |r| MyMailers.some_mailer(r.user_id).deliver_later end end end
使用活动作业“工作”
some_job.rb
class SomeJob < ActiveJob::Base queue_as :mailer def perform() @user = User.all @reminders = @user.reminders.select(:user_id).uniq.newmade @reminders.each do |r| MyMailers.some_mailer(r.user_id).deliver_later end end end
我的Whenever调度程序schedule.rb中的两个示例
require File.expand_path(File.dirname(__FILE__) + "/../config/environment") set :path, Rails.root set :output, Rails.root.join('log', 'cron.log') #using a worker every 1.day, :at => '4:30 am' do runner SomeWorker.perform_async end #using a job every 1.day, :at => '4:30 am' do runner SomeJob.perform_async end
简短的回答是他们是一回事。 ActiveJob将其称为Job，而Sidekiq将其称为Worker。 我决定保持术语不同，以便人们可以区分这两者。
你可以使用任何一个。 请注意，ActiveJob不提供对全套Sidekiq选项的访问权限，因此如果要为作业自定义选项，可能需要将其设置为Worker。
Rails 4.2添加了ActiveJob来统一作业API但是要异步运行它需要一个后台处理程序，这就是sidekiq的来源。
Sidekiq已经拥有了它的工作类，但它也实现了新的活动作业类，因此它可以以任何方式工作。
但是，有关活动作业的好处是您可以更改后台处理程序而无需更改代码，前提是它们都支持您需要的function（例如：在特定时间处理作业;具有多个优先级队列）。
这里有一个rails api指南 ，包含支持活动作业的处理程序的良好比较，包括每个处理程序支持的function。 如果你懒得检查链接，这是比较表：
| | Async | Queues | Delayed | Priorities | Timeout | Retries | |-------------------|-------|--------|-----------|------------|---------|---------| | Backburner | Yes | Yes | Yes | Yes | Job | Global | | Delayed Job | Yes | Yes | Yes | Job | Global | Global | | Qu | Yes | Yes | No | No | No | Global | | Que | Yes | Yes | Yes | Job | No | Job | | queue_classic | Yes | Yes | No* | No | No | No | | Resque | Yes | Yes | Yes (Gem) | Queue | Global | Yes | | Sidekiq | Yes | Yes | Yes | Queue | No | Job | | Sneakers | Yes | Yes | No | Queue | Queue | No | | Sucker Punch | Yes | Yes | No | No | No | No | | Active Job Inline | No | Yes | N/A | N/A | N/A | N/A | | Active Job | Yes | Yes | Yes | No | No | No |
我建议坚持使用原生sidekiq以获得更多function。 我偶尔会遇到一些与ActiveJob有关的奇怪的序列化问题。 ActiveJob在追求实施统一API的崇高目标的同时，为此正确地限制了许多实现，并为现在的IMO提供了一点好处。 就我个人而言，我非常渴望在未来的某个时间（可能永远不会发生，你不会只是为了好玩而交换你的应用程序的关键部分），如果我决定，那么可能会付出重写代码的可能价格（如activerecord vs mongodb）交换实现更丰富的function集。