【问题标题】:background job vs after_save callback后台作业与 after_save 回调
【发布时间】:2010-07-21 17:33:16
【问题描述】:

我有一个名为 Vote 的模型,它会非常频繁地更改(人们对事物进行投票)。我在投票保存后进行其他分析,例如插值选民是男性/女性、年龄等。这会导致更新同一模型中的计数器(成人投票、女性投票等)。

我想知道在保存处理后执行此操作的最佳方法是什么,这应该是后台作业(我使用延迟作业插件)还是最好将其保留为 after_save 回调?从性能的角度来看,哪个更好?

我真的不需要向用户显示第二个最新数据(即使 after_save 回调也无法完成)。

谢谢

【问题讨论】:

  • 我想这将取决于您的分析材料的机制?它是一个分析整个池的过程,以一种比一次一个记录更便宜的方式进行整体分析吗?

标签: ruby-on-rails delayed-job


【解决方案1】:

我的经验法则是,如果完成时间超过一秒(平均),我会将其推送到后台作业,否则我将保持同步。我使用delayed job,效果很好,我没有理由离开它。我有一个案例,我不需要在后台作业中访问数据库,并且我使用了自定义 rake 任务,它非常有效并且让我不必实现后台作业处理器。

【讨论】:

  • 第二种方法还有一点:如果任务对应用程序的使用不重要,或者用户不需要这个更新的信息,立即延迟_job它。例如,更新用户名更改的第三方系统(可能会开具发票)不会影响用户使用您的应用程序的能力,因此请使用 delay_job
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-07-08
  • 1970-01-01
  • 1970-01-01
  • 2018-06-08
  • 2011-11-28
  • 2015-05-16
相关资源
最近更新 更多