Wie man verteiltes Locking implementiert (2016)

Verteilte Sperren implementieren

• Auf der Redis-Website wurde der Redlock-Algorithmus entdeckt, der behauptet, fehlertolerante verteilte Sperren auf Redis zu implementieren.
• Es existieren bereits mehrere unabhängige Implementierungen von Redlock, und da sich möglicherweise Menschen auf diesen Algorithmus verlassen, hat der Autor beschlossen, seine Notizen zu teilen.
• Redis ist nützlich, um flüchtige und sich schnell ändernde Daten zwischen Servern zu teilen, aber es ist bedenklich, dies auf den Bereich der Datenverwaltung auszuweiten, in dem starke Konsistenz und Dauerhaftigkeit gefordert sind.

Zweck von Sperren

• Sperren dienen dazu sicherzustellen, dass von mehreren Knoten nur einer eine bestimmte Aufgabe ausführt.
• Wenn Sperren aus Effizienzgründen verwendet werden, ist die Nutzung einer einzelnen Redis-Instanz möglicherweise die bessere Wahl.
• Wenn Sperren für Korrektheit verwendet werden, ist Redlock nicht geeignet.

Ressourcen mit Sperren schützen

• Sperren in verteilten Systemen unterscheiden sich von Mutexen in Multithread-Anwendungen.
• Sie verhindern, dass ein anderer Client denselben Vorgang ausführt, während ein Client eine Datei liest, sie verändert und anschließend wieder zurückschreibt.

Sichere Sperren mit Fencing implementieren

• Sichere Sperren lassen sich implementieren, indem Fencing-Tokens erzeugt und in Schreibanfragen einbezogen werden.
• Redlock ist nicht sicher, da es keine Fencing-Tokens erzeugen kann.

Zeit für Konsens verwenden

• Redlock macht im Gegensatz zu Algorithmen im asynchronen Modell viele Annahmen über die Zeit.
• Wenn sich Systemuhren ungewöhnlich verhalten, kann das Ablaufen von Schlüsseln früher oder später als erwartet erfolgen.

Die Zeitannahmen von Redlock brechen

• Redlock setzt ein synchrones Systemmodell voraus und funktioniert nur korrekt, wenn Netzwerklatenz, Prozesspausen und Uhrfehler begrenzt sind.
• Fälle wie der 90-sekündige Paketverzögerungsvorfall bei GitHub können die Sicherheit von Redlock gefährden.

Fazit

• Redlock ist für auf Effizienz optimierte Sperren unnötig schwergewichtig und für Situationen, die Korrektheit erfordern, nicht sicher genug.
• Wenn Sperren für Korrektheit erforderlich sind, empfiehlt sich der Einsatz eines geeigneten Konsenssystems wie ZooKeeper.

Zusammenfassung von GN⁺

• Der Redlock-Algorithmus liefert eine wichtige Diskussion über die Implementierung von Sperren in verteilten Systemen.
• Dieser Artikel hebt Zeitannahmen und Sicherheitsprobleme in verteilten Systemen hervor und erklärt die Bedeutung einer korrekten Sperren-Implementierung.
• Er empfiehlt alternative Systeme wie ZooKeeper und hilft dabei, die Komplexität verteilter Systeme zu verstehen.

[GN⁺]

Hacker-News-Kommentare

• Ich habe verteilte Sperren mit Temporal implementiert, und bisher funktioniert das gut. Mithilfe der Funktionen von Temporal ist die Implementierung verteilter Sperren einfach.
• In den Blog-Kommentaren habe ich angemerkt, dass ein wichtiger Punkt des Algorithmus übersehen wurde, und darauf hingewiesen, dass seine Ablehnung auf einem schwachen Punkt beruht.
• Mit modernen Computern und APIs kann man ungefähre Zeitwartezeiten umsetzen, GC-Pausen sind begrenzt, und monotone Uhren funktionieren. Das ist eine akzeptable Annahme.
• Den Auto-Release-Mechanismus zu kritisieren und die Ziele sowie das Systemmodell des Algorithmus zu kritisieren, sind zwei verschiedene Dinge.
• Redlock wurde in verschiedenen Anwendungsfällen erfolgreich eingesetzt, und wenn Timeouts sinnvoll gesetzt werden, lassen sich Race Conditions nur schwer auslösen. Sehr kurze Timeouts sind ein Designfehler.
• Ich frische gerade mein Wissen zu Low-Level-Themen und Algorithmen auf und würde gern zum Spaß etwas bauen, aber die meisten Materialien sind entweder nur Spielzeugniveau oder extrem komplex.
• Ich implementiere verteilte Sperren mit PostgreSQL, starte eine Transaktion, hole eine Advisory Lock und halte den Sperrzustand, bis die Transaktion freigegeben wird.
• Mir wurde klar, dass ich den Zustand der Datenbankverbindung nicht geprüft hatte; bei Aufgaben, die nichts mit der Datenbank zu tun haben, könnte ich die Sperre verloren haben.
• Ich habe verteilte Sperren mit Deno und Deno KV implementiert; es basiert auf FoundationDB.
• Ich habe mir Redis angesehen, aber das Korrektheitsproblem gelöst, indem ich PostgreSQL verwendet und die Anfrage in eine SET-Operation umgewandelt habe.
• Vielen Ingenieuren sind Korrektheitsprobleme nicht wichtig, und es gibt Randfälle, in denen Nachrichten verloren gehen oder in der falschen Reihenfolge ankommen können.
• Für Sperren ein Timeout zu setzen, ist eine gute Idee; wenn der Client abstürzt, geben das Betriebssystem oder ein Supervisor die Sperre frei.
• Wenn keine Sperre nötig ist, kann man Versions-Token verwenden, um die Datenintegrität zu wahren. Es können eindeutige Werte wie UUIDs verwendet werden.