Uhren, die ihre eigene Unsicherheit kennen: Google Spanner, TrueTime und die Beherrschung der Zeit in der Cloud

Der Aufhänger: Eine Datenbank, die das Unmögliche behauptet

Über Jahrzehnte galt in der verteilten Datenverarbeitung ein eherner Glaubenssatz: Eine Datenbank kann global verteilt, strikt konsistent und hochverfügbar sein – aber niemals alle drei Eigenschaften zugleich. Wer Daten über Kontinente hinweg repliziert, muss entweder Inkonsistenzen in Kauf nehmen oder Ausfälle. So lautete, grob gesprochen, die Lehre aus dem CAP-Theorem. Und dann veröffentlichte Google im Oktober 2012 auf der OSDI-Konferenz ein Papier über ein System namens Spanner, das genau diese Erwartung zu sprengen schien: eine relationale Datenbank, über den ganzen Globus verteilt, mit echten ACID-Transaktionen, externer Konsistenz – und einer Verfügbarkeit von mehr als fünf Neunen.

Das Bemerkenswerteste war nicht die schiere Skalierung, sondern wie Google das Konsistenzproblem löste. Nicht durch einen cleveren Konsens-Algorithmus allein, nicht durch mehr Kommunikation zwischen den Rechenzentren – sondern durch die Zeit selbst. Genauer: durch eine Uhr, die etwas tut, was gewöhnliche Uhren nicht können. Sie gibt nicht vor, die exakte Uhrzeit zu kennen. Stattdessen liefert sie ein Intervall zurück und garantiert: „Die wahre Zeit liegt irgendwo hier drin." Diese Uhr heißt TrueTime, und ihre zentrale Erfindung ist die ehrliche Offenlegung der eigenen Unsicherheit.

Warum sollte dich das interessieren – über die intellektuelle Eleganz hinaus? Weil das Problem, das Spanner löst, in jeder verteilten Architektur lauert, mit der du beruflich zu tun hast. Sobald zwei Rechner an verschiedenen Orten gemeinsam über eine Wahrheit entscheiden müssen – welche Transaktion zuerst kam, welcher Schreibvorgang gilt, welcher Zustand der aktuelle ist – stößt du auf dieselbe Frage, an der Spanner arbeitet: Was bedeutet „gleichzeitig" eigentlich, wenn es keine gemeinsame Uhr gibt? Die Antwort, die TrueTime gibt, ist nicht nur eine Ingenieursleistung. Sie ist eine Lektion darüber, wie man mit Ungewissheit umgeht: nicht, indem man sie wegredet, sondern indem man sie misst und einplant.

Dieser Artikel nimmt dich auf die ganze Strecke mit: vom fundamentalen Problem der Zeit in verteilten Systemen über Lamports logische Uhren und die Grenzen klassischer Zeitsynchronisation, hin zu TrueTimes Kerntrick – der bekannten Unsicherheit –, dem darauf aufbauenden „Commit Wait", den konsistenten Snapshots ohne Sperren, und schließlich zu der oft missverstandenen Frage, ob Spanner das CAP-Theorem nun „bricht" oder nicht. Am Ende steht eine praktische Denkfigur, die weit über Datenbanken hinausreicht.

Teil 1: Das Problem – warum es in der Cloud kein „Jetzt" gibt

Die Illusion der gemeinsamen Gegenwart

Auf einem einzelnen Computer ist die Reihenfolge von Ereignissen unproblematisch. Es gibt eine CPU, eine Uhr, einen Befehlsstrom; was zuerst geschah, geschah eben zuerst. In dem Moment aber, in dem zwei Maschinen an verschiedenen Orten beteiligt sind, zerfällt diese Selbstverständlichkeit. Maschine A in Frankfurt und Maschine B in Iowa haben jeweils ihre eigene Quarzuhr, und diese Uhren laufen unweigerlich auseinander – sie driften. Eine typische Server-Quarzuhr kann pro Tag um mehrere Sekunden vom Soll abweichen. Es gibt keine physikalisch ausgezeichnete „gemeinsame Gegenwart", auf die sich beide Maschinen ohne Weiteres berufen könnten.

Schlimmer noch: Selbst wenn man die Uhren perfekt synchronisieren könnte, setzt die Physik eine harte Grenze. Information breitet sich höchstens mit Lichtgeschwindigkeit aus. Eine Nachricht von Europa nach Nordamerika braucht über Glasfaser realistisch einige zehn Millisekunden. Brewer rechnet in seinem CAP-Papier vor: Eine Strecke von rund 1000 Meilen entspricht etwa fünf Millionen Fuß, und bei rund einem halben Fuß pro Nanosekunde im Medium ergibt das eine minimale Laufzeit von etwa 10 Millisekunden – nur für die reine Distanz. Die Frage „Was ist jetzt der Zustand des Systems?" hat über große Entfernungen schlicht keine eindeutige, sofort verfügbare Antwort. Diese Tatsache ist nicht behebbar; sie ist tief in der Struktur von Raum und Zeit verankert (ein Echo der Relativitätstheorie, das auch in der Spukhafte Fernwirkung: Quantenverschränkung von Einstein zum Quanteninternet eine Rolle spielt: Es gibt keine universelle Gleichzeitigkeit).

Warum „einfach NTP" nicht genügt

Die naheliegende Antwort eines Praktikers lautet: „Synchronisiere die Uhren halt mit NTP." Das Network Time Protocol gleicht Rechneruhren gegen Zeitserver ab und hält sie typischerweise im Bereich einiger Millisekunden, im günstigen Fall darunter. Für Logdateien und Cron-Jobs ist das vollkommen ausreichend.

Für eine strikt konsistente Datenbank ist es das nicht – aus einem subtilen, aber entscheidenden Grund: NTP sagt dir nicht, wie falsch es gerade liegt. Du bekommst eine Zahl, einen Zeitstempel, der so tut, als sei er exakt. In Wahrheit kann er um einige Millisekunden danebenliegen – aber du weißt nicht, um wie viele. Wenn zwei Maschinen ihre lokalen, leicht abweichenden Uhren befragen und beide einen Zeitstempel für eine Transaktion vergeben, kann es passieren, dass eine Transaktion, die später in der realen Welt stattfand, einen früheren Zeitstempel erhält. Die kausale Ordnung kehrt sich um. Für ein Banksystem, ein Inventar oder eine Berechtigungsdatenbank ist das ein Korruptionsrisiko: Ein Lesevorgang könnte einen Zustand sehen, der eine bereits bestätigte Änderung nicht enthält.

Das eigentliche Gift ist also nicht der Fehler an sich – jede Uhr hat einen Fehler –, sondern der unbekannte Fehler. Ein Zeitstempel ohne Fehlerangabe ist wie eine Messung ohne Fehlerbalken: Er suggeriert eine Präzision, die er nicht hat. Genau diese trügerische Scheingenauigkeit ist es, die TrueTime später beseitigt. (Wer über Fehlerbalken und ihre Tücken nachdenkt, findet eine verwandte Geschichte in der Die kosmische Spannung: Warum das Universum zwei Expansionsraten zu haben scheint – auch dort entscheidet die ehrliche Behandlung der Unsicherheit über die ganze Interpretation.)

Teil 2: Logische Zeit – Lamports geniale Umgehung und ihre Grenze

Ereignisse ordnen, ohne Uhren zu vertrauen

Lange bevor jemand an global synchronisierte Atomuhren dachte, löste Leslie Lamport 1978 das Ordnungsproblem auf eine ganz andere, fast schon philosophische Weise. Sein berühmtes Papier Time, Clocks, and the Ordering of Events in a Distributed System fragt nicht: „Wie spät ist es wirklich?" Sondern: „Welche Ereignisse müssen vor welchen anderen passiert sein?"

Lamports Schlüsselbegriff ist die happened-before-Relation (geschah-vor). Sie definiert eine partielle Ordnung allein aus der Logik der Kausalität: Innerhalb eines Prozesses ist die Reihenfolge klar; und wenn Prozess A eine Nachricht sendet, die Prozess B empfängt, dann geschah das Senden zwingend vor dem Empfangen. Aus diesen beiden Regeln baut Lamport „logische Uhren" – simple Zähler, die bei jedem Ereignis hochgezählt und mit jeder Nachricht weitergereicht werden. Das Resultat ist eine konsistente Ordnung kausal verknüpfter Ereignisse, ganz ohne physikalische Zeit. Diese Idee ist eines der Fundamente der gesamten verteilten Datenverarbeitung; Vektoruhren und ähnliche Konstrukte bauen darauf auf.

Lamports Ansatz hat eine bestechende Eigenschaft: Er ist immer korrekt, weil er sich auf gar keine Uhr verlässt. Aber er hat eine ebenso fundamentale Grenze.

Was logische Uhren nicht können: die Außenwelt

Logische Uhren ordnen nur Ereignisse, die durch eine Kette von Nachrichten kausal verbunden sind. Ereignisse, zwischen denen keine solche Kette läuft, bleiben unvergleichbar – die Ordnung ist partiell, nicht total. Vor allem aber kennen logische Uhren die reale Zeit der Außenwelt nicht. Genau das wird zum Problem, sobald Beobachter ins Spiel kommen, die außerhalb des Systems stehen.

Stell dir vor, du buchst online einen Flug (Transaktion T1), bestätigst die Buchung, rufst dann deinen Partner an und der bucht auf derselben Website den Nebenplatz (Transaktion T2). Im realen Ablauf geschah T1 nachweislich vor T2 – das wisst ihr beide, weil zwischen den beiden Buchungen ein Telefonat lag, also ein Kommunikationskanal außerhalb der Datenbank. Eine korrekte Datenbank muss diese Außen-Reihenfolge respektieren: Niemand darf je einen Zustand sehen, in dem T2 vor T1 wirksam wurde. Diese starke Eigenschaft heißt externe Konsistenz (eng verwandt mit Linearisierbarkeit): Wenn T2 in der realen Welt zu committen beginnt, nachdem T1 fertig committet hat, dann muss der Zeitstempel von T2 größer sein als der von T1 – selbst wenn beide Transaktionen auf entgegengesetzten Seiten der Erde laufen.

Logische Uhren allein können das nicht garantieren, weil sie den außerhalb laufenden Kanal (das Telefonat) nicht sehen. Für externe Konsistenz braucht man einen Bezug zur physikalischen Zeit. Und damit sind wir wieder beim Uhrenproblem – nur dass es jetzt unausweichlich gelöst werden muss. Genau hier setzt TrueTime an.

Teil 3: TrueTime – die Uhr, die ihre eigene Unsicherheit kennt

Ein Intervall statt eines Punktes

Die zentrale, beinahe trotzig einfache Idee von TrueTime: Eine ehrliche Uhr gibt keinen Zeitpunkt zurück, sondern ein Zeitintervall. Die Kernmethode TT.now() liefert ein Paar von Werten – earliest und latest – und garantiert formal: Die absolute Echtzeit zum Zeitpunkt des Aufrufs liegt mit Sicherheit innerhalb dieses Intervalls. In der Notation des Spanner-Papiers gilt für tt = TT.now() stets tt.earliest ≤ t_abs(e_now) ≤ tt.latest.

Die halbe Breite dieses Intervalls ist die instantane Fehlerschranke, üblicherweise mit dem griechischen Buchstaben ε (Epsilon) bezeichnet. Epsilon ist also das Maß der eingestandenen Unsicherheit. Eine perfekte Uhr hätte ε = 0; eine ehrliche reale Uhr hat ein kleines, aber von null verschiedenes ε und – das ist der Clou – sie kennt dieses ε und legt es offen. Zwei zusätzliche Bequemlichkeitsmethoden ergeben sich unmittelbar: TT.before(t) ist genau dann wahr, wenn t garantiert in der Zukunft liegt (t < tt.earliest), und TT.after(t) ist genau dann wahr, wenn t garantiert in der Vergangenheit liegt (t > tt.latest).

Daraus folgt eine schlichte, mächtige Regel: Überlappen sich zwei TrueTime-Intervalle nicht, dann ist die reale Reihenfolge der beiden Aufrufe eindeutig bekannt. Überlappen sie sich, weiß man es nicht – und muss vorsichtig sein. TrueTime macht also die Grenze des Wissbaren explizit, statt sie zu verschleiern.

Wie aus Hardware Vertrauen wird: GPS und Atomuhren

Damit das Intervall schmal bleibt, betreibt Google in jedem Rechenzentrum Zeit-Master-Maschinen und auf jeder gewöhnlichen Maschine einen Timeslave-Daemon. Die Master beziehen ihre Zeit aus zwei bewusst unterschiedlichen physikalischen Quellen, weil diese komplementäre Fehlermodi haben:

Die Mehrheit der Master besitzt GPS-Empfänger mit eigenen Antennen. GPS liefert über die Satelliten-Atomuhren eine sehr genaue Zeit, ist aber verwundbar durch Antennen- und Empfängerausfälle, lokale Funkstörungen, Spoofing und systematische Fehler (etwa falsche Schaltsekundenbehandlung). Eine kleinere Gruppe von Mastern – im Paper halb scherzhaft „Armageddon-Master" genannt – ist stattdessen mit Atomuhren ausgestattet. Diese sind erstaunlich erschwinglich (eine Größenordnung vergleichbar mit einem GPS-Master) und fallen auf eine Weise aus, die unkorreliert zu GPS ist: Sie driften langsam aufgrund von Frequenzfehlern, aber sie sind immun gegen GPS-Störungen. Indem Google beide Quellen kombiniert, übersteht das System den Ausfall jeweils einer der beiden Welten.

Jeder Daemon befragt regelmäßig eine Vielzahl von Mastern – nahe und ferne GPS-Master sowie einige Armageddon-Master – und wendet eine Variante von Marzullos Algorithmus an, um „Lügner" (defekte oder abweichende Master) zu erkennen und zu verwerfen und sich auf die übereinstimmende Mehrheit zu synchronisieren. Maschinen, deren lokale Uhr stärker abweicht als die spezifizierte Worst-Case-Schranke, werden aus dem Verkehr gezogen.

Die Größenordnung: Epsilon im Sägezahn

Wie groß ist ε in der Praxis? Hier wird die Mechanik anschaulich. Zwischen zwei Synchronisationen lässt der Daemon seine Unsicherheit wachsen, weil die lokale Uhr ohne frischen Abgleich langsam driftet. Google rechnet konservativ mit einer Worst-Case-Driftrate von 200 Mikrosekunden pro Sekunde. Das Poll-Intervall – der Abstand zwischen zwei Synchronisationen – lag zur Zeit des Papiers bei 30 Sekunden. In diesem Rhythmus folgt ε einer Sägezahnkurve: Direkt nach der Synchronisation ist die Unsicherheit klein, dann wächst sie linear mit der Drift, bis die nächste Synchronisation sie wieder herunterzieht. In Googles damaliger Produktionsumgebung schwankte ε so zwischen etwa 1 und 7 Millisekunden, im Mittel also rund 4 Millisekunden.

Man halte sich vor Augen, was hier geschieht: Statt zu behaupten, die Uhr sei exakt, misst das System fortlaufend, wie unsicher sie gerade ist, und schreibt diese Unsicherheit in jeden Zeitstempel hinein. Die Frage, ob eine Maschine die korrekte Zeit „wirklich weiß" oder nur zufällig richtig läge, wird so von Glück auf eine belastbare Garantie umgestellt – ein technischer Verwandter der erkenntnistheoretischen Frage aus dem Drei Seiten gegen 2000 Jahre: Das Gettier-Problem und die Frage, was Wissen ist: Wann ist eine Überzeugung echtes Wissen und nicht bloß ein glücklicher Treffer?

Teil 4: Commit Wait – „warte die Unsicherheit aus"

Der einfachste denkbare Trick, und warum er funktioniert

Jetzt kommt der Moment, in dem aus der ehrlichen Uhr echte externe Konsistenz wird – und die Lösung ist von fast schon frecher Schlichtheit. Sie heißt Commit Wait.

Wenn Spanner eine Schreibtransaktion committet, vergibt der koordinierende Leader einen Commit-Zeitstempel s. Er wählt s mindestens so groß wie TT.now().latest zum Zeitpunkt des Commits – also als sicher nicht zu früh. Und dann tut das System etwas Kontraintuitives: Es wartet. Genauer wartet der Leader, bis TT.after(s) wahr ist – das heißt, bis die gesamte TrueTime-Uhr garantiert über s hinausgelaufen ist, bis also s zweifelsfrei in der Vergangenheit liegt. Erst danach werden die Sperren freigegeben und die Transaktion als committet sichtbar.

Die Wartezeit beträgt im Mittel ungefähr 2ε (man muss von now bis latest und dann die Unsicherheit auswarten), also bei ε ≈ 4 ms wenige Millisekunden. Entscheidend: Diese Wartezeit läuft parallel zur ohnehin nötigen internen Kommunikation des Zwei-Phasen-Commits, sodass sie in der Praxis kaum zusätzliche Latenz kostet. Man „bezahlt" die Unsicherheit, aber meist aus einem Budget, das man sowieso ausgeben musste.

Warum das die Reihenfolge garantiert

Der Beweis dahinter ist kurz und schön. Betrachte zwei Transaktionen T1 und T2, wobei T2 in der realen Welt erst zu committen beginnt, nachdem T1 fertig committet hat. Dann gilt eine kleine Kette von Ungleichungen:

• Durch Commit Wait ist der Zeitstempel von T1 garantiert vor der absoluten realen Commit-Zeit von T1: s1 < t_abs(commit von T1).
• Nach Annahme begann T2 erst nach diesem Zeitpunkt: t_abs(commit von T1) < t_abs(start von T2).
• Durch Kausalität und die Wahl von s2 = TT.now().latest beim Start von T2 ist s2 nicht kleiner als die reale Startzeit von T2.

Setzt man das zusammen, folgt zwingend s1 < s2. Die Zeitstempel respektieren also die reale, von außen beobachtbare Reihenfolge – exakt das, was externe Konsistenz verlangt. Der ganze Zauber besteht darin, die Unsicherheit nicht zu ignorieren, sondern sie auszuwarten. Brewer formuliert das als allgemeines Muster: „Waiting out the uncertainty" – die Ungewissheit aussitzen – ist eine wiederkehrende, robuste Technik in verteilten Systemen.

Es lohnt, kurz innezuhalten und die Schönheit dieser Lösung zu würdigen. Das schwierigste Problem verteilter Datenbanken – eine globale Ordnung ohne globale Uhr – wird nicht durch mehr Kommunikation gelöst, sondern durch Geduld, gestützt auf eine Uhr, die ehrlich über ihre Grenzen ist. Statt zu fragen „Sind wir uns einig, wie spät es ist?" sagt jeder Knoten nur: „Ich warte, bis selbst im ungünstigsten Fall keine Verwechslung mehr möglich ist."

Teil 5: Der eigentliche Gewinn – konsistente Snapshots ohne Sperren

So elegant Commit Wait ist – Brewer weist ausdrücklich darauf hin, dass der größte praktische Wert von TrueTime woanders liegt: bei konsistenten Lesevorgängen ohne Sperren.

Spanner ist ein Mehrversionssystem (Multi-Version Concurrency Control): Es behält alte Versionen jedes Datums mit ihren Zeitstempeln. Weil jeder Schreibvorgang einen monoton wachsenden, real verankerten Zeitstempel trägt, kann man die gesamte Datenbank zu einem exakten Zeitpunkt der Vergangenheit lesen – einen sauberen Snapshot. Solche Snapshot-Reads brauchen überhaupt keine Sperren und blockieren keine laufenden Schreibvorgänge. Jeder hinreichend aktuelle Replikat-Knoten kann sie lokal beantworten, was Lesevorgänge schnell und billig macht.

Damit ein Replikat weiß, ob es einen Lesezeitpunkt t schon bedienen darf, führt es eine sogenannte Safe Time t_safe: den höchsten Zeitstempel, bis zu dem es garantiert auf dem aktuellen Stand ist. Es darf einen Read bei t genau dann beantworten, wenn t ≤ t_safe. Das ist eine bemerkenswert präzise Form von „Bescheid wissen": Das Replikat behauptet nicht, alles zu kennen, sondern weiß genau, bis wohin sein Wissen reicht.

Der praktische Nutzen ist enorm. Eine Analyse-Abfrage über die ganze Datenbank – etwa ein großer MapReduce-Lauf – kann einen einzigen, präzisen Zeitstempel wählen und erhält reproduzierbare, in sich konsistente Ergebnisse, ganz so, als hätte man die Welt für einen Augenblick angehalten. Bei älteren Systemen wie Bigtable war der Zeitbegriff über die Daten-Shards hinweg „ausgefranst" (jagged), was Ergebnisse besonders für die jüngste Vergangenheit unvorhersehbar machte. Genau diese Konsistenz ist auch der Grund, warum sich aus Spanner-Snapshots saubere Backups und Wiederherstellungen bauen lassen: Ein Snapshot liegt stets zwischen zwei Transaktionen und enthält nie eine halb angewandte Transaktion, die eine Invariante verletzen würde – und zwar selbst dann, wenn man die Invarianten gar nicht explizit kennt.

TrueTime erlaubt sogar, Snapshots über mehrere unabhängige Systeme hinweg konsistent zu ziehen, solange alle monoton wachsende TrueTime-Zeitstempel verwenden und sich auf einen Snapshot-Zeitpunkt einigen. Und man kann sich nicht nur auf die Vergangenheit, sondern auf die Zukunft einigen: Spanner unterstützt atomare Schemaänderungen, indem ein zukünftiger Zeitpunkt festgelegt wird, zu dem alle Replikate gleichzeitig auf das neue Schema umschalten. Die ganze Idee, den Zustand aus einer geordneten Folge zeitgestempelter Ereignisse zu rekonstruieren, ist im Kern dieselbe, die hinter dem Das Logbuch der Wahrheit: Event Sourcing und CQRS verstehen steht – Spanner liefert gewissermaßen die global verlässliche Uhr, die ein solches Logbuch erst über Kontinente hinweg eindeutig macht.

Teil 6: Bricht Spanner das CAP-Theorem? Ein verbreitetes Missverständnis

Was CAP wirklich sagt

Kein Artikel über Spanner kommt um die Frage herum, die in jeder zweiten Diskussion auftaucht: „Hebelt Spanner nicht das CAP-Theorem aus?" Die kurze Antwort lautet: nein – und die längere ist lehrreicher als die Legende.

Das CAP-Theorem geht auf eine Vermutung von Eric Brewer (um 2000) zurück, die Seth Gilbert und Nancy Lynch 2002 formal bewiesen. Es besagt, vereinfacht: Von den drei Eigenschaften Konsistenz (C, hier als Serialisierbarkeit gedacht), Verfügbarkeit (A, 100 % – jede Anfrage erhält eine Antwort) und Partitionstoleranz (P, das System arbeitet trotz unterbrochener Netzwerkverbindungen weiter) kann man nicht alle drei zugleich uneingeschränkt haben. Über Weitverkehrsnetze gelten Partitionen als unvermeidlich; sobald man das akzeptiert, muss man im Partitionsfall zwischen C und A wählen. Wichtig – und oft überlesen – ist Brewers Feinheit: Man muss das nur während einer tatsächlichen Partition aufgeben, und das eigentliche Theorem spricht von 100 % Verfügbarkeit, während die interessante Praxis von realistisch hoher Verfügbarkeit handelt.

Spanners ehrliche Antwort: „effektiv CA", technisch CP

Brewer selbst hat dem 2017 ein eigenes Papier gewidmet – Spanner, TrueTime and the CAP Theorem – und darin mit der Legende aufgeräumt. Seine Position ist erfrischend nüchtern: Spanner ist technisch ein CP-System. Wenn eine Partition auftritt, wählt Spanner Konsistenz und opfert im Zweifel Verfügbarkeit. Das liegt an konkreten Designentscheidungen: Updates laufen über Paxos-Gruppen, die eine Mehrheit (Quorum) brauchen; verliert ein Leader das Quorum, stocken Schreibvorgänge. Und der Zwei-Phasen-Commit für gruppenübergreifende Transaktionen kann ebenfalls blockieren, wenn die Beteiligten getrennt sind.

Und doch dürfen Nutzer Spanner in der Praxis wie ein CA-System behandeln – Brewer nennt das „effectively CA" (effektiv CA). Der Grund ist nicht TrueTime, sondern etwas viel Erdigeres: Googles eigenes, privates Weitverkehrsnetz. Jedes Spanner-Paket fließt ausschließlich über Google-kontrollierte Router und Leitungen; jedes Rechenzentrum hängt über mindestens drei unabhängige Glasfaserstrecken am globalen Netz. Dadurch werden echte Partitionen so selten, dass sie als Verfügbarkeitsursache praktisch verschwinden. In Brewers Auswertung interner Vorfälle entfielen weniger als 8 % auf die Kategorie „Netzwerk" – und in keinem einzigen Fall wurde ein großer Cluster-Verbund vom anderen abgeschnitten oder lag ein Spanner-Quorum auf der Minderheitsseite einer Partition. Spanner erreicht damit intern mehr als fünf Neunen Verfügbarkeit. Wenn aber doch einmal eine echte Partition zuschlägt, hält Spanner kompromisslos an der Konsistenz fest.

Hier liegt die wirklich wichtige Einsicht, und sie wird oft verkehrt herum erzählt: TrueTime „umgeht" CAP nicht. Brewer betont ausdrücklich, dass TrueTime zur Verfügbarkeit kaum beiträgt. TrueTimes Beitrag ist Konsistenz – externe Konsistenz, sperrenfreie konsistente Reads und konsistente Snapshots. Die Verfügbarkeit kommt vom Netz und von jahrelanger operativer Härtung. Das Verdienst der bekannten Unsicherheit ist also nicht, ein Theorem zu brechen, sondern eine stärkere Konsistenzgarantie zu liefern, ohne dafür die übliche Latenz- und Verfügbarkeitsstrafe zu zahlen.

Eine Landkarte der Ansätze

Um die Einordnung zu erleichtern, hier eine Übersicht der Strategien, wie verteilte Systeme mit Zeit und Ordnung umgehen:

Die Zeile zu TrueTime ist die eigentliche Pointe: Sie erkauft sich Konsistenz nicht durch mehr Reden, sondern durch eine bessere Uhr und ein kurzes, geplantes Warten.

Erkenntnis zum Mitnehmen

Die zentrale, übertragbare Einsicht hinter Spanner und TrueTime ist nicht „Google hat eine teure Uhr gebaut". Sie ist viel allgemeiner und praktischer:

Ungewissheit verschwindet nicht, wenn man sie ignoriert – aber sie wird beherrschbar, sobald man sie misst und in das eigene Vorgehen einplant. Eine gewöhnliche Uhr lügt durch falsche Präzision: Sie nennt eine Zahl und verschweigt ihren Fehler. TrueTimes Durchbruch besteht darin, den Fehler offen mitzuliefern – und dann lässt sich auf dieser Ehrlichkeit eine harte Garantie aufbauen, indem man im Zweifel einfach so lange wartet, bis keine Verwechslung mehr möglich ist.

Übertrage das auf deine eigene Arbeit. Überall, wo du dich auf einen Wert verlässt – einen Cache-Eintrag, einen replizierten Status, das Ergebnis eines verteilten Jobs, einen externen API-Zeitstempel – lohnt die TrueTime-Frage: Wie groß ist hier eigentlich mein ε? Und plane ich diese Unsicherheit ein, oder tue ich so, als gäbe es sie nicht? Ein System, das sein eigenes Nichtwissen kennt und konservativ behandelt, ist robuster als eines, das blind auf scheinbare Genauigkeit vertraut. Das gilt für Datenbanken ebenso wie für Schätzungen in einem Projektplan, für Monitoring-Schwellen oder für die Frage, ob zwei Ereignisse in deinen Logs wirklich in der Reihenfolge passierten, die ihre Zeitstempel suggerieren. „Warte die Unsicherheit aus" ist mehr als ein Datenbanktrick – es ist eine Haltung gegenüber unvollständigem Wissen.

Reflexionsfrage

Denk an eine Stelle in deiner Architektur, an der du dich auf Zeitstempel oder auf „den aktuellen Zustand" eines entfernten Systems verlässt – eine Synchronisation, ein verteilter Lock, eine Reihenfolge-Annahme zwischen zwei Diensten. Stell dir nun vor, jede dieser Uhren würde dir nicht einen Zeitpunkt, sondern ein Intervall mit ihrer ehrlichen Unsicherheit zurückgeben. Wie groß wäre dieses Intervall wohl wirklich – Mikrosekunden, Millisekunden, Sekunden? Und welche deiner aktuellen Annahmen über „vorher" und „nachher" würden zerbrechen, wenn die Intervalle sich überlappen? Was müsstest du messen oder auswarten, um aus einer riskanten Annahme eine belastbare Garantie zu machen?

Querverweise im Vault

• Das Logbuch der Wahrheit: Event Sourcing und CQRS verstehen – Beide Themen drehen sich um den Zustand als geordnete Folge zeitgestempelter Ereignisse; TrueTime liefert die global eindeutige Ordnung, die ein solches Logbuch über Kontinente hinweg erst zuverlässig macht.
• Spukhafte Fernwirkung: Quantenverschränkung von Einstein zum Quanteninternet – Die fehlende universelle Gleichzeitigkeit und die Lichtgeschwindigkeit als harte Grenze für Information verbinden Relativität und verteilte Systeme direkt miteinander.
• Die kosmische Spannung: Warum das Universum zwei Expansionsraten zu haben scheint – Ein Paradebeispiel dafür, dass die ehrliche Behandlung von Fehlerschranken (ε) über die ganze Interpretation entscheidet – in der Kosmologie wie in der Datenbank.
• Drei Seiten gegen 2000 Jahre: Das Gettier-Problem und die Frage, was Wissen ist – Wann „weiß" ein Replikat die Zeit wirklich und wann hat es nur zufällig recht? Die Safe-Time-Garantie ist die technische Antwort auf eine zutiefst erkenntnistheoretische Frage.

Quellen

• James C. Corbett et al. (2012): Spanner: Google's Globally-Distributed Database. Proceedings of OSDI '12. Original-PDF: https://research.google.com/archive/spanner-osdi2012.pdf
• Eric A. Brewer (2017): Spanner, TrueTime and the CAP Theorem. Google Research. PDF: https://research.google.com/pubs/archive/45855.pdf
• Google Cloud: Spanner – TrueTime and external consistency (offizielle Dokumentation): https://docs.cloud.google.com/spanner/docs/true-time-external-consistency
• Leslie Lamport (1978): Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM 21(7), S. 558–565: https://lamport.azurewebsites.net/pubs/time-clocks.pdf
• Seth Gilbert & Nancy Lynch (2002): Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. ACM SIGACT News 33(2): https://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf
• Barbara Liskov (1991): Practical Uses of Synchronized Clocks in Distributed Systems. ACM PODC. Zusammenfassung u. a. via Spanner-/Brewer-Referenzen (siehe oben).

← All articles