Cron 和delayed_job - 在 Heroku 中同时使用两者
我是否正确地认为，在heroku上每2小时运行一次后台进程（例如发送电子邮件/统计信息收集等）的最有效方法是使用一个cron，每两个小时安排一次，然后将项目粘贴到delayed_jobs队列中（基于 dj gem），然后立即被 Heroku 工作人员拾取？
除此之外，一旦应用程序投入生产，我认为具有成本效益的方法是让 Hirefire 启动一名工人来执行这项工作，然后再将其关闭，这种想法是否正确？
我还应该考虑其他方法吗？我以前没有做过这种延迟的工作 - 在开发和上线之前的基本生产测试中，我都基于 Heroku cron - 但在生产中，如果 cron 作业的负载增加，这似乎不明智。
任何有关有价值的替代方法的指示都表示赞赏！
Am I right in thinking the most efficient way to run a background process every 2 hours on heroku (e.g. sending emails / stats collection etc.) is to use a cron, scheduled for every two hours, that then sticks items in a delayed_jobs queue (based on the dj gem) that is then picked up by a heroku worker instantly?
Further to that, once the app is in production, am I right in thinking the cost-effective approach would be to have hirefire spin up a worker to carry out the job and then shut it down afterwards?
Are there other approaches I should consider? I have not done this kind of delayed job work before - in development and in basic production testing before go live I have it all based on a heroku cron - but in production that doesn't seem sensible if the load on the cron job increases.
Any pointers on worthwhile alternative approaches appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您没有全职工作需要员工做，那么 Hirefire 绝对是您的最佳选择，否则您将支付休眠员工的费用。
计时的另一个选项是使用可用的 :run_at 参数让延迟的作业在完成时重新安排自己。然后，工作人员会在到达时间时执行此操作（尽管我从未测试过这是否可以与 Hirefire 一起使用，因为我认为他们只是查看作业数量）
总体而言，这是一种非常合理的方法，也是我将使用的方法。
Hirefire is definitely the way to go if you don't have a full time set of work for a worker to do as you'll be paying for a dormant worker otherwise.
Another option for the timing is to get the delayed job to reschedule itself when it completes using the :run_at argument that's available. The worker will then do it when it's hit the time (although I've never tested this would work with Hirefire as I think they just look at Job count)
It's a pretty sound approach overall, and what I would use.