Ticketing Snapshot
Un nœud trop en retard pour rattraper via le journal (par ex. juste après un redémarrage) reçoit l'intégralité de l'état actuel via le RPC FullSnapshot. snapshot_bytes contient la structure suivante, sérialisée avec postcard.
| Champ | Contenu |
|---|---|
last_applied | La dernière position de journal que ce snapshot reflète |
last_membership | Informations de membership (composition des nœuds) |
token_seq | Le compteur d'émission des jetons de fencing — répliqué, si bien que la monotonie des jetons tient même après un changement de leader |
locks | Une liste de (key, token, remain_ms) — chaque verrou détenu et son lease restant |
remain_msest le lease restant, en millisecondes, au moment où le snapshot a été pris. Le nœud qui l'installe restaure l'heure d'expiration commenow + remain_mssur sa propre horloge — aucun horodatage absolu n'est jamais envoyé, si bien que la dérive d'horloge entre nœuds n'a aucun effet.- Les millisecondes ne sont utilisées qu'ici, pour la précision (l'unité côté client est la seconde).
- Le journal Raft est en mémoire (volatile). Un nœud redémarré démarre avec un état vide, puis rattrape son retard via la réplication du journal d'un pair ou ce snapshot — l'état validé est préservé tant qu'une majorité reste vivante.
Flux
Leader
Nœud en retard
juste après un redémarrage — démarre avec un état vide
AppendEntries
trop en retard pour rattraper via le journal
FullSnapshot — état complet en une seule trame
installation : restaure chaque verrou en now + remain_ms
retour à de simples entrées de journal AppendEntries
RPC de consensus (Raft)
Terminologie
- Snapshot — une copie complète de l'état à un instant donné. Il permet à un nœud en retard d'installer le snapshot et de ne suivre que les entrées de journal qui suivent, au lieu de tout rejouer depuis le début.
- Membership — la liste des nœuds qui composent le cluster et leurs informations de rôle.