明らかに、希望する日付までの遅延をミリ秒数に設定できますが、それが実際にはうまく機能しない場合があり、最大整数値が問題になる可能性があります。Kueがそれを実行できない場合は、クライアント向けアプリが使用するメインデータベース、またはおそらく3番目のストアに、離れすぎている日付固有のジョブを保存できます。このプロセス。
更新:これはばかげた質問です、私は頭の中でいくつかの数学をすばやく行い、ひどく失敗しました、私は推測し、そして尋ねました、私は尋ねる前に正確に計算するべきでした。
明らかに、希望する日付までの遅延をミリ秒数に設定できますが、それが実際にはうまく機能しない場合があり、最大整数値が問題になる可能性があります。Kueがそれを実行できない場合は、クライアント向けアプリが使用するメインデータベース、またはおそらく3番目のストアに、離れすぎている日付固有のジョブを保存できます。このプロセス。
更新:これはばかげた質問です、私は頭の中でいくつかの数学をすばやく行い、ひどく失敗しました、私は推測し、そして尋ねました、私は尋ねる前に正確に計算するべきでした。
残念ながら、Kueには他に仕事をスケジュールする方法がありません。整数をオーバーフローさせるまで、どのジョブをスケジュールする必要があるのだろうか。KueがRedisに支えられていることを考えると、私はおそらく、何年も先の仕事をスケジュールするためにKueに頼りたくないでしょう。
本当にそれをしなければならない場合は、実行日をジョブと一緒に保存し、遅延を可能な限り高く設定することができます。実行するときが来たら、その日付が経過したかどうかを確認し、経過していない場合は、残りのミリ秒でジョブを再キューイングします。残りのミリ秒がまだ高すぎる場合は、最大で再キューイングします。
JavaScriptの最大整数のサイズのため、私はそれについて心配しません。
ドキュメントには、日付は現在に関連していると記載されているため、ジョブを最大285、427。017年(9、007、199、254、740、992ミリ秒)先に開始するようにスケジュールできます。日付を絶対日付に変換する可能性が高いとはいえ、それよりも小さいが、それでもかなり大きい制限があります:243,090。534年97,671,189,983,570,992ミリ秒)。
時間的には、2038年の32ビット秒のオーバーフローについてもっと検討したいと思います。