由於缺少服務器時鍾同步，因此AppEngine推送隊列中的Task-execution-ETA

Question

如果將AppEngine推送隊列與TaskOptions.etaMillis(...)選項一起添加，則可以將其安排為將來執行。 正如System.currentTimeMillis()返回的那樣，此方法需要一個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是否以某種方式阻止了此操作？ 如果沒有，那么任務ETA到底有什么用？ 能否將ETA指定為相對時間而不是絕對時間才能使它起作用？

令人難過的是，實際上有一個名為TaskOptions.countdownMillis(...)的函數確實期望一個相對時間，但是查看最終處理該值的源代碼 ，人們看到它只是被轉換為絕對時間。基於相同的高度不可靠的System.currentTimeMillis()規范。

更糟糕的是：如果您未指定ETA或倒數計時，則此函數僅使用當前系統時間而不是0，因此，即使您希望立即執行的任務也可能會被擱置一個小時或更長時間！

這是一些重大錯誤還是我錯過了一些東西？

同樣，這同樣適用於“ 拉入隊列”中的“任務”租約，對嗎？

Answer 1

如果將倒計時設置為10,000毫秒，則任務通常會在10秒鍾左右運行，但有時任務可能會延遲幾分鍾。 它們用於最終用戶不等待的任務。

如果所有處理均由具有完美可用性的單個服務器處理，則相對時間將起作用。 取而代之的是，我們有許多服務器，每台服務器的可用性都不完美，因此，我們知道時鍾偏斜通常很小，因此添加了具有絕對時間的任務。