ruby on rails - perform - Sidekiq Rails 4.2 ¿Usar trabajo activo o trabajador? Cual es la diferencia

sidekiq rails 5

Question

Estos son mis primeros trabajos de procesamiento de forma asíncrona. Estoy implementando Sidekiq para el procesamiento en segundo plano en mi aplicación. Lo usaré para correos electrónicos de recordatorio y notificaciones dentro de la aplicación. Estoy confundido en cuanto a si debo usar Trabajo Activo para crear un trabajo que envíe un correo electrónico o un Trabajador de Sidekiq para enviar un correo electrónico. Parecen hacer lo mismo y Rails 4.2 Active Job parece muy nuevo ... ¿está reemplazando la necesidad de un Sidekiq Worker?

A continuación se muestra el mismo envío de un código de correo electrónico mediante un trabajo de trabajo activo y un trabajador de Sidekiq. Estoy utilizando siempre que gema para la programación.

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

Usando un "Trabajador" de 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

Usando un trabajo activo "Trabajo"
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

Ambos ejemplos en mi planificador Cuando sea necesario. 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

La respuesta corta es que son la misma cosa. ActiveJob lo llama trabajo mientras que Sidekiq lo llama trabajador. He decidido mantener la terminología diferente para que las personas puedan distinguir los dos.

Puedes usar cualquiera de los dos. Tenga en cuenta que ActiveJob no proporciona acceso al conjunto completo de opciones de Sidekiq, por lo que si desea personalizar las opciones para su trabajo, es posible que tenga que convertirlo en Trabajador.

Answer 2

Rails 4.2 agregó ActiveJob para unificar la API de trabajos, pero para ejecutarlo de forma asíncrona necesita un controlador de fondo, de ahí es de donde viene el sidekiq.

Sidekiq ya tiene su clase de trabajador, pero también implementó la nueva clase de trabajo activo, por lo que puede funcionar de cualquier manera.

Sin embargo, lo bueno del trabajo activo es que puede cambiar el manejador en segundo plano sin necesidad de cambiar su código, siempre que ambos admitan las funciones que desea (por ejemplo: manejar trabajos en un momento determinado; tener varias colas de prioridad).

Aquí hay una guía de api de rieles que contiene una buena comparación de los controladores que admiten el trabajo activo, incluidas las funciones compatibles de cada controlador. Aquí está la tabla de comparación si eres demasiado perezoso para revisar el enlace:

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

Recomendaría seguir con el sidekiq nativo para más características. También me encontré con algunos problemas de serialización extraños con ActiveJob de vez en cuando. ActiveJob, mientras persigue un noble objetivo de imponer una API unificada, limita muchas implementaciones precisamente por esta razón y ofrece un pequeño beneficio por ahora IMO. Personalmente, estoy más que ansioso por pagar el posible precio de volver a escribir el código en algún momento en el futuro (lo que tal vez nunca ocurra, no intercambiará partes críticas de su aplicación solo por diversión, como activerecord vs mongodb) para cambiar la implementación por un conjunto de características más rico.