1

AppEngine プッシュ キューでは、タスクがオプションで追加された場合、将来の実行のためにタスクをスケジュールTaskOptions.etaMillis(...)できます。longこのメソッドは、によって返されるように、絶対ミリ秒でタスクを実行する時間を指定するパラメーターを想定していますSystem.currentTimeMillis()。

AppEngine がサーバー クロックの同期について保証しないことを考えると、クロックは HOURS 単位でずれることがあります!!! ( 「Google I/O 2010 - Google App Engine を使用したデータ パイプライン」の 0:36:07 を参照)、これはどのように信頼できるのでしょうか?

次の例を考えてみましょう。

  • http リクエストが着信し、クロックがたまたま 30 分進んでいるインスタンスにルーティングされます
  • リクエスト処理中、一部のバッチ処理をバックグラウンド タスクに任せたい
  • 約 10 秒以内に結果をユーザーに報告できるようにしたいと考えています。
  • そのため、次の ETA でタスクをスケジュールしますSystem.currentTimeMillis() + 10,000
  • 30 分のクロック スキューを考えると、この ETA は実際には今から 30 分 10 秒後に相当します。
  • したがって、タスクが現在別のインスタンスによって処理されている場合、30 分以上保留になる可能性があります。
  • 言うまでもなく、ユーザーにとっては、私のサービスが死んでいるかのように見えます。

これは、基礎となる API で何らかの形で防止されていますか? そうでない場合、Task ETA はどのように役立つのでしょうか? これを機能させるには、ETA を絶対時間ではなく相対時間として指定する必要はありませんか?

本当に悲しい部分は、実際にはTaskOptions.countdownMillis(...)相対時間を期待する 関数が呼び出されていることですが、最終的にこの値を処理するソースコードを見ると、同じ非常に信頼性の低いSystem.currentTimeMillis().

さらに悪いことに、ETA またはカウントダウンを指定しない場合、この関数は 0 ではなく現在のシステム時間を使用するだけなので、すぐに実行する予定のタスクでさえ、1 時間以上保留になる可能性があります。

これは重大なバグですか、それとも何か不足していますか?

また、プル キュー内のタスクのリースにも同じことが当てはまりますよね?

4

1 に答える 1

0

カウントダウンを 10,000 ミリ秒に設定すると、タスクは通常約 10 秒で実行されますが、タスクが数分遅れることがあります。これらは、エンド ユーザーが待機していないタスクを対象としています。

すべての処理が完全な可用性を備えた単一のサーバーによって処理される場合、相対時間は機能します。代わりに、多くのサーバーがあり、それぞれが不完全な可用性を備えているため、クロック スキューが通常小さいことがわかっているので、絶対時間でタスクを追加します。

于 2013-09-06T04:51:45.440 に答える