Ich bin dumm
Nun, wann immer wir in unserem lokalen System arbeiten, funktioniert alles wie Butter. Deshalb nennen wir „Keinen besseren Ort als 127.0.0.1“, aber WACHEN SIE MIT DER REALITÄT AUF
Nun, in der Produktion laufen die Dinge nicht immer wie erwartet. Meistens, wenn Sie mehrere Instanzen Ihrer Anwendung ausführen.
? Wie Sie sehen können, wenn mehrere Instanzen unserer Anwendung ausgeführt werden und unser Client beispielsweise eine Anfrage stellt, um einen Benutzer als bezahlten Benutzer in unserer Datenbank zu markieren.
- Der Kunde wird unseren Server anfordern
- Anfrage geht bei unserem Load Balancer ein
- Und eine der Instanzen erhält die Anfrage und stellt eine Schreibabfrage in unsere Datenbank
Es scheint in Ordnung zu sein, oder? Bis jetzt kein Problem.
Nun ja, bis jetzt gibt es kein Problem. Aber was ist, wenn wir eine Geschäftslogik schreiben möchten wie:-
- Benutzer aus der Datenbank abrufen
- Überprüfen Sie, ob der Benutzer ein kostenloser Benutzer ist oder bereits bezahlt hat
- Wenn kostenlos, markieren Sie es als bezahlt und speichern Sie es in der Datenbank
- Wenn bezahlt, senden Sie in der Antwort „Bereits bezahlt“.
⚡️ Wie wir wissen (angenommen, wir verwenden hier MySQL), sind MySQL-Datenbanken ACID-kompatibel, was bedeutet, dass jede Abfrage atomar und isoliert ist. Das bedeutet, dass die MySQL-Abfrage auf atomare Weise ausgeführt wird und entweder erfolgreich ist oder fehlschlägt. Aber es wird zwischendurch nicht aufhören.
? Aber hier gibt es ein Problem. Denken Sie, denken Sie....
- Schritt 1: Wir rufen den Benutzer ab (Atomic-Transaktion)
- Schritt 2: Ausführen einiger Geschäftslogik im Code
- Schritt 3: Aktualisieren des MySQL-Eintrags, wenn der Benutzer nicht bezahlt hat (Atomic-Transaktion)
Was passiert, wenn in Schritt 2 eine weitere Anfrage zum Stornieren der Zahlung eingeht und dann diese Abfrage zuerst ausgeführt wird und den Benutzer als kostenlos markiert, dann Schritt 3 ausgeführt wird und der Benutzer als bezahlt markiert wird.
?? Hurra, der Benutzer hat Zugriff auf unsere Produkte erhalten, ohne dafür zu bezahlen.
Sperren
✅ Hier kommt der Retter, Locks
? Lock ist eine Struktur, die es jeweils nur einem Thread ermöglicht, einen kritischen Abschnitt (Codeblock, auf den nicht mehrere Worker, d. h. Threads) zugreifen dürfen, zu betreten
Daher werden wir die Sperre vor dem Abschluss des Vorgangs aktivieren und nach Abschluss des Vorgangs freigeben:-
- Schritt 0: try-acquire() lock
- Schritt 1: Bei Erwerb holen wir den Benutzer ab (atomare Transaktion)
- Schritt 2: Ausführen einiger Geschäftslogik im Code
- Schritt 3: Aktualisieren des MySQL-Eintrags, wenn der Benutzer nicht bezahlt hat (Atomic-Transaktion)
- Schritt 4: release() die Sperre
? Problem
Hier kommt nun das Problem: Wenn wir eine Datenstruktur mit Speichersperre oder eine speicherbasierte Sperre verwenden, ist diese für eine Instanz für unsere Anwendung geeignet. Was ist mit den anderen Instanzen, die denselben Code ausführen und in der Datenbank aktualisieren?
Nun, hier kommt das Konzept des verteilten Sperrens
? Verteiltes Sperren
Hier fungiert Lock als zentraler Dienst. Wenn eine Instanz unseres Dienstes die Sperre erhält, können andere nicht denselben Schlüssel verwenden.
Welcher Schlüssel könnte hier im Zahlungsdienst sein?
? Für einen Benutzer, der eine Zahlung vornimmt, könnte der Schlüssel die Kombination aus = „PAYMENT_“ + Benutzer-ID + Betrag
sein
Und dies wird pro Benutzer einzigartig sein. Und dieser Schlüssel bleibt derselbe, wenn der Benutzer eine Zahlung vornimmt oder die Zahlung storniert. Wenn also eine andere Aktion ausgeführt wird, kann sie nicht fortgesetzt werden, da beide Aktionen versuchen, denselben Schlüssel zu verwenden.
? Was zum Teufel ist Schlüssel, Sperre erwerben, Sperre freigeben? Und vor allem: Wie wird Redis verwendet?
? Verwenden von Redis zur Implementierung von Distributed Locking
Verwendung einer einzelnen Instanz von Redis:-
Aber hier sind die wenigen Probleme mit einer einzelnen Redis-Instanz:-
- Eine einzelne Instanz kann fehlschlagen und die erworbene Sperre wird möglicherweise nicht freigegeben
- Wenn zwei Instanzen verwendet werden (Master-Replikat), erhält ein Client die Sperre für eine Instanz
- Der Master muss zur Synchronisierung mit dem Replikat kommunizieren. Diese Kommunikation selbst ist eine asynchrone Kommunikation
? Wenn also eine Sperre auf dem Master erworben wird und während der Kommunikation mit dem Replikat der Master ausfällt, bevor die Synchronisierung mit dem Replikat erfolgt. Das Replikat wird zum Master, wobei die Sperre für denselben Schlüssel verfügbar ist, der zuvor auf dem Master erworben wurde.
Zwei Instanzen unserer Dienste können die Sperre auf Redis erhalten, selbst wenn zwei Instanzen vorhanden sind (Master-Replikat).
Verwendung des Redlock-Algorithmus: –
Erwerb einer Sperre: – Wir werden versuchen, eine Sperre für mehrere Redis-Instanzen mit Sperrenablaufzeit zu erlangen
Validierung der Sperre: – Die Sperre gilt als erworben, wenn große Redis-Instanzen eine Sperre für den Client erworben haben
Sperre aufheben: – Beim Aufheben der Sperre heben alle Instanzen die Sperre auf
Und ja, das ist es.
❤️ Vielen Dank fürs Lesen und abonnieren Sie unseren Newsletter für weitere Artikel dieser Art:- https://www.serversidedigest.com/
Für weitere Informationen:-
- Jedis in Java:- https://redis.io/docs/latest/develop/connect/clients/java/jedis/
- Redis-Client in Golang: – https://github.com/redis/go-redis
Das obige ist der detaillierte Inhalt vonSo implementieren Sie eine verteilte Sperre mit Redis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
