Comment implémenter un verrouillage distribué (2016)

Implémenter un verrou distribué

• Découverte de l’algorithme Redlock sur le site web de Redis, qui affirme implémenter un verrou distribué tolérant aux pannes au-dessus de Redis.
• Plusieurs implémentations indépendantes de Redlock existent déjà, et comme certaines personnes peuvent dépendre de cet algorithme, l’auteur a décidé de partager ses notes.
• Redis est utile pour partager entre serveurs des données temporaires et qui changent rapidement, mais son extension au domaine de la gestion de données exigeant une forte cohérence et de la durabilité suscite des inquiétudes.

Objectif des verrous

• Un verrou sert à garantir qu’un seul nœud parmi plusieurs exécute une tâche donnée.
• Si l’on utilise un verrou pour des raisons d’efficacité, il peut être préférable d’utiliser une seule instance Redis.
• Si l’on utilise un verrou pour des raisons de justesse, Redlock n’est pas adapté.

Protéger une ressource avec un verrou

• Dans un système distribué, un verrou est différent d’un mutex dans une application multithread.
• Il empêche qu’un autre client effectue la même opération pendant qu’un client lit un fichier, le modifie puis le réécrit.

Implémenter un verrou sûr grâce au fencing

• On peut implémenter un verrou sûr en utilisant des jetons de fencing inclus dans les requêtes d’écriture.
• Redlock n’est pas sûr, car il ne génère pas de jetons de fencing.

Utiliser le temps pour parvenir à un consensus

• Contrairement aux algorithmes conçus pour un modèle asynchrone, Redlock repose fortement sur des hypothèses liées au temps.
• Si l’horloge système fonctionne de manière anormale, l’expiration des clés peut se produire plus tôt ou plus tard que prévu.

Rompre les hypothèses temporelles de Redlock

• Redlock suppose un modèle de système synchrone et ne fonctionne correctement que si les délais réseau, les pauses de processus et les erreurs d’horloge restent limités.
• Des cas comme l’incident de délai de 90 secondes sur les paquets chez GitHub peuvent menacer la sûreté de Redlock.

Conclusion

• Redlock est inutilement lourd pour des verrous visant l’optimisation de l’efficacité, et pas suffisamment sûr dans les situations exigeant de la justesse.
• Si un verrou est nécessaire pour garantir la justesse, il est préférable d’utiliser un véritable système de consensus, comme ZooKeeper.

Résumé GN⁺

• L’algorithme Redlock apporte une discussion importante sur l’implémentation des verrous dans les systèmes distribués.
• Cet article met en avant les hypothèses temporelles et les problèmes de sûreté dans les systèmes distribués, et explique l’importance d’une implémentation correcte des verrous.
• Il recommande des systèmes alternatifs comme ZooKeeper et aide à mieux comprendre la complexité des systèmes distribués.

[GN⁺]

Avis Hacker News

• J’ai déjà mis en œuvre un verrouillage distribué avec Temporal, et jusqu’à présent cela fonctionne bien. Les fonctionnalités de Temporal rendent l’implémentation d’un verrouillage distribué simple
• J’ai laissé un commentaire sur le blog pour dire qu’un point important de l’algorithme avait été manqué, ce qui montre que son rejet repose sur un point faible
• Avec les ordinateurs modernes et les API actuelles, on peut attendre des durées approximatives, les pauses GC sont limitées et les horloges monotones fonctionnent. Ce sont des hypothèses acceptables
• Critiquer le mécanisme de libération automatique et critiquer l’objectif de l’algorithme ainsi que le modèle du système sont deux choses différentes
• Redlock a été utilisé avec succès dans divers cas d’usage, et avec des timeouts correctement définis, il est difficile de provoquer une condition de concurrence. Définir des timeouts trop courts est une erreur de conception
• Je mets à jour mes connaissances sur le bas niveau et les algorithmes, et j’aimerais construire quelque chose pour le plaisir, mais la plupart des ressources sont soit au niveau jouet, soit extrêmement complexes
• J’implémente un verrouillage distribué avec PostgreSQL : je démarre une transaction, j’obtiens un advisory lock et je garde le verrou tant que la transaction n’est pas libérée
• Je me suis rendu compte que je n’avais pas vérifié l’état de la connexion à la base de données, et qu’il était donc possible d’avoir perdu le verrou si le travail n’était pas lié à la base
• J’ai implémenté un verrouillage distribué avec Deno et Deno KV, qui repose sur FoundationDB
• J’ai étudié Redis, mais j’ai utilisé PostgreSQL pour transformer les requêtes en opérations SET, ce qui a permis de résoudre le problème de correction
• Beaucoup d’ingénieurs n’accordent pas d’importance aux problèmes de correction, alors qu’il existe des cas limites où des messages peuvent être perdus ou arriver dans le mauvais ordre
• Définir un timeout sur le verrou est une bonne idée, et si le client plante, l’OS ou le superviseur libère le verrou
• Quand aucun verrou n’est nécessaire, on peut utiliser un version token pour préserver l’intégrité des données. Une valeur unique comme un UUID peut être utilisée