Verrous distribués et baux de leader : expiration, jetons de barrière et ce qu'un verrou ne peut pas promettre

Ce que c'est

Un verrou distribué est un bail : un client acquiert le droit exclusif sur un nom pour une durée limitée et doit le renouveler avant expiration. La documentation Kubernetes (citée) décrit les objets Lease du groupe d'API coordination.k8s.io, utilisés pour les battements de cœur des nœuds et l'élection de leader des composants du plan de contrôle. Redis documente Redlock (cité) comme un algorithme de verrouillage multi-instances proposé, invite à son analyse, et, dans son avertissement sur la cohérence, indique que des jetons de barrière devraient être mis en œuvre et que Redis n'utilise pas d'horloge monotone pour l'expiration des clés.

L'analyse de Kleppmann (citée) pose le point central : un client peut se mettre en pause (ramasse-miettes, défauts de page, contention CPU, paquet retardé) après avoir acquis le bail, le bail expire, un second client l'acquiert, et le premier client reprend et écrit comme s'il détenait encore le verrou. Aucun service de verrouillage ne peut empêcher cela à lui seul. La correction consiste en un jeton de barrière, un nombre qui augmente à chaque octroi du verrou, envoyé avec chaque écriture vers la ressource protégée, laquelle rejette toute écriture portant un jeton inférieur à celui qu'elle a déjà vu. Le zxid de ZooKeeper ou la version d'un znode peuvent servir d'un tel jeton ; Kleppmann note que Redlock ne dispose d'aucun mécanisme pour en générer un.

Pourquoi c'est important

Kleppmann distingue les verrous d'efficacité (éviter de refaire deux fois un même travail coûteux ; un doublon occasionnel est inoffensif) des verrous de correction (un doublon corrompt des données ou facture deux fois). Les équipes déploient souvent le premier type et s'y fient comme s'il s'agissait du second.

Comment l'appliquer

• Décider de quel type de verrou on a besoin. Pour l'efficacité, un simple magasin de verrous avec une durée de vie (TTL) et un jeton de propriétaire à la libération suffit.
• Pour la correction, obtenir du service de verrouillage un jeton strictement croissant (la révision d'un magasin de consensus, une séquence de base de données mise à jour dans la même transaction) et faire vérifier ce jeton par la ressource : une colonne de barrière avec un UPDATE ... SET fence = $held WHERE fence <= $held conditionnel (zéro ligne mise à jour signifie que le bail a été perdu), ou une API de stockage avec écritures conditionnelles.
• Fixer l'intervalle de renouvellement nettement en dessous de la durée du bail, et arrêter le travail immédiatement en cas d'échec du renouvellement ; ne pas « terminer d'abord l'élément en cours ».
• Ne libérer qu'avec le jeton détenu, afin qu'un détenteur expiré ne puisse pas libérer le bail du successeur.
• Préférer rendre le travail idempotent plutôt que de le verrouiller ; un verrou ne fait alors que réduire l'effort gaspillé.

Pièges

Les durées de bail reposent sur des hypothèses d'horloge murale quant à la durée pendant laquelle un processus peut se mettre en pause, et ces pauses n'ont pas de borne supérieure. Un verrou qui protège une ressource sans vérification de jeton est une indication, pas une garantie. Un exécuteur cron singleton dont « une seule instance s'exécute » est imposé par un verrou a quand même besoin de tâches idempotentes.