Как правильно применить delayed_job для создания повторяющихся событий?

Question

[A_Modestov]

Добрый день, господа. Прошу прощения за, возможно, глупый вопрос, но понимание никак не приходит.
Есть задача: нужно создавать события в календаре, в зависимости от атрибута модели(:repeat) событие может быть ежедневным, еженедельным, ежемесячным, ежегодным. В каждом конкретном случае создается набор событий вперед (на каждый день, месяц, неделю, год). Поскольку создание 365 событий занимает много времени, процесс уводится в фоновый режим(поток). Вот мой метод create:

def create
    @event = current_user.events.create(event_params)

    Thread.new do
      case @event.every
        when 1 
          for i in 1..365
            @event = current_user.events.create(event_params)
            @event.update_attributes( start_at: @event.start_at + i.day )
            @event.update_attributes( end_at: @event.end_at + i.day )
          end
        when 2 
          for i in 1..53
            @event = current_user.events.create(event_params)
            @event.update_attributes( start_at: @event.start_at + i.week )
            @event.update_attributes( end_at: @event.end_at + i.week )
          end
        when 3 
          for i in 1..11
            @event = current_user.events.create(event_params)
            @event.update_attributes( start_at: @event.start_at + i.month )
            @event.update_attributes( end_at: @event.end_at + i.month )
          end
        when 4 
          for i in 1..10
            @event = current_user.events.create(event_params)
            @event.update_attributes( start_at: @event.start_at + i.year )
            @event.update_attributes( end_at: @event.end_at + i.year )
          end
      end
    end
  end

Как переделать сие, применив гем delayed_job? Где правильнее всего хранить всю эту логику? Разумно ли оставить все в методе контроллера? Заранее спасибо за помощь.

Answer 1

[vsuhachev]

Я бы на вашем месте не планировал все события наперед, а планировал ближайшее событие. А после его исполнения планировал следующее и т.п. Сейчас же у вас все жестко забито в коде, например ежедневное событие через год перестанет исполняться, а ежегодное через 10 лет.

Итого вам нужно
1) Хранить где-то запись о том что задача X запланирована с даты Y с периодичностью Z
2) Хранить запись о истории выполнения событий из которой можно узнать когда последний раз выполнялась задача X
3) Фоновая задача по планированию событий, которая будет выполняться например 1 раз в час и будет читать данные из пп.1-2 и создавать следующее приближающееся событие.

Comments

[A_Modestov]

3) Фоновая задача по планированию событий, которая будет выполняться например 1 раз в час и будет читать данные из пп.1-2 и создавать следующее приближающееся событие.

Как можно организовать ежечасно выполняющееся событие?

[vsuhachev]

На разных движках есть разные решения. Гуглите по словам rails + scheduling, reccuring jobs, repeatable jobs и выбирайте. Я пару раз использовал cron или sidekiq и особо больших познаний в этой области не имею

Answer 2

[d'Ivan]

Создай модель

class JobCreateEvents < Struct.new(:event_id, user_id)
  def perform
    user = User.find(user_id)
    event = Event.find(event_id)
    # ...
    # долгая операция
    # ...
  end
end

Затем в контроллере помещаешь операцию по созданию событий в очередь:

Delayed::Job.enqueue JobCreateEvents.new(@event.id, @current_user.id)

Thread.new убираешь.

Логику можно хранить как в модели JobCreateEvents, так и в модели Event.

Comments

[A_Modestov]

Создал модель:

class JobCreateEvents < Struct.new(:event_id, :user_id, :params)
	def perform
	    user = User.find(user_id)
	    event = Event.find(event_id)
      	case event.repeat
	        when 1 
	          for i in 1..365
	            next_event = user.events.create(params)
	            next_event.update_attributes( start_at: event.start_at + i.day )
	            next_event.update_attributes( end_at: event.end_at + i.day )
	          end
	        when 2 
	          for i in 1..53
	            next_event = user.events.create(params)
	            next_event.update_attributes( start_at: event.start_at + i.week )
	            next_event.update_attributes( end_at: event.end_at + i.week )
	          end
	        when 3 
	          for i in 1..11
	            next_event = user.events.create(params)
	            next_event.update_attributes( start_at: event.start_at + i.month )
	            next_event.update_attributes( end_at: event.end_at + i.month )
	          end
	        when 4 
	          for i in 1..10
	            next_event = user.events.create(params)
	            next_event.update_attributes( start_at: event.start_at + i.year )
	            next_event.update_attributes( end_at: event.end_at + i.year )
	          end
      	end
	end
end

Добавил действие в контроллер:

def create
    @event = current_user.events.create(event_params)
    Delayed::Job.enqueue JobCreateEvents.new(@event.id, @current_user.id, event_params)

    if @event.errors.empty?
      redirect_to user_path(current_user)
    else 
      render "new"
    end
  end

В итоге выполняется только первое @event = current_user.events.create(event_params). В чем может быть косяк?

Answer 3

[Алексей П]

Лучше не пользоваться delayed_job. Используйте Resque, sidekiq, active_job

Comments

[d'Ivan]

1. Ответ не приносит никакой пользы автору вопроса.
2. Неаргументированный ответ

Даже сами авторы Resque признают, что DelayedJob хорош для большинства случаев.
https://github.com/blog/542-introducing-resque

I highly recommend DelayedJob to anyone whose site is not 50% background work.

[Алексей П]

Роман Мирр: почему же?
Автор мог не знать о данных гемах. А теперь узнал о них.
Сами авторы говорят, что он подходит для проектов, где нет большой нагрузки на фоновые задачи. От себя добавлю, что delayed_job может выполнить задачи в цикле, друг за другом. Однозначный плюс, что нет зависимости от redis, однозначный минус - нет зависимости от redis. Значит работа delayed _job ограничена GIL.
Собственно, в сайдкик и рескью мы можем прилепить любой воркер, хоть руби, хоть го. И конечно delayed job подтекает.
Ну и немного циферок
https://www.ruby-toolbox.com/categories/Background_Jobs

[Алексей П]

Sidekiq + golang
https://github.com/jrallison/go-workers
dmathieu.com/articles/development/sidekiq-ruby-golang

[d'Ivan]

Алексей П: Перефразировав утверждение авторов Resque, если на сайте нагрузка в фоновой работе не более 50%, то горячо рекомендуется использовать DelayedJob.
Таким образом, DelayedJob отвечает большинству задач. Иначе это стрелять из пушки по воробьям.
То есть приведённые альтернативы DelayedJob имеют место быть только в случае высоконагруженных фоновыми задачами сайтов.

[Алексей П]

Роман Мирр: но мы же не знаем загрузки. Зачем брать менее универсальное решение?

[d'Ivan]

Алексей П: не нужно гадать за автора вопроса. Мы ведь не ездим на грузовиках только потому что порой необходимо перевезти много вещей, а на легковушках.