120 秒のスリープで、無限ループでスケジュールされたジョブをコーディングしました。スケジュールされたタスクは、わずかなデータを取得するための Web サイトでの ping です。私たちのソリューションよりも cron ジョブを使用する利点/欠点は何ですか?
3 に答える
リモートサイトをポーリングするプログラムを構築すると、これらの問題/利点が提供されます。
- 欠陥 (未処理の例外) とプログラムが失敗し、ポーリングが停止する可能性があります
- プログラムの遅延によりタイム スリップが発生する可能性があります (120 秒を超える遅延)
- 関心の分離 - プログラム ロジックと混合されたポーリングのスケジューリングにより、より多くのコードが作成されます (失敗する可能性が高くなります)。
- DRY - cron 機能が既に存在するのに (再) 構築する理由
- プログラムは、使用されていないときでもメモリに常駐する必要があります (1/120 秒)
Cron は定期的なスケジューリング用に構築されています。ここにいくつかの問題/利点があります。
- Cron は既にビルド済みで動作し、非常に信頼性が高い
- 環境の提供とログ出力には注意が必要です
- 子プログラムは 120 秒ごとに再起動する必要があります
- Cronは他のプログラム/サーバー/依存関係をチェックしません
- Cron はダウンストリームの依存関係を通知/開始しません
- Cron は厳しいスケジューリング制約を提供しません (1 秒未満でもほぼリアルタイムでもありません)。
cron
仕事の利点:
- 実行するタイミングをより簡単に制御できます。実行する分、時間、日などを制御します
- コードの記述とその操作の管理が容易になります。タスクのループとタイミング ロジックを排除し、実行
crontab
してタイミングを変更したり、停止したりします。 - 実行していないときは、システムのメモリを占有していません。
- 何らかの理由で失敗して終了した場合は、適切な時間になると再び起動します
無限ループの利点:
- 必要になるたびに再起動するオーバーヘッドがありません
この特定のケースでは、CPU リアルタイムとメモリに関する賛否両論はおそらくわずかだと思います。しかしcron
、いつ実行するかを制御できることと、管理が容易であることから、無期限に実行されるものにはジョブの方が適しています。
上記の回答に加えて、もう 1 つ注意事項があります。あなたのスケジュールは 120 秒なので、既知の cron 式パーサー (2 分間隔に等しい) のいずれかで実際に指定できるため、幸運です。
たとえば 125 だとすると、どの方言でも指定できません。
45 秒のインターバルが必要だとします。cron 式のいくつかの方言 (例: Quartz) では、秒を指定できます。ここでの注意点は、45 秒間隔を指定することはまだできないということです。
cron 式 0/13 0/7 * * * ( https://crontab.guru/#0/13_0/7_ _ _*) を考えてみましょう。
Crontab Guru は、この表現を「0 から 23 までの 7 時間ごとに、0 から 59 までの 13 分ごと」と説明しています。
https://www.freeformatter.com/cron-expression-generator-quartz.html (Quartz に基づく) を参照して、式「0/45 * */7 ? * *」を検討すると、式の説明与えられたのは、「毎日 00 秒から 45 秒ごと、毎分、午前 0 時から 7 時間ごと」です。
計算された実行シーケンスは次のとおりです (今から):
2019 年 3 月 6 日水曜日 14:00:00 UTC 2019 年 3 月 6 日水曜日 14:00:45 UTC 2019 年 3 月 6 日水曜日 14:01:00 UTC 2019 2019 年 3 月 6 日水曜日 14:02:45 UTC 2019 年 3 月 6 日水曜日 14:03:00 UTC 2019 年 3 月 6 日水曜日 14:03:45 UTC 2019
これは、より大きな/時間の容器/をオーバーフローするたびに、不整脈が発生することを意味します. ちょうどあなたが知っているので ;-)
PS式の7が冗長であることにも注意してください。私たちは毎分リズムを再開しているので、毎時間も意味します。CRON式は楽しいです:-)