在分布式服务架构中使用System.currentTime？

Question

我有两个服务，服务A和服务B。

我在服务B上调用了一个方法doStuff()，它用当时运行B代码的计算机上的system.CurrentTime()在数据库中创建了一个条目。

我在服务A上调用了一个方法compareThings()，它查询服务B，提取我刚刚添加的条目，并获取时间戳字段，将其称为tsFromB。现在，我想检查一下system.CurrentTime() - tsFromB。

我的问题是，如果计算机时钟差之间的1分钟差很重要，那么运行Service A的计算机上的system.CurrentTime() - tsFromB是不是一个好的选择？这是正确的吗？

Answer 1

由于多种原因，您不能信任单个计算机时钟。

为了回答你在评论部分的问题，我将分享Martin Kleppmann的书中的摘录，设计数据密集型应用程序来自他关于不可靠时钟的部分。

• 计算机中的石英钟不是很准确:它会漂移(运行得比正常的快或慢)。时钟漂移随机器温度的变化而变化。Google假设其服务器的时钟漂移为200ppm(百万分之)，这相当于每30秒与服务器重新同步的时钟的时钟漂移为6毫秒，或每天重新同步的时钟的时钟漂移为17秒。
• 如果计算机的时钟与NTP服务器相差太大，它可能会拒绝同步，或者本地时钟将被强制重置。观察此重置前后时间的任何应用程序都可能会看到时间倒退或突然向前跳转。
• 如果某个节点意外地从NTP服务器上被防火墙隔离，则在一段时间内可能不会注意到配置错误。
• NTP同步只能和网络延迟一样好，所以当你在一个具有可变数据包延迟的拥塞网络上时，它的准确性是有限的。一项实验表明，通过互联网同步时，最小误差为35毫秒，尽管偶尔出现的网络延迟尖峰会导致大约一秒的误差。根据配置的不同，较大的网络延迟可能会导致NTP客户端放弃entirely.
• Some NTP服务器错误或错误配置，从而报告按小时关闭的时间。NTP客户端相当健壮，因为它们查询多个服务器并忽略异常值。然而，把系统的正确性押在陌生人告诉你的internet.
• “Leap秒数结果上的时间上是有点令人担忧的，这是59秒或61秒长的，这会打乱系统中的计时假设，这些系统在设计时并没有考虑到闰秒。许多大型系统崩溃的事实表明，关于时钟的错误假设很容易潜入系统。处理闰秒的最佳方法可能是让NTP服务器“躺着”，“通过在一天中逐渐执行闰秒调整(这称为涂抹)，虽然实际的NTP服务器行为在practice.
• “In虚拟机中有所不同，但硬件时钟是虚拟化的，这给需要精确计时的应用程序带来了额外的挑战。当CPU核心在虚拟机之间共享时，每个虚拟机都会暂停数十毫秒，而另一个虚拟机正在运行。从应用程序的角度来看，这种暂停表现为时钟突然向前跳动。
• “如果您在不完全控制的设备(例如，移动或嵌入式设备)上运行软件，您可能根本不能信任设备的硬件时钟。一些用户故意将他们的硬件时钟设置为不正确的日期和时间，例如为了规避游戏中的时间限制。因此，时钟可能会疯狂地设置为过去或未来的某个时间。

当然，如果您决定从另一个分布式组件获取时钟数据，那么您将再次陷入分布式计算的经典问题，例如，如果为您提供时间的服务停机、无法访问或太慢等等，会发生什么情况。这也适用于数据库。如果有人处理这个问题，使用这个全局的、共享的实体将在一定程度上解决问题。

Answer 2

在这种情况下，我通常不会使用计算机A或B的时间戳。我将使用数据库中的当前时间。

Answer 3

你听说过NTP(网络时间协议)协议吗？它用于网络上的计算机的时间同步，以防止此类问题。我建议您使用它，而不是解决不使用这些选择的副作用。有关更多信息，请访问以下链接：

NTP

NTP wiki