Verteilte Sperren und Leader-Leases: Ablauf, Fencing-Token und was eine Sperre nicht versprechen kann

Worum es geht

Eine verteilte Sperre ist ein Lease: Ein Client erwirbt das ausschliessliche Recht an einem Namen für eine begrenzte Zeit und muss es vor dem Ablauf erneuern. Die zitierte Kubernetes-Dokumentation beschreibt Lease-Objekte in der API-Gruppe coordination.k8s.io, die für Node-Heartbeats und die Leader-Wahl von Control-Plane-Komponenten verwendet werden. Redis dokumentiert Redlock (zitiert) als vorgeschlagenen Multi-Instanz-Sperralgorithmus, lädt zu dessen Analyse ein und sagt in seinem Konsistenz-Disclaimer, dass Fencing-Token implementiert werden sollten und dass Redis für den Ablauf von Schlüsseln keine monotone Uhr verwendet.

Kleppmanns Analyse (zitiert) macht den zentralen Punkt deutlich: Ein Client kann pausieren (Garbage Collection, Page Faults, CPU-Konkurrenz, ein verzögertes Paket), nachdem er den Lease erworben hat, der Lease läuft ab, ein zweiter Client erwirbt ihn, und der erste Client setzt fort und schreibt, als hielte er die Sperre noch. Kein Sperrdienst kann dies aus eigener Kraft verhindern. Die Korrektur ist ein Fencing-Token, eine Zahl, die bei jeder Vergabe der Sperre steigt, mit jedem Schreibzugriff auf die geschützte Ressource gesendet wird und die jeden Schreibzugriff mit einem niedrigeren Token ablehnt als einem bereits gesehenen. Die zxid oder Znode-Version von ZooKeeper kann als solches Token dienen; Kleppmann merkt an, dass Redlock über keine Möglichkeit verfügt, ein solches zu erzeugen.

Warum es wichtig ist

Kleppmann unterscheidet Sperren für Effizienz (dieselbe teure Arbeit nicht zweimal ausführen; ein gelegentliches Duplikat ist harmlos) von Sperren für Korrektheit (ein Duplikat verfälscht Daten oder belastet doppelt). Teams setzen oft die erste Art ein und verlassen sich darauf wie auf die zweite.

So wird es angewendet

• Entscheiden, welche Art von Sperre gebraucht wird. Für Effizienz genügt ein einzelner Sperrspeicher mit einer TTL und einem Eigentümer-Token bei der Freigabe.
• Für Korrektheit ein monoton steigendes Token vom Sperrdienst beziehen (die Revision eines Konsensspeichers, eine in derselben Transaktion aktualisierte Datenbanksequenz) und die Ressource es prüfen lassen: eine Fence-Spalte mit einem bedingten UPDATE ... SET fence = $held WHERE fence <= $held (null aktualisierte Zeilen bedeutet, der Lease wurde verloren), oder eine Speicher-API mit bedingten Schreibzugriffen.
• Das Erneuerungsintervall deutlich unter der Lease-Dauer ansetzen und die Arbeit sofort stoppen, wenn eine Erneuerung fehlschlägt; nicht «den aktuellen Eintrag zuerst fertig machen».
• Nur mit dem gehaltenen Token freigeben, damit ein abgelaufener Inhaber nicht den Lease des Nachfolgers freigeben kann.
• Bevorzugt die Arbeit idempotent machen, statt sie zu sperren; eine Sperre verringert dann nur vergeudeten Aufwand.

Stolpersteine

Lease-Dauern sind Realzeit-Annahmen darüber, wie lange ein Prozess pausieren darf, und Pausen haben keine Obergrenze. Eine Sperre, die eine Ressource ohne Token-Prüfung schützt, ist ein Hinweis, keine Garantie. Ein Singleton-Cron-Runner, bei dem «nur eine Instanz läuft» per Sperre durchgesetzt wird, braucht weiterhin idempotente Jobs.