web-dev-qa-db-fra.com

Sidekiq Rails 4.2 Utiliser un travail actif ou un travailleur? Quelle est la différence

Il s'agit de mes premiers travaux de traitement de manière asynchrone. J'implémente Sidekiq pour le traitement en arrière-plan dans mon application. Je vais l'utiliser pour des e-mails de rappel et des notifications dans l'application. Je ne sais pas si je dois utiliser Active Job pour créer un travail qui envoie un e-mail ou un Sidekiq Worker pour envoyer un e-mail. Ils semblent faire la même chose et Rails 4.2 Le travail actif semble très nouveau… remplace-t-il le besoin d'un Sidekiq Worker?

Vous trouverez ci-dessous la même chose en envoyant un code de messagerie à l'aide d'une tâche Active Job et d'un Sidekiq Worker. J'utilise Whenever gem pour la planification.

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

tilisation d'un "Worker" 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

tilisation d'un travail actif "Travail"
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

Les deux exemples dans mon planificateur Everyever 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
ruby-on-railsasynchronoussidekiqwheneverrails-activejob
29
NothingToSeeHere

En bref, c'est la même chose. ActiveJob l'appelle un Job tandis que Sidekiq l'appelle un Worker. J'ai décidé de garder la terminologie différente afin que les gens puissent distinguer les deux.

Vous pouvez utiliser l'un ou l'autre. Notez qu'ActiveJob ne donne pas accès à l'ensemble complet des options Sidekiq, donc si vous souhaitez personnaliser les options de votre travail, vous devrez peut-être en faire un Worker.

53
Mike Perham

Rails 4.2 a ajouté ActiveJob pour unifier l'API des jobs mais pour l'exécuter de manière asynchrone, vous avez besoin d'un gestionnaire d'arrière-plan, c'est de là que vient le sidekiq.

Sidekiq a déjà sa classe de travailleurs, mais il a également mis en œuvre la nouvelle classe d'emplois active, afin qu'elle puisse fonctionner dans les deux sens.

Cependant, la bonne chose à propos du travail actif est que vous pouvez changer le gestionnaire d'arrière-plan sans avoir besoin de changer votre code, à condition qu'ils prennent tous les deux en charge les fonctionnalités que vous souhaitez (par exemple: gérer les travaux à un certain moment; avoir plusieurs files d'attente prioritaires).

Il y a un guide Rails api ici qui contient une bonne comparaison pour les gestionnaires qui prennent en charge le travail actif, y compris les fonctionnalités prises en charge de chaque gestionnaire. Voici le tableau de comparaison si vous êtes trop paresseux pour vérifier le lien:

|                   | 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      |
21
Mohammad AbuShady

Je recommanderais de rester avec sidekiq natif pour plus de fonctionnalités. J'ai également rencontré de temps en temps des problèmes de sérialisation étranges avec ActiveJob. ActiveJob, tout en poursuivant un noble objectif d'appliquer l'API unifiée, limite précisément de nombreuses implémentations pour cette raison et offre un petit avantage pour le moment à l'OMI. Personnellement, je suis plus que désireux de payer le prix possible de la réécriture du code dans le futur (ce qui peut ne jamais arriver, vous n'échangez pas les parties critiques de votre application juste pour le plaisir - comme activerecord vs mongodb) si je décide d'échanger l'implémentation pour un ensemble de fonctionnalités plus riche.

6
Dr.Strangelove

Selon la documentation, l'utilisation de Sidekiq :: Worker par rapport à ActiveJob peut présenter des avantages en termes de performances.

https://github.com/mperham/sidekiq/wiki/Active-Job#performance

0
Chad M