NTP サーバーを使用してコンピュータのシステム クロックを同期できることは知っています。しかし、他のシステムと同期して物事をスケジュールしたいアプリケーションで NTP を使用できますか?
シナリオ: Java アプリケーション (おそらく Mule のような ESB で実行する) を開発していて、それが実行されるマシンの時間を必ずしも制御できるとは限りません。アプリで NTP サーバーを使用して時刻を取得し、その時刻に基づいて実行するタスクをスケジュールできますか?
スケジューラとして Quartz を使用していて、時間の処理におそらく joda-time を使用しているとしましょう (それが役立つ場合)。時間は非常に正確である必要はありません。リモート システムよりもはるかに進んでいないことを確認したいだけです。
ドリフトについてあまり心配していない場合、およびマシンがランダムに時刻を変更するだけではないと仮定すると、NTP サーバーに ping を送信して、IT が考えている時刻を取得し、それをローカル マシンが考えている時刻と比較できます。次に、差分を計算し、最後に現地時間でタスクをスケジュールします。
たとえば、NTP サーバーでは 12:30 と表示されているのに、ローカル マシンでは 12:25 と表示されているとします。そして、タスクを NTP 時間の 13:00 に開始したいとします。
つまり、12:25 - 12:30 = -0:05 です。13:00 + (-0:05) = 12:55 なので、タスクを 12:55 にスケジュールします。
補遺 --
実装の素朴さについて話すことはできません。私はプロトコルに十分に精通していません。
最終的には、どのレベルの実用的な精度が許容できるかということになります。NTP は、システム間の時刻を同期するために使用されます。それが解決する問題の 1 つは、継続的に呼び出されることで、クロック クリープを防ぎます。「NTP Ping, schedule with offset」手法を使用し、たとえば、その未来の時間がおそらく 8 時間後だとすると、クロック クリープが発生する可能性が非常に高くなります。つまり、タスクを " 12:55"、12:55 になると、クロックが (まったく) 同期されておらず、ジョブが仮想的に再同期するように再スケジュールされていないため、元の NTP サーバーからずれている可能性があります。
明らかに、元のスケジュールと実際の実行の間の期間が長ければ長いほど、ドリフトの可能性が高くなります。元の NTP ping がどれほど優れていても、これはアーティファクトです。ドリフトを補うためにこれらのタスクが実行時間に近づいたときに再スケジュールする予定がない場合は、NTP の「合理的な」実装が適している可能性があります。
NTP クライアントを備えた Apache Commons NET ライブラリがあります。System.currentTimeMillis() を使用していると不満を言う人もいますが、これには Windows で解決の問題 (10 ～ 15 ミリ秒) がある (あった?)。System.nanoTime はこれに対処し、それを使用するようにライブラリを簡単に変更して再構築することができます。
それが実装の「素朴さ」をどのように反映しているかについては言えません。しかし、最終的には、2 台のマシンとそのジョブを (仮想的に) 同期させる必要があるかどうかにかかっています。
しかし、他のシステムと同期して物事をスケジュールしたいアプリケーションで NTP を使用できますか?
そのように使われているという話は聞いたことがありません。ただし、Network Time Protocol (RFC 1305) のクライアントを実装することを止めるものは何もありません。完全な NTP 実装はおそらくやり過ぎですが、SNTP モード (RFC 2030) でプロトコルを使用することもできます。
高可用性と妥当な精度が必要な場合は、おそらくローカル NTP サーバーをセットアップして使用することをお勧めします。
Google で検索すると、多数の Java NTP クライアントが存在することがわかります...
私の直感では、NTP がペースを維持するにはハードウェア クロックの調整が必要であることがわかります。したがって、ハードウェアにアクセスできない場合は、それを行うことはできません。
ただし、数秒の精度で十分な場合は、サーバーからサンプル時間を定期的に送信して、システム クロック間のずれを計算し、ジョブのスケジュールされた時間を調整することができます。