Was ist eine Snowflake-ID?
Eine Snowflake-ID ist eine 63-Bit-Ganzzahl, die zur Erzeugung eindeutiger Kennungen in einem verteilten System ohne zentrale Koordinierungsstelle dient. Twitter entwickelte das Format im Jahr 2010, um automatisch inkrementierende Datenbanksequenzen zu ersetzen, die nicht über Dutzende von Anwendungsservern hinweg skalieren konnten, die auf geshardete MySQL-Cluster schrieben. Jede Snowflake-ID ist eine vorzeichenbehaftete 64-Bit-Ganzzahl, bei der das höchstwertige Bit stets null ist, sodass 63 Nutzdatenbits verbleiben, die in vier Felder aufgeteilt sind: einen 41-Bit-Zeitstempel-Offset, eine 5-Bit-Rechenzentrumskennung, eine 5-Bit-Maschinenkennung und eine 12-Bit-Sequenznummer. Dieser Aufbau ermöglicht es einem einzelnen Snowflake-Dienstknoten, bis zu 4.096 eindeutige IDs pro Millisekunde zu erzeugen, was dem System einen theoretischen Durchsatz von Millionen von IDs pro Sekunde bei einem Einsatz mit Hunderten von Arbeitsprozessen verleiht.
Snowflake-IDs sind monoton steigend — jede neue ID ist innerhalb derselben Epoche größer als die vorherige —, aber sie sind zwischen Knoten nicht streng sequenziell. Zwei Maschinen, die in derselben Millisekunde arbeiten, erzeugen IDs, die sich verzahnen, was ein bewusster Kompromiss ist: Das Schema opfert perfekte Ordnung zugunsten absoluter betrieblicher Unabhängigkeit. Jeder Arbeiter muss lediglich seine eigene Rechenzentrums- und Maschinennummer sowie die aktuelle Uhrzeit kennen, um eine global eindeutige Kennung zu erzeugen, ohne jemals einen anderen Knoten oder einen Sperrdienst abzufragen.
Anatomie der 63-Bit-Kennung
Die Snowflake-ID ist eine 63-Bit-Ganzzahl, die sich aus den folgenden Feldern zusammensetzt, vom höchstwertigen zum niedrigstwertigen Bit:
- 41-Bit-Zeitstempel — Millisekunden, die seit einer benutzerdefinierten Epoche vergangen sind.
- 5-Bit-Rechenzentrums-ID — identifiziert das physische Rechenzentrum, das den Arbeiter beherbergt.
- 5-Bit-Maschinen-ID — identifiziert den einzelnen Host oder Prozess innerhalb dieses Rechenzentrums.
- 12-Bit-Sequenznummer — ein Zähler pro Millisekunde, der auf null zurückgesetzt wird, wenn die Uhr vorwärts tickt.
Die genaue Formulierung, die diesen Aufbau beschreibt, lautet: ein 41-Bit-Zeitstempel, 5-Bit-Rechenzentrum, 5-Bit-Maschine und 12-Bit-Sequenz. Zusammen belegen diese Felder 63 Bit, wobei das führende Vorzeichenbit auf null gesetzt ist, damit die ID bequem in eine vorzeichenbehaftete 64-Bit-Ganzzahl in Sprachen wie Java und C# passt.
Die Twitter-Epoche und die Zeitstempelkomponente
Jede Snowflake-ID trägt einen Zeitstempel-Offset, der ab einer benutzerdefinierten Epoche gemessen wird: 1288834974657 Millisekunden. Dieser Wert entspricht ungefähr dem 04.11.2010 um 04:42:54.657 UTC und wurde gewählt, um mit dem Beginn des internen Snowflake-Einsatzes von Twitter zusammenzupassen. Die Verwendung einer benutzerdefinierten Epoche anstelle der Unix-Epoche bedeutet, dass das 41-Bit-Zeitstempelfeld einen Bereich von etwa 69 Jahren abdecken kann, bevor es überläuft. Der maximale Zeitstempelwert, den das Feld aufnehmen kann, beträgt 2^41 minus 1, also 2.199.023.255.551 Millisekunden — etwa 69,7 Jahre nach der Epoche, was das Überlaufdatum in die 2080er-Jahre verschiebt.
Um einen Zeitstempel zu kodieren, subtrahiert man die Epoche von den aktuellen Millisekunden der Unix-Epoche und verschiebt das Ergebnis dann um 22 Bit nach links, um Platz für die drei niedrigeren Felder zu schaffen. Jeder Eingabezeitstempel, der vor der Epoche liegt, ist ungültig und muss zurückgewiesen werden.
Rechenzentrums- und Maschinenknoten-Identifikation
Das 5-Bit-Rechenzentrumsfeld und das 5-Bit-Maschinenfeld akzeptieren jeweils Werte von 0 bis 31, was insgesamt 1.024 eindeutige Knotenkennungen in einem Einsatz ergibt. Einem Arbeiter werden beim Start eine Rechenzentrums-ID und eine Maschinen-ID zugewiesen, typischerweise über eine Konfigurationsdatei, einen Koordinierungsdienst wie ZooKeeper oder ein Befehlszeilenargument. Die Zuweisung muss innerhalb der Flotte eindeutig sein: Zwei Arbeiter, die dasselbe (Rechenzentrum, Maschine)-Paar teilen, erzeugen kollidierende IDs, es sei denn, ihre Uhren sind phasenverschoben.
Diese Felder werden in die ID eingefügt, indem der Rechenzentrumswert um 17 Bit und der Maschinenwert um 12 Bit nach links verschoben wird und die verschobenen Werte dann per ODER-Verknüpfung in die 63-Bit-Ganzzahl eingefügt werden. Die Gesamtzahl von 1.024 Knoten ist für die meisten realen Einsätze ausreichend, aber Umgebungen, die mehr als 1.024 Arbeiter benötigen, können Bits aus dem Sequenzfeld oder dem Zeitstempelfeld entwenden, auf Kosten des Durchsatzes oder der Epochenreichweite.
Der Sequenzzähler und die Uhrgrenzen
Das 12-Bit-Sequenzfeld ist das Arbeitspferd des Snowflake-Designs. Es läuft von 0 bis 4.095 und inkrementiert um eins für jede innerhalb derselben Millisekunde erzeugte ID. Wenn die Sequenz 4.095 erreicht, läuft der Arbeiter in einer aktiven Warteschleife, bis die Systemuhr zur nächsten Millisekunde vorrückt, woraufhin die Sequenz auf null zurückgesetzt wird und die Erzeugung fortgesetzt wird. Dies gibt einem einzelnen Knoten eine maximale Burstrate von 4.096 IDs pro Millisekunde.
Uhrdrift und Uhrrückstellung sind die beiden bedeutendsten Fehlermodi des Snowflake-Algorithmus. Wenn die Systemuhr rückwärts läuft — sei es aufgrund einer NTP-Korrektur, einer Migration einer virtuellen Maschine oder einer manuellen Änderung —, könnte ein Arbeiter eine ID mit einem Zeitstempel erzeugen, der kleiner ist als die zuletzt erzeugte, wodurch die Eindeutigkeitsgarantie gebrochen wird. Die Standard-Gegenmaßnahme besteht darin, die ID-Erzeugung anzuhalten und einen Fehler auszulösen, wenn eine Uhrrückstellung erkannt wird, und die Bearbeitung von Anfragen zu verweigern, bis die Uhr den zuletzt gesehenen Zeitstempel wieder erreicht hat. Ein Einsatz, der keine Ausfallzeiten tolerieren kann, sollte einen dedizierten Zeitdienst oder eine logische Uhrschicht in Betracht ziehen.
Durchgerechnetes Beispiel
Betrachten Sie die folgenden Eingabewerte: einen Unix-Epochen-Zeitstempel von 1700000000000 Millisekunden, eine Rechenzentrums-ID von 7, eine Maschinen-ID von 13 und eine Sequenznummer von 4095.
Kodierung. Berechnen Sie zuerst den Zeitstempel-Offset: 1700000000000 minus der Snowflake-Epoche 1288834974657 ergibt 411165025343. Verschieben Sie diesen Offset um 22 Bit nach links, um 1724551110456246272 zu erhalten. Verschieben Sie den Rechenzentrumswert 7 um 17 Bit nach links, um 917504 zu erhalten. Verschieben Sie den Maschinenwert 13 um 12 Bit nach links, um 53248 zu erhalten. Die Sequenznummer erfordert keine Verschiebung. Kombinieren Sie die vier Terme mit bitweisem ODER, um die endgültige Snowflake-ID zu erzeugen: 1724551110457221119.
Dekodierung. Um die ursprünglichen Felder aus der ID 1724551110457221119 wiederherzustellen, maskieren Sie die niedrigsten 12 Bit, um die Sequenz zu extrahieren: 4095. Verschieben Sie um 12 Bit nach rechts und maskieren Sie die niedrigsten 5 Bit, um die Maschinen-ID wiederherzustellen: 13. Verschieben Sie um 17 Bit nach rechts und maskieren Sie die niedrigsten 5 Bit, um die Rechenzentrums-ID wiederherzustellen: 7. Verschieben Sie um 22 Bit nach rechts, um den Zeitstempel-Offset zu erhalten: 411165025343. Addieren Sie die Epoche 1288834974657, um den ursprünglichen Unix-Epochen-Zeitstempel wiederherzustellen: 1700000000000.
Der Roundtrip ist exakt, weil jedes Feld in seine zugewiesene Bitbreite passt und bei der Kodierung keine Informationen verloren gehen.
Genauigkeit und Einschränkungen
Das Snowflake-Kodierungsschema ist deterministisch und reversibel, sofern alle Eingaben in ihren gültigen Bereichen liegen. Der Zeitstempel-Offset muss eine nicht-negative 41-Bit-Ganzzahl sein; die Rechenzentrums- und Maschinen-IDs müssen im Bereich von 0 bis 31 liegen; und die Sequenz muss im Bereich von 0 bis 4.095 liegen. Jede Eingabe außerhalb dieser Grenzen wird als ungültig zurückgewiesen.
Das Schema berücksichtigt weder Schaltsekunden noch eine Genauigkeit unterhalb der Millisekunde. Es stützt sich auf die Systemuhr des Hosts, die driften oder von externen Prozessen angepasst werden kann. In Einsätzen, in denen die Systemuhr durch einen großen NTP-Sprung vorgestellt wird, schreitet das Offsetfeld korrekt voran, aber der Sequenzzähler war während der Lücke inaktiv, sodass ein Zeitraum ohne ausgegebene IDs entsteht. Dies ist für die Eindeutigkeit unschädlich, erzeugt jedoch eine Diskontinuität in der ID-Zeitlinie.
Netzwerkpartitionierte Arbeiter, die dasselbe (Rechenzentrum, Maschine)-Tupel teilen, erzeugen kollidierende IDs, wenn sie jemals gleichzeitig aktiv sind. Der Kennungsraum stellt 1.024 eindeutige Knotenplätze bereit, und das Überschreiten dieser Anzahl erfordert eine benutzerdefinierte Bit-Layout-Variante.
Quellen
- Twitter Snowflake-Repository: https://github.com/twitter-archive/snowflake/tree/snowflake-2010
- Ursprünglicher Ankündigungsbeitrag: https://blog.x.com/engineering/en_us/a/2010/announcing-snowflake
Redaktioneller Vermerk
Dieser Artikel beschreibt das Snowflake-ID-Format, wie es in der Referenzimplementierung von Twitter aus dem Jahr 2010 definiert ist. Das Bit-Layout und der Epochenwert sind direkt dem quelloffenen Scala-Quellcode entnommen. Das durchgerechnete Beispiel wurde mit einer manuellen Berechnung überprüft, die dieselben Werte kodiert und dekodiert, um den Roundtrip zu bestätigen. Die Erörterung der Uhrrückstellung und der Knotenbegrenzungen spiegelt die Betriebserfahrung wider, die in der ingenieurwissenschaftlichen Literatur zur verteilten ID-Erzeugung dokumentiert ist.
Der Artikel behandelt keine Drittanbieter-Implementierungen oder Varianten, die das Bit-Layout verändern — wie etwa solche, die eine 10-Bit-Maschinen-ID, eine andere Epoche oder ein aus einem Koordinierungsdienst bezogenes Arbeiter-ID-Feld verwenden. Diese Varianten liegen außerhalb des Geltungsbereichs der ursprünglichen Snowflake-Spezifikation. Autor: Redaktionsteam von SoupCalc Letzte Überprüfung: 11. August 2026.