ruby-on-rails – heroku上的自定义时钟进程

前端之家收集整理的这篇文章主要介绍了ruby-on-rails – heroku上的自定义时钟进程前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我刚刚在一个典型的’nix服务器上继承了Rails项目.决定将它移动到客户端的heroku,由我来完成后台进程.
目前,它使用Whenever来安排每日事件(电子邮件等)并在启动时启动延迟的作业队列.

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

Scheduled Jobs and Custom Clock Processes in Ruby with Clockwork

解决方法

是的 – Heroku的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就会愉快地运行它.如果您使用时钟进程(例如每当24×7),您将使用整个dyno(每小时0.05美元)除了安排工作之外什么都不做.

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

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

猜你在找的Ruby相关文章