heroku上的自定义时钟进程

时间:2012-09-07 21:41:24

标签: ruby-on-rails heroku whenever

我刚刚在一个典型的'nix服务器上继承了Rails项目。决定将它移动到客户端的heroku,由我来完成后台进程。 目前,它使用Whenever来安排每日事件(电子邮件等)并在启动时启动延迟的作业队列。

Heroku提供了一个使用发条的自定义时钟进程文档的示例,我可以通过这个示例随时使用吗?我可能遇到的任何陷阱?我是否需要创建一个单独的工作人员dyno?

Scheduled Jobs and Custom Clock Processes in Ruby with Clockwork

2 个答案:

答案 0 :(得分:9)

是的 - Heroku的Cedar堆栈让你可以运行任何你想要的东西。

Cedar堆栈的基本构建块是dyno。每个dyno都会获得应用程序的短暂副本,512 MB的RAM以及一堆共享的CPU时间。 Web dynos应该将HTTP服务器绑定到$PORT环境变量中指定的端口,因为这是Heroku将发送HTTP请求的地方,但除此之外,web dynos与其他类型的dynos相同。

您的应用程序告诉Heroku如何通过在Procfile中定义它们来运行其各种组件。 (参见Declaring and Scaling Process Types with Procfile。)时钟流程文章演示了一种模式,您可以使用工作(即非Web)dyno根据任意条件将工作排入队列。再一次,你可以在这里做任何你想做的事 - 只需在Procfile中定义它,Heroku将很乐意运行它。如果你使用时钟进程(例如24x7 whenever),你将使用整个dyno(每小时0.05美元)除了安排工作之外什么都不做。

在你的情况下,我会考虑从Whenever切换到Heroku Scheduler。调度程序基本上是一个Heroku运行的cron,其中crontab条目是“旋转dyno并运行此命令”。对于额外的dynos,你仍然需要支付0.05美元/小时,但与时钟+工作人员设置不同,你只需支付他们实际花费的时间。它将周期性任务与稳态网络+工作人员流量完全分开,而且通常也便宜得多。

唯一警告的另一个词是在分布式系统中运行定期任务很复杂,并且具有复杂的故障模式。一些平台事件(对应于大的EC2中断)导致了两个同步时钟进程和重复的调度程序运行。如果你正在做一些需要连续运行的事情(比如每天给人们发送一次电子邮件),可以考虑用RDBMS锁定来保护它,并仔细检查它实际上是你日常工作后大约23个小时。

答案 1 :(得分:1)

Heroku Scheduler对于生产使用来说通常是一个糟糕的选择,因为它是unreliable并且有时会跳过运行它的任务。

好消息是,如果您使用Sidekiq运行作业队列dyno,则会为其安排插件,例如sidekiq-cron。有了它,您可以使用相同的dyno进行调度。如果您还没有作业工作者,则需要将其设置为仅用于计划,如果您需要可靠地运行它。

P.S。如果您碰巧运行Delayed::Job进行排队的工作,那么也会为其安排插件,例如this one