Générateur d'ID Snowflake - Créer des ID Distribués Uniques

Qu’est-ce qu’un générateur d’identifiants Snowflake ?

Un générateur d’ID Snowflake construit un numéro unique de 64 bits à partir d’un horodatage, d’un identifiant de machine et d’un numéro de séquence. Twitter a créé ce format en 2010 afin que les machines qui génèrent des ID n’aient pas à se coordonner entre elles. De nombreux serveurs peuvent produire des ID en même temps sans demander : « ce numéro a-t-il déjà été utilisé ? » Cet outil construit un ID Snowflake à partir des valeurs saisies et montre comment ces valeurs remplissent les 64 bits.

Fonctionnement de ce générateur d’identifiants Snowflake

Le générateur accepte quatre entrées :

• Horodatage : un horodatage Unix en millisecondes. Laissez ce champ vide pour utiliser l’heure actuelle.
• Identifiant de machine : un entier compris entre 0 et 31 (5 bits). Il s’agit de l’« identifiant de travailleur » d’origine de Twitter.
• Identifiant de centre de données : un entier compris entre 0 et 31 (5 bits).
• Numéro de séquence : un entier compris entre 0 et 4095 (12 bits), utilisé pour distinguer les identifiants créés au cours de la même milliseconde.

L’outil combine les quatre valeurs en un ID de 64 bits et affiche le résultat réparti en ses segments d’horodatage, de machine et de séquence.

L’horodatage est mesuré à partir d’un point de départ fixe appelé l’époque de Twitter : le 4 novembre 2010, 1:42:54,657 UTC, soit 1 288 834 974 657 millisecondes après l’époque Unix. Ce générateur ne permet pas de modifier ce point de départ : chaque ID qu’il produit est mesuré à partir de cette unique date fixe.

Structure d’un identifiant Snowflake

Un identifiant Snowflake est un entier de 64 bits réparti en quatre parties, lues du bit de poids fort vers le bit de poids faible :

Le bit initial vaut toujours 0, si bien qu’un identifiant Snowflake est toujours un nombre positif. Le champ d’horodatage de 41 bits et le champ de séquence de 12 bits sont les deux parties qui rendent les identifiants Snowflake faciles à trier : les identifiants créés plus tard ont un segment d’horodatage plus grand et sont donc classés après les précédents.

Formule d’un identifiant Snowflake

Le générateur construit l’identifiant avec la formule suivante :

1delta = timestamp - 1288834974657
2id = (delta << 22) | (dataCenterId << 17) | (machineId << 12) | sequence
3

<< désigne un décalage de bits vers la gauche. Décaler un nombre de 22 bits vers la gauche revient à le multiplier par 2²², soit 4 194 304. Les valeurs de décalage (22, 17, 12) proviennent directement de la largeur des champs : le champ de séquence occupe 12 bits, donc l’identifiant de machine est décalé de 12 bits ; le champ de machine occupe 5 bits, donc l’identifiant du centre de données est décalé de 17 bits (12 + 5), et ainsi de suite.

Comment calculer un identifiant Snowflake : exemple détaillé

Supposons qu’une personne saisisse :

• Horodatage : 1 288 834 975 657 (exactement 1 000 ms après l’époque Twitter)
• Identifiant du centre de données : 1
• Identifiant de machine : 1
• Numéro de séquence : 0

Étape 1 — Calculer le décalage. Soustrayez l’époque de l’horodatage : 1 288 834 975 657 − 1 288 834 974 657 = 1 000.

Étape 2 — Placer chaque champ à la bonne position.

• Horodatage : 1 000 << 22 = 4 194 304 000
• Identifiant du centre de données : 1 << 17 = 131 072
• Identifiant de machine : 1 << 12 = 4 096
• Séquence : 0

Étape 3 — Combiner avec un OU bit à bit. Comme aucun des champs décalés ne se chevauche, leur addition donne le même résultat que leur combinaison par OU :

4 194 304 000 + 131 072 + 4 096 + 0 = 4 194 439 168

Voilà l’ID Snowflake correspondant à cette saisie. La vue des résultats de l’outil redécoupe la même chaîne binaire de 64 bits en un bloc d’horodatage de 41 bits, un bloc de machine de 10 bits et un bloc de séquence de 12 bits, de sorte que la structure du nombre reste visible.

Domaines d’utilisation des identifiants Snowflake

Twitter a conçu ce format pour obtenir des ID uniques, à peu près ordonnés dans le temps, sur de nombreuses machines, sans compteur central que chaque serveur devrait consulter. D’autres plateformes ont repris l’idée. Discord, par exemple, indique qu’il utilise le format snowflake de Twitter pour ses ID. La même idée se retrouve dans le partitionnement de bases de données, les numéros de commande des systèmes de commerce électronique et les journaux d’événements des applications distribuées : partout où de nombreuses machines doivent attribuer des ID de façon indépendante tout en les gardant à peu près triés par date.

Limites des identifiants Snowflake

Un générateur Snowflake de production tient normalement sa propre horloge : il incrémente le numéro de séquence pour chaque ID créé dans la même milliseconde et attend la milliseconde suivante dès que la séquence atteint 4 095. Cet outil ne garde aucune mémoire entre deux calculs. Il construit un ID à partir de l’horodatage, des identifiants et du numéro de séquence saisis, ce qui le rend utile pour explorer le format, mais différent d’un service de production en fonctionnement.

La conception présente des limites fixes, quel que soit le service qui l’implémente :

• Époque fixe : ce générateur n’accepte que les horodatages correspondant au 4 novembre 2010 ou à une date ultérieure (l’époque Twitter). Les dates antérieures ne peuvent pas être encodées.
• Limite de l’horodatage : le champ d’horodatage de 41 bits est saturé vers juillet 2080. Après cette date, l’écart par rapport à l’époque ne tient plus dans 41 bits.
• Limite de la séquence : une seule machine ne peut émettre que 4 096 identifiants distincts (0–4095) au cours d’une même milliseconde avant que les valeurs ne se répètent.
• Espace des machines : avec 5 bits pour chacun des identifiants de machine et de centre de données, un déploiement dispose de 1 024 identités de machine distinctes (32 × 32) à attribuer sans collisions.
• Ordonnancement local, et non global : les identifiants ne sont correctement triés les uns par rapport aux autres que s’ils proviennent de machines dont les horloges sont synchronisées. La dérive des horloges entre les machines peut rompre l’ordre temporel strict.

Historique de l’identifiant Snowflake

Twitter a conçu Snowflake lors de la migration de son stockage de MySQL vers Cassandra, qui n’offre aucun mécanisme d’ID séquentiels. Les objectifs de conception étaient des ID de moins de 64 bits, uniques, à peu près ordonnés dans le temps et directement triables. La version initiale a été publiée en 2010 puis abandonnée au profit d’une réécriture interne. D’autres grandes plateformes ont repris la conception, sous une forme modifiée, parce qu’elles avaient le même besoin : des ID uniques et triables, générés par de nombreuses machines à la fois.

Questions fréquentes

Qu’est-ce qu’un identifiant Snowflake ? Un identifiant Snowflake est un nombre de 64 bits composé d’un horodatage, d’un identifiant de machine et d’un numéro de séquence, conçu pour que de nombreuses machines puissent générer des identifiants uniques sans se coordonner.

Quelle est la formule d’un identifiant Snowflake ? id = ((timestamp − epoch) << 22) | (dataCenterId << 17) | (machineId << 12) | sequence, où l’époque est une date de départ fixe et où << désigne un décalage de bits vers la gauche.

Puis-je modifier l’époque dans ce générateur ? Non. Cet outil mesure toujours l’horodatage à partir de l’époque Twitter fixe, 4 novembre 2010. Aucun champ ne permet de définir une autre date de départ.

Cet outil décode-t-il un identifiant Snowflake existant ? Non. Il construit uniquement un nouvel identifiant à partir de l’horodatage, de l’identifiant de machine, de l’identifiant du centre de données et du numéro de séquence saisis, puis affiche la répartition en bits de ce nouvel identifiant.

Combien d’identifiants Snowflake une machine peut-elle générer par milliseconde ? Jusqu’à 4 096, puisque le champ de séquence occupe 12 bits (valeurs de 0 à 4 095).

Jusqu’à quelle année ce générateur peut-il produire des horodatages valides ? Jusque vers juillet 2080. Le champ d’horodatage de 41 bits peut contenir au maximum environ 69,7 ans mesurés à partir de l’époque fixe de 2010 (les notes de Twitter arrondissent cette durée à 69 ans), après quoi la valeur dépasse la capacité du champ.

Références

1. Twitter. Snowflake README (étiquette snowflake-2010), GitHub. Snowflake README — ID non coordonnés, à peu près ordonnés dans le temps, de moins de 64 bits ; temps sur 41 bits (69 ans), identifiant de machine sur 10 bits (1 024 machines), séquence sur 12 bits (4 096 par machine et par milliseconde) ; conçu à l’occasion de la migration de MySQL vers Cassandra.
2. Twitter. IdWorker.scala (étiquette snowflake-2010), GitHub. Snowflake IdWorker.scala — twepoch = 1288834974657 ; 5 bits de travailleur, 5 bits de centre de données, 12 bits de séquence ; décalages 12, 17 et 22.
3. Discord. API Reference: Snowflakes. Référence de l’API Discord — Discord utilise le format snowflake de Twitter pour ses ID.
4. Twitter. Snowflake README (master), GitHub. Avis de retrait de Snowflake — la version initiale a été publiée en 2010 puis abandonnée.