Используем Resque в Rails

Маленькое дополнение из собственного опыта. Если ставить задачу в resque в методах типа after_create, то можно столкнуться с тем что задача начнет выполняться раньше чем произойдет коммит в БД (вот такой он офигительно быстрый этот resque) и тогда объект еще не будет доступен для других соединений к БД, в том числе и для самого resque. В этом случае лучше использовать методы серии after_commit…

Я правильно понял что это аналог Celery в python?

Статья как раз вовремя, только что собрался прикручивать Delayed Job из-за поддержки расписаний по-умолчанию. Но раз существует resque_scheduler, тем более появился такой хороший мануал, то естественно выбираем Rescue :)
Автор, спасибо :)

А вот есть интересная штуковина от большого специалиста по «асинхронным рельсам»:
github.com/mperham/sidekiq
Это то же самое, но жрет памяти меньше т.к. не process per job, а thread per job.

DelayedJob перестал развиваться? оО Последний коммит 3 дня назад. github.com/collectiveidea/delayed_job Вкуснях в нем, конечно, поменьше, чем в Resque, но для большинства задач он вполне годится. И Redis не нужен, опять же.

А я юзаю DJ и крутой гем clockwork. Один раз поднял энвайрмент, и он висит в памяти, по таймеру добавляет задачу в DJ.

Выглядит как-то так:

# config/clock.rb
require_relative './environment'
require 'clockwork'
include Clockwork


every(1.day, 'user.pages.update', at: '12:00'){ User.unblocked.all.each(&:update_pages_info!) }
every(6.hours, 'user.apps.persistence.check'){ Delayed::Job.enqueue UpdateApplicationPersistenceJob.new }
every(1.day, 'pages.refresh_likes_count', at: '23:00'){ Facebook::Page.update_likes_count! }

Defunkt кстати сам писал в описании Resque, что они до этого сидели на DJ и он их полностью устраивал и всем нравился. А Resque они начали писать, когда очереди разрослись слишком неприлично. Суть в том, что пока у тебя нет огромных нагрузок и тысяч очередей, DJ проще и удобнее. Кроме того, в нем офигенный сериалайзер. А Resque работает только с простыми типами.