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

Question

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

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

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

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

Answer 1

出于多种原因，您不能相信个别计算机时钟。

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

• The quartz clock in a computer is not very accurate: it drifts (runs faster or slower than it should). Clock drift varies depending on the temperature of the machine. Google assumes a clock drift of 200 ppm (parts per million) for its servers, which is equivalent to 6 ms drift for a clock that is resynchronized with a server every 30 seconds, or 17 seconds drift for a clock that is resynchronized once a day. This drift limits the best possible accuracy you can achieve, even if everything is working correctly.
• If a computer’s clock differs too much from an NTP server, it may refuse to synchronize, or the local clock will be forcibly reset. Any applications observing the time before and after this reset may see time go backward or suddenly jump forward.
• If a node is accidentally firewalled off from NTP servers, the misconfiguration may go unnoticed for some time. Anecdotal evidence suggests that this does happen in practice.
• NTP synchronization can only be as good as the network delay, so there is a limit to its accuracy when you’re on a congested network with variable packet delays. One experiment showed that a minimum error of 35 ms is achievable when synchronizing over the internet, though occasional spikes in network delay lead to errors of around a second. Depending on the configuration, large network delays can cause the NTP client to give up entirely.
• Some NTP servers are wrong or misconfigured, reporting time that is off by hours. NTP clients are quite robust, because they query several servers and ignore outliers. Nevertheless, it’s somewhat worrying to bet the correctness of your systems on the time that you were told by a stranger on the internet.
• “Leap seconds result in a minute that is 59 seconds or 61 seconds long, which messes up timing assumptions in systems that are not designed with leap seconds in mind. The fact that leap seconds have crashed many large systems shows how easy it is for incorrect assumptions about clocks to sneak into a system. The best way of handling leap seconds may be to make NTP servers “lie," “by performing the leap second adjustment gradually over the course of a day (this is known as smearing), although actual NTP server behavior varies in practice.
• “In virtual machines, the hardware clock is virtualized, which raises additional challenges for applications that need accurate timekeeping. When a CPU core is shared between virtual machines, each VM is paused for tens of milliseconds while another VM is running. From an application’s point of view, this pause manifests itself as the clock suddenly jumping forward.
• “If you run software on devices that you don’t fully control (e.g., mobile or embedded devices), you probably cannot trust the device’s hardware clock at all. Some users deliberately set their hardware clock to an incorrect date and time, for example to circumvent timing limitations in games. As a result, the clock might be set to a time wildly in the past or the future.

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