我剛剛繼承了一個Rails項目，並且在一個典型的'nix服務器上。我們決定將其轉移到客戶端的heroku，並由我來完成後臺進程。 目前它使用每當安排日常事件（電子郵件等）和引導啓動延遲的作業隊列。heroku上的自定義時鐘進程
Heroku提供了使用發條的自定義時鐘進程的文檔示例，我可以通過本示例隨時隨地使用它嗎？我可能遇到的任何陷阱？我需要創建一個單獨的工人dyno嗎？
Scheduled Jobs and Custom Clock Processes in Ruby with Clockwork
是 - Heroku的雪松堆棧可以讓你運行任何你想要的。
雪松煙囪的基本構件是測功機。每個dyno都會得到應用程序的臨時副本，512 MB的RAM和一堆共享CPU時間。預期Web dynos將HTTP服務器綁定到$PORT環境變量中指定的端口，因爲這是Heroku將發送HTTP請求的地方，但除此之外，Web dynos與其他類型的dynos相同。
您的應用程序告訴Heroku如何通過在Procfile中定義它們來運行其各個組件。 （請參閱Declaring and Scaling Process Types with Procfile。）「時鐘進程」文章演示了一種模式，您可以使用工作人員（即非網絡）dyno根據任意標準排列工作。再次，你可以在這裏做任何你想做的事情 - 只需在Procfile中定義它，Heroku就會高興地運行它。如果您使用時鐘進程（例如24x7 whenever），則您將使用整個測功機（每小時0.05美元）除了計劃工作外什麼都不做。
在你的情況下，我會考慮從每當切換到Heroku Scheduler。調度程序基本上是一個Heroku運行的cron，其中的crontab項是「旋轉一個測功機並運行此命令」。您仍然會爲額外的dynos支付0.05美元/小時，但與時鐘+工作人員設置不同，您只需支付他們實際花費的時間。它將週期性任務與穩定狀態的Web +工作者流量完全分開，而且通常也便宜得多。
另一個警告詞是在分佈式系統中運行週期性任務很複雜並且具有複雜的故障模式。一些平臺事件（對應於大的EC2中斷）導致了諸如2個併發時鐘進程和重複調度器運行之類的事件。如果你正在做一些需要連續運行的事情（比如每天給員工發一封電子郵件），請考慮使用RDBMS鎖定來保護它，並且仔細檢查自己的日常工作實際上已經過了23小時。
Heroku Scheduler對於生產使用來說通常是一個糟糕的選擇，因爲它是unreliable，有時會跳過其任務。
好消息是，如果您運行一個帶Sidekiq的作業隊列測試儀，則會有調度插件。 sidekiq-cron。有了這個，你可以使用相同的動態調度。如果你還沒有工作的工作人員，那麼你需要設置它，只是爲了安排，如果你需要可靠地運行它。
P.S.如果您碰巧運行Delayed::Job作爲排隊作業，那麼也有調度插件。 this one。
是的，我肯定希望將我的任何時間任務切換到調度程序，但我們仍然需要常量後臺進程來運行延遲的作業隊列。現在我唯一的問題是DJ q每天都會在重新啓動時自動執行所有任務，Heroku UTC v在數據庫問題中的EST時間可能......在Heroku上的計時有問題嗎？ – TheIrishGuy
我已經將一些應用程序從假定某個時區的環境移植到Heroku。你可以說'heroku config：設置TZ ='來設置應用程序進程的本地時間，並且說'ALTER USER SET timezone ='通過會話變量改變數據庫時區。 –
willglynn
我只是澄清，我不認爲'每當'是一個'24x7'時鐘過程寶石。它只是一個生成crontabs的工具（我不認爲這是Heroku的工作）。然而，其他的寶石，比如'clockwork'，都是24x7時鐘進程，這對於偶爾的後臺工作來說操作起來會很昂貴。 –