소개

Advent Calendar 4일째로 기술 정보를 씁니다만, 이번은 Rails에서의 비동기 처리의 백엔드로 사용하는 adapter에 대해서 간단하게 기재합니다. ( Rails의 Active Job 정보 )

비동기 처리 및 어댑터

처리가 무거워지는 경우나 메일 송신을 사용하는 경우 등 비동기 처리를 사용하고 있을까 생각합니다. 일단 처리를 비동기 처리 실행용의 큐에 넣어, 비동기 처리의 결과를 나중에 통지하는 것으로, 액션시의 처리가 가벼워져 최종 유저에게 스트레스를 주지 않게 합니다.
여러분은 delayed_job을 사용한 적이 있습니까? 편리했어요?
지금도 편리한 것은 변하지 않습니다만, 자주 사용되는 adapter(유명한 곳)로서는 sidekiq나 resque라고 하는 선택사항도 있습니다.

adapter의 차이

sidekiq와 resque의 차이점은 아래 기사에 설명되어 있으므로 참조하십시오.
htps : // 코 m / 자루 / ms / 8385f dbd1 25 370


htps : // 기주 b. 이 m / mぺr은 m / 할 수 있습니다.

delayed_job이 sidekiq, resque와 다른 큰 점은 Redis를 사용하지 않는 점입니다. delayed_job은 ActiveRecord를 사용하며 큐 관리를 위한 테이블을 만듭니다.
delayed_job을 사용하는 경우,

장점 · · · Redis를 사용하지 않는 경우 설치가 필요하지 않습니다.

단점・・・Redis가 빠르다. 많은 액세스가 비동기 처리를 많이 사용하는 경우 지연이 발생합니다.

같은 특징이 있습니다. 또한 worker를 늘려도 ActiveRecord 부분에서 테이블 잠금을하므로 병목 현상이 될 수 있습니다.

base.rb

def reserve(worker, max_run_time = Worker.max_run_time)
  # We get up to 5 jobs from the db. In case we cannot get exclusive access to a job we try the next.
  # this leads to a more even distribution of jobs across the worker processes
  find_available(worker.name, worker.read_ahead, max_run_time).detect do |job|
    job.lock_exclusively!(max_run_time, worker.name)
  end
end

def lock_exclusively!(max_run_time, worker)
  now = self.class.db_time_now
  affected_rows = if locked_by != worker
    # We don't own this job so we will update the locked_by name and the locked_at
    self.class.update_all(["locked_at = ?, locked_by = ?", now, worker], ["id = ? and (locked_at is null or locked_at < ?) and (run_at <= ?)", id, (now - max_run_time.to_i), now])
  else
    # We already own this job, this may happen if the job queue crashes.
    # Simply resume and update the locked_at
    self.class.update_all(["locked_at = ?", now], ["id = ? and locked_by = ?", id, worker])
  end
  if affected_rows == 1
    self.locked_at = now
    self.locked_by = worker
    self.locked_at_will_change!
    self.locked_by_will_change!
    return true
  else
    return false
  end
end

소감

Redis를 사용하거나 액세스가 많아지면 sidekiq, resque를 어댑터에 사용하는 느낌일까 생각합니다.
delayed_job을 사용하는 것은 안되는 것은 아니지만, KVS인 Redis를 사용하고 있는 어댑터를 선택하는 것이 좋을까라고 하는 것과, 실행시는 락 하는 처리가 달리므로 다용하는 것은 삼가한 쪽 좋은 것 같아요. 액세스 수가 늘어나거나 규모가 커지면 성능을 의식하고 Redis를 사용할 기회가 늘어난다고 생각하기 때문에 delayed_job을 사용하면 소규모 애플리케이션이 될 것이라고 생각합니다.

보충

비슷한 것이 resque의 README에 쓰는군요. .
Resque VS DelayedJob !!?
htps : // 기주 b. 코 m / 레 s 쿠에 / 레 s 쿠에 # 레 s 쿠에 vs