Sidekiq Rails 4.2 Use Active Job or Worker? What's the difference

问题

This is my first processing jobs asynchronously I am implementing Sidekiq for background processing in my app. I will use it for reminder emails and in-app notifications. I am confused as to whether I should use Active Job to create a job that sends an email or a Sidekiq Worker to send an email. They seem to do the same thing and Rails 4.2 Active Job seems very new…is it replacing the need for a Sidekiq Worker?

Below is the same sending a mailer code using an Active Job job and a Sidekiq Worker. I am using Whenever gem for scheduling.

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

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

Using an Active Job "Job"
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

Both Examples in my Whenever scheduler 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

回答1:

Short answer is they are the same thing. ActiveJob calls it a Job whereas Sidekiq calls it a Worker. I've decided to keep the terminology different so that people can distinguish the two.

You can use either one. Note that ActiveJob does not provide access to the full set of Sidekiq options so if you want to customize options for your job you might need to make it a Worker.

回答2:

Rails 4.2 added ActiveJob to unify the jobs API but to run it asynchronously you need a background handler, this is where the sidekiq comes from.

Sidekiq already has its worker class but it also implemented the new active job class, so it can work either way.

However, the good thing about active job is that you can change the background handler without the need to change your code, provided they both support the features you want (eg: handling jobs at a certain time; having multiple priority queues).

There's a rails api guide here that contains a good comparison for handlers that support active job, including each handler's supported features. Here's the comparison table if you're too lazy to check the link:

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

回答3:

I would recommend sticking with native sidekiq for more features. I also ran into some weird serialization issues with ActiveJob once in a while. ActiveJob, while pursuing a noble goal of enforcing unified API, limits many implementations precisely for this reason and offers a little benefit for now IMO. Personally, I'm more than eager to pay the possible price of rewriting the code some time in a future(which may never happen, you don't swap critical parts of your application just for fun - like activerecord vs mongodb) if I decide to swap implementation for richer feature-set.