由于缺少服务器时钟同步，因此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秒钟左右运行，但有时任务可能会延迟几分钟。 它们用于最终用户不等待的任务。

如果所有处理均由具有完美可用性的单个服务器处理，则相对时间将起作用。 取而代之的是，我们有许多服务器，每台服务器的可用性都不完美，因此，我们知道时钟偏斜通常很小，因此添加了具有绝对时间的任务。