A Practical Perspective
Let's look into the practical perspective of clocks and time in distributed systems.
The clocks used in real systems are what we usually call physical clocks.
Physical clock
A
Most physical clocks are based on cyclic processes. Below are some examples of such devices:
Sundial
A sundial is one of the most basic and easy-to-understand devices. It tells the time of the day by using a gnomon and tracking the shadow created by the sun.
Hourglass
An hourglass is also a basic and easy-to-understand device. It measures time by the regulated flow of sand through a bulb.
Pendulum clock
A pendulum clock is a common clock device that uses an oscillating weight as its timekeeping element.
Quartz clock
A quartz clock is an electronic version of the pendulum clock and is used in software systems. This device makes use of a crystal, called quartz crystal, that vibrates or ticks with a specific frequency when electricity is applied to it.
Atomic clock
An atomic clock is one of the most accurate timekeeping devices. It uses the frequency of electronic transitions in certain atoms to measure time.
Skew between clocks
All of the above devices rely on physical processes to measure time. Of course, errors may reside in the measurement tools and the physical processes themselves.
As a result, no matter how often we synchronize these clocks with each other or other clocks with accurate measurement methods, there will always be a skew between the various clocks involved in a distributed system.
Side effects of assuming a global clock in distributed systems
When we build a distributed system, we must take the difference between clocks into account. The overall system should not operate under the assumption that all these clocks are the same and act as a single global clock.
The following illustration contains an example of what could happen otherwise.
is the event happening at node , and is the timestamp assigned to that event. The same is true for the other such symbols.
Let’s assume we have a distributed system comprising of three different nodes A, B, and C. Every time an event happens at a node, the node assigns a timestamp to the event, using its own clock, and then propagates this event to the other nodes. As the nodes receive events from the other nodes, they compare the timestamps associated with these events to determine the order in which the events happened.
If all the clocks were completely accurate and reflected exactly the same time, the scheme would theoretically be capable of identifying the order.
However, if there is a skew between the clocks of the various nodes, the correctness of the system is violated.
More specifically, in our example, we assume that the clock of node A runs ahead of the clock of node B. In the same way, the clock of node C runs behind the clock of node B. As a result, even if the event in node A happened before the event in node C, node B will compare the associated timestamps and believe that the event from node C happened first.
Conclusion
From a practical point of view, the best we can do is to accept there will always be a difference between the clocks of different nodes in the system. Then, we can expose this uncertainty in some way so that the various nodes in the system can handle it appropriately.
is a system that follows this approach, using the TrueTime API that directly exposes this uncertainty by using time intervals (embedding an error) instead of plain timestamps. Spanner J. C. Corbett et al., “Spanner: Google’s Globally-Distributed Database,” in Proceedings of OSDI 2012, 2012.
Get hands-on with 1400+ tech skills courses.