Sujet : consensus
-
Ce que garantit un cluster Raft : majorités, un seul leader et lectures linéarisables
Les systèmes de consensus tels qu'etcd (Raft) permettent à une majorité de serveurs de s'accorder sur un journal ordonné ; ils restent corrects quel que soit le nombre de pannes, mais ne progressent que tant qu'une majorité reste joignable. Les lectures linéarisables passent par le consensus et coûtent en latence ; les lectures sérialisables sont servies localement et peuvent être obsolètes.
-
Verrous distribués et baux de leader : expiration, jetons de barrière et ce qu'un verrou ne peut pas promettre
Un verrou distribué est un bail qui expire ; un processus mis en pause par un ramasse-miettes, une contention CPU ou un réseau retardé peut continuer d'agir après que son bail est passé à quelqu'un d'autre. Seul un jeton de barrière strictement croissant, vérifié par la ressource protégée, rend un tel verrou sûr pour la correction ; un verrou utilisé simplement pour éviter un travail en double demande moins.
-
Horloges logiques : horodatages de Lamport, horloges vectorielles et horloges hybrides
Les horloges murales de machines différentes ne concordent pas, si bien qu'ordonner des événements par horodatage fait perdre des mises à jour. Les horodatages de Lamport donnent un ordre compatible avec la causalité, les horloges vectorielles détectent en plus les mises à jour concurrentes, et les horloges logiques hybrides conservent une valeur proche de l'heure murale tout en préservant l'ordre causal.
Lisible par machine : JSON