这是我第一次异步处理作业我在我的应用程序中实现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&#34;工作人员&#34;
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
使用活动作业&#34;作业&#34;
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
答案 0 :(得分:51)
简短回答是他们是一回事。 ActiveJob将其称为Job,而Sidekiq将其称为Worker。我决定保持术语不同,以便人们可以区分这两个术语。
您可以使用其中任何一个。请注意,ActiveJob不提供对全套Sidekiq选项的访问权限,因此如果您想自定义作业选项,则可能需要将其设置为Worker。
答案 1 :(得分:20)
Rails 4.2添加了ActiveJob
来统一作业API,但是要异步运行它,你需要一个后台处理程序,这就是sidekiq的来源。
Sidekiq已经拥有了其工作类,但它也实现了新的活动作业类,因此它可以以任何方式工作。
然而,关于活动作业的好处是你可以在不需要更改代码的情况下更改后台处理程序,只要它们都支持你想要的功能(例如:在特定时间处理作业;具有多个优先级队列)
有一个rails api guide here包含支持活动作业的处理程序的良好比较,包括每个处理程序支持的功能。如果你懒得查看链接,这是比较表:
| | 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 |
答案 2 :(得分:6)
我建议坚持使用原生sidekiq以获得更多功能。我偶尔会遇到一些与ActiveJob有关的奇怪的序列化问题。 ActiveJob在追求实施统一API的崇高目标的同时,为此正确地限制了许多实现,并为现在的IMO提供了一点好处。就个人而言,我非常渴望支付将来某个时间重写代码的可能的价格(可能永远不会发生,你不会交换应用程序的关键部分)如果我决定将实现交换为更丰富的功能集,那就好玩 - 就像activerecord vs mongodb一样。