Sidekiq Rails 4.2使用活动作业还是工作者？有什么不同

Question

这是我第一次异步处理作业我在我的应用程序中实现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"Worker"
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

Answer 1

简短的回答是他们是一回事.ActiveJob将其称为Job,而Sidekiq将其称为Worker.我决定保持术语不同,以便人们可以区分这两者.

你可以使用任何一个.请注意,ActiveJob不提供对全套Sidekiq选项的访问权限,因此如果要自定义作业选项,可能需要将其设置为Worker.

Answer 2

添加ActiveJob了Rails 4.2 来统一作业API但是要异步运行它需要一个后台处理程序,这就是sidekiq的来源.

Sidekiq已经拥有了它的工作类,但它也实现了新的活动作业类,因此它可以以任何一种方式工作.

但是,有关活动作业的好处是您可以更改后台处理程序而无需更改代码,只要它们都支持您需要的功能(例如:在特定时间处理作业;具有多个优先级队列).

这里有一个rails api指南,其中包含对支持活动作业的处理程序的良好比较,包括每个处理程序支持的功能.如果你懒得查看链接,这是比较表:

|                   | 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      |

Answer 3

我建议坚持使用原生sidekiq以获得更多功能.我偶尔会遇到一些与ActiveJob有关的奇怪的序列化问题.ActiveJob在追求实施统一API的崇高目标的同时,为此正确地限制了许多实现,并为现在的IMO提供了一点好处.就个人而言,我非常渴望在未来的某个时间(可能永远不会发生,你不会只是为了好玩而交换你的应用程序的关键部分),如果我决定,那么可能会付出重写代码的可能价格(如activerecord vs mongodb)交换实现更丰富的功能集.