
No Effect Before Its Cause: From Einstein to Lamport
Causality in collaborative editors · Part 1 of 2
以下正文同步自 Hacker News 最新,版权归原站所有,已转换为易读排版。
Causality in collaborative editors · Part 1 of 2
Einstein's moving train, Leslie Lamport's clocks and a 2,500-year-old idea explain the core problem of leaderless replication: ordering writes when no clock can be trusted.
Every distributed systems article is legally required to feature Alice and Bob, so let's get it over with.
Alice and Bob are editing the same sentence: "The car is ". Alice types "fast". Bob is on a train (the universe, as you'll see, is a train enthusiast), and just as it enters a tunnel his internet drops. He doesn't notice, so a few minutes later he types "slow" in the same spot, and when the train comes out of the tunnel his edit syncs.
Now the system has to decide what the sentence says. The obvious rule is "newest timestamp wins": Bob's clock says he typed later, so "slow" stays and "fast" quietly disappears, even though Bob never saw it. That rule is wrong, and the reason is the central problem of leaderless replication, where every copy of the data accepts writes on its own and no boss server decides the order.
It turns out physics ran into this exact problem more than a century ago.
In 1905, a 26-year-old patent clerk named Albert Einstein was thinking about light and clocks, and he realised something unsettling. Picture a woman standing on a station platform and a man sitting in the middle of a fast train as it passes her. Two lightning bolts strike, one at each end of the train, just as the man draws level with her. The woman says they struck at the same moment. The man says the front one struck first. Both have checked carefully. Both are right.
How? The trick is that light travels at the same speed for everyone, even someone on a moving train. While the light is on its way, the train carries the man toward the front flash and away from the rear one, so the front flash reaches him first. He's sitting exactly in the middle, and light came at him from both ends at the same speed, so he concludes, correctly for him, that the front strike happened first. The woman, standing halfway between the strikes, gets both flashes together and concludes, just as correctly, that they were simultaneous. (We'll walk through this properly, with a diagram, in a minute.)
There is no master clock hanging over the universe to tell them who's wrong. "At the same time" depends on who's asking.
But there's one thing they can never argue about. If one event caused the other, say the first flash lit a fuse that set off the second, then every observer, on any platform or any train, sees the cause before the effect. Timing is up for debate. Cause and effect is not.
Seventy-three years later, a computer scientist named Leslie Lamport looked at a network of computers and recognised the same picture. Every machine was an observer with its own clock, and there was no master clock to settle arguments. So he stopped asking "when did this happen?" and started asking "what caused this?"
That's exactly where Alice and Bob are. Their devices are the two observers. The leaderless system is the universe with no master clock. And the only honest question left is whether Bob's edit was caused by Alice's. It wasn't: he never saw it.
This article follows that thread from Einstein's train to Lamport's clocks. It shows why no timestamp can settle who came first, and what leaderless systems trust instead: cause and effect. It ends at CRDTs (conflict-free replicated data types), the data structures that collaborative editors like Yjs use to merge Alice's and Bob's edits with no master clock and no boss server. (A 2,500-year-old Buddhist idea turns up along the way, saying much the same thing.) The rule they all share: no effect before its cause.
Why collaborative editors? Because that's where I ran into leaderless replication myself. I didn't come to it through databases. I came to it by trying to understand how a Notion-like editor lets several people type into the same document, even offline, without ever losing anyone's words.
Full disclosure: I'm terrible at physics, so if you're a physicist, please be gentle. Most people spend a free weekend hiking or posting sunset photos captioned "grateful." I spent mine with a laptop and that editor, plus a dog I've photographed roughly 400 times. One thing led to another, and I ended up reading about Einstein, lightning and trains. You don't need any physics or distributed-systems background to follow along.
Go outside tonight and look up. That Sun you saw earlier? You were seeing it as it was about 8 minutes ago. Proxima Centauri? That light is over four years old. The Andromeda galaxy is a 2.5-million-year-old photo, which makes it older than every embarrassing picture your friends have of you, combined.
The sky is not a live stream. It is a museum of the past, and every exhibit is from a different year.
Now open a shared Notion-style editor while your colleague edits the same paragraph from another continent. Congratulations, your screen is also a museum. What you see of their typing is a few milliseconds old, or a few hours old if their Wi-Fi decided to go spiritual and "disconnect for a while."
Physicists have lived without a universal clock for over a century. Software engineers had to learn the same lesson, and leaderless systems are where it bites hardest.
In practice, leaderless means there's no single source of truth everyone has to bow to. Every replica (each copy of the data, on each server or device) accepts writes on its own, online or offline, and the replicas swap updates afterwards. Databases like Amazon's Dynamo, Riak and Cassandra work this way, and so do many collaborative editors. Even when an editor has a sync server in the middle, it's just a messenger relaying updates, not a judge. The goal is that once every replica has received the same updates, they all hold exactly the same data.
To see how that’s possible, we need to go back to the train, starting with how ordinary things move on one.
Before we mess with light, let's see how normal things behave. You already know this part, even if you don't know that you know it.
Imagine a train moving at a steady 200 km/h (not a Sri Lankan train, obviously). You're sitting inside, and you throw a ball forward at 20 km/h.
What you see. The ball moves forward at 20 km/h. You're also moving at 200 km/h, but you feel nothing special. It's like pouring tea on a smooth-running train: the tea doesn't fly to the back of the carriage, it just sits in the cup.
Why nothing weird happens. You, the ball, the seats, the tea and the air inside the train are all moving at the same 200 km/h together. When everything shares the same motion, it cancels out inside. Physicists call this bubble of things moving together a frame of reference. Inside the bubble, life looks exactly the same as standing still.
What a person outside sees. Someone standing next to the track sees the ball moving at the train's speed plus your throw: 200 + 20 = 220 km/h.
So it's one ball with two correct speeds: 20 km/h for you, and 220 km/h for the person outside. Speed depends on who is watching, and nobody is wrong. With normal things, speeds just add up. Throw the ball backward at 20 km/h and the person outside sees 200 − 20 = 180 km/h.
Hold on to this rule, because light refuses to follow it. Shine a torch forward on the train and you'd expect the person outside to measure the light going faster than normal. They don't. Light travels at the same speed for everyone, and that is where all the trouble starts.
Back to that 1905 idea: two events can be simultaneous for one person and not simultaneous for another, and both people are right.
Later, in 1916, Einstein explained it with a train.
Here's the setup. A train is zooming along a track. Lightning strikes both ends of the train. A woman is standing on the platform, exactly halfway between the two strikes. Both flashes reach her at the same moment, so she says: "Simultaneous. Obviously."
Meanwhile, a man is sitting in the middle of the train. While the light is travelling, the train carries him toward the front flash and away from the rear one, so the front flash reaches him first. Both flashes travel at the same speed, and he's sitting exactly in the middle of the train. So, as far as he's concerned, the flash that reaches him first must have happened first. He says: "The front strike happened first."
Who's right? Both of them. "At the same time" is not a fact about the universe. It's a fact about whoever is watching. Einstein basically invented "it depends," and computer scientists have been billing for it ever since.
This is exactly the problem with comparing timestamps from two servers. Every server's clock is its own little train. Clocks drift, jump, and get corrected by NTP (the network time protocol that keeps server clocks roughly in sync) at the worst possible moment. Asking "whose edit came first?" by comparing clocks is like asking the woman on the platform and the man on the train to agree on which strike came first. Each server's clock is its own point of view, so they won't agree.
So if nobody agrees on when, does anyone agree on anything? Yes: cause and effect. People can argue about timing all day, but an effect can never show up before its cause.
Take any event, like a firework going off. Light spreads out from it in every direction, and nothing in the universe is faster than light. Not even your project manager asking "any updates?" That growing bubble of light splits all of spacetime into three zones:
Here's the rough rule. Pick any one observer and measure two things: how long light needs to travel between the two events' locations, and how much time actually passed between them. If more time passed than light needs, a signal could have connected them, and every observer agrees on which came first. If less time passed, they're in each other's elsewhere: no signal could connect them, so neither can affect the other, and observers moving differently can disagree about their order. The best part: every observer agrees on which of the two cases it is, even when they disagree about the times.
Quick example: two points on opposite sides of the Earth are about 12,700 km apart in a straight line through the planet, so even light needs about 42 milliseconds to connect them (and about 67 ms if it had to follow the surface, the way a cable does). Two events there one second apart could be causally linked. Ten milliseconds apart? No signal could connect them, so asking which came first has no physical answer. It's like asking a friend which of his two exes was "the problem."
The elsewhere is where all the drama lives. Physics drama, software drama, all of it.
In 1978, Leslie Lamport looked at a network of computers and thought, "This is basically a tiny universe." His paper, "Time, Clocks, and the Ordering of Events in a Distributed System," borrows its central idea straight from special relativity.
He draws the network as a simple picture. Each computer is a vertical line, with time running along it. When one computer sends a message to another, you draw an arrow from the sender's line to the receiver's line. The arrow slants because the message takes time to travel: it leaves at one moment and lands at a later one. Messages are the light rays of this universe. They are the only way one machine can find out what another machine did.
Read it by following the arrows. Even though c1 sits between a1 and a2 on the page, no chain of arrows connects them, so they are concurrent, whatever any clock says.
From that picture, Lamport defined happens-before, and notice that it never mentions a clock.
If neither happens before the other, the events are concurrent. They're in each other's elsewhere. Martin Kleppmann sums it up in Designing Data-Intensive Applications: two operations are concurrent when neither knows about the other, no matter what the clock said. Concurrency isn't about doing things at the same time. It's about
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。