Warum muss ein einzelner Redis-Thread gesperrt werden?

Mein persönliches Verständnis ist, dass Redis zwar Single-Threaded ist, aber von mehreren Clients gleichzeitig aufgerufen werden kann und jeder Client einen Thread hat. Es besteht Konkurrenz zwischen Client-Zugriffen.

Da mehrere Clients gleichzeitig vorhanden sind, muss die Atomizität des Vorgangs gewährleistet sein. Wenn es beispielsweise um Abbuchungen von Bankkarten geht, müssen die Einholung des Restbetrags, die Beurteilung, der Abzug und die Rückbuchung eine Transaktion darstellen, andernfalls kann es zu Fehlern kommen.

Im Fall der herkömmlichen eigenständigen Anwendungsbereitstellung können Java-Parallelitätssperren wie ReentrantLcok oder synchronisiert zur gegenseitigen Ausschlusskontrolle verwendet werden. Aufgrund der Anforderungen der Geschäftsentwicklung wurde das ursprüngliche Einzelmaschinen-Bereitstellungssystem jedoch nach und nach auf mehreren Maschinen und mehreren JVMs bereitgestellt, um Dienste gleichzeitig bereitzustellen, was die Strategie der Parallelitätskontrollsperre in der ursprünglichen Einzelmaschinen-Bereitstellung ungültig machte Für dieses Problem ist ein JVM-übergreifender gegenseitiger Ausschlussmechanismus erforderlich, um den Zugriff auf gemeinsam genutzte Ressourcen zu steuern. Dies ist das Problem, das verteilte Sperren lösen möchten. (Empfohlenes Lernen: Redis-Video-Tutorial)

Implementierungsbedingungen für verteilte Sperren

1. Gegenseitige Exklusivität, dasselbe wie bei einer Einzelanwendung notwendig, um sicherzustellen, dass immer nur ein Client die Sperre hält

2. Zuverlässigkeit, die Stabilität des Systems muss gewährleistet sein und es darf kein Deadlock auftreten

3. Konsistenz muss die Sperre sein garantiert Es kann nur von der Person entsperrt werden, die es gesperrt hat, und die Sperre von A kann nicht von Benutzer B entsperrt werden

Verschiedene Personen, die verteilte Sperren in Redis implementieren, können unterschiedliche Implementierungslogiken haben.

In einer verteilten Umgebung war das Thema Datenkonsistenz schon immer ein wichtiges Thema, unterscheidet sich jedoch von der Situation eines einzelnen Prozesses. Der größte Unterschied zwischen verteilten und eigenständigen Situationen besteht darin, dass es sich nicht um Multithreads, sondern um Multiprozesse handelt. Da Multithreads den Heap-Speicher gemeinsam nutzen können, können sie einfach den Speicher als Markierungsspeicherort verwenden. Die Prozesse befinden sich möglicherweise nicht einmal auf derselben physischen Maschine, daher muss das Tag an einem Ort gespeichert werden, an dem alle Prozesse es sehen können.

Ein häufiges Flash-Sale-Szenario besteht darin, dass mehrere Instanzen des Bestellservices bereitgestellt werden. Wenn beispielsweise 4 Flash-Sale-Artikel vorhanden sind, kauft der erste Benutzer 3 Artikel und der zweite Benutzer 2 Artikel. Idealerweise kann der erste Benutzer erfolgreich kaufen und der zweite Benutzer wird darüber informiert, dass der Kauf fehlgeschlagen ist, und umgekehrt . Was tatsächlich passieren kann, ist, dass beide Benutzer einen Lagerbestand von 4 erhalten und der erste Benutzer 3 kauft. Bevor der Lagerbestand aktualisiert wird, gibt der zweite Benutzer eine Bestellung für 2 Artikel auf und aktualisiert den Lagerbestand auf 2, was zu einem Fehler führt.

Übliche Sperrschemata sind wie folgt:

Implementieren verteilter Sperren basierend auf der Datenbank

Implementieren verteilter Sperren basierend auf dem Cache, z. B. Redis

Implementieren verteilter Sperren basierend auf Zookeeper

Weitere technische Artikel zu Redis finden Sie in der Spalte Erste Schritte-Tutorial zur Verwendung der Redis-Datenbank, um mehr zu erfahren!

Das obige ist der detaillierte Inhalt vonWarum muss ein einzelner Redis-Thread gesperrt werden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!