Analyse des von PHP und Redis implementierten pessimistischen Sperrmechanismus

In diesem Artikel wird hauptsächlich der von PHP + Redis implementierte pessimistische Sperrmechanismus vorgestellt, der Redis-Sperrmechanismus, das optimistische Sperren, das pessimistische Sperren und andere Konzepte kurz vorgestellt und die zugehörigen Betriebstechniken des von PHP + Redis implementierten pessimistischen Sperrens im Formular analysiert von Beispielen. Freunde können darauf verweisen

Dieser Artikel beschreibt die von PHP+Redis implementierte pessimistische Sperre als Beispiel. Teilen Sie es als Referenz mit allen. Die Details lauten wie folgt:

Schließmechanismus

Die häufig verwendeten Schlösser sind in optimistische Schlösser und unterteilt Als Hintergrundwissen zu pessimistischen Schlössern wird in diesem Artikel eine kurze Einführung in diese beiden Arten von Schlössern gegeben.

Optimistic Lock

Sehen wir uns zunächst die Erklärung in der Baidu-Enzyklopädie an: Die meisten davon basieren auf der Datenversion ( Version ) Aufnahmemechanismus. Was ist eine Datenversion? Das heißt, den Daten eine Versionskennung hinzuzufügen. In Versionslösungen, die auf Datenbanktabellen basieren, wird dies normalerweise durch Hinzufügen eines „Version“-Felds zur Datenbanktabelle erreicht. Beim Auslesen der Daten wird auch diese Versionsnummer ausgelesen und bei einer späteren Aktualisierung wird diese Versionsnummer um eins erhöht. Zu diesem Zeitpunkt werden die Versionsdaten der übermittelten Daten mit den aktuellen Versionsinformationen des entsprechenden Datensatzes in der Datenbanktabelle verglichen. Wenn die Versionsnummer der übermittelten Daten größer als die aktuelle Versionsnummer der Datenbanktabelle ist aktualisiert, andernfalls werden sie als abgelaufene Daten betrachtet.

Eigentlich ist es, um es ganz klar auszudrücken, so, als gäbe es in einem Fitnessstudio nur ein Laufband, und am Eingang des Fitnessstudios steht ein Nummernautomat. Jeder, der das Fitnessstudio betritt, muss sich vorher eine Nummer besorgen Sie können eintreten. Wenn sich jemand auf dem Laufband befindet, wärmen Sie sich auf und trinken Sie Wasser. Überprüfen Sie, ob die aktuell auf dem Laufband angezeigte Nummer angezeigt wird (die Nummer der letzten Person, die das Laufband verwendet hat). Wenn das Laufband kleiner ist als das, das Sie halten, bedeutet dies, dass die Nummer überschritten wurde. In Wirklichkeit wissen wir alle, dass wir entweder gehen oder neu anordnen müssen, aber wir können nicht springen in der Warteschlange Das Gleiche gilt im System und es wird normalerweise ein Fehler zurückgegeben.

Pessimistisches Schloss

Schauen wir uns in ähnlicher Weise die Erklärung der Baidu-Enzyklopädie an: Es weist starke exklusive und exklusive Eigenschaften auf. Es bezieht sich auf eine konservative Haltung gegenüber der Änderung von Daten durch die Außenwelt (einschließlich anderer aktueller Transaktionen des Systems und der Transaktionsverarbeitung von externen Systemen). Daher werden die Daten während des gesamten Datenverarbeitungsprozesses in einem gesperrten Zustand gehalten. Die Implementierung pessimistischer Sperren basiert häufig auf dem von der Datenbank bereitgestellten Sperrmechanismus (nur der von der Datenbankschicht bereitgestellte Sperrmechanismus kann die Exklusivität des Datenzugriffs wirklich garantieren. Andernfalls gibt es keinen Sperrmechanismus, selbst wenn er in diesem System implementiert ist um sicherzustellen, dass das externe System die Daten nicht verändert.

Dann ist es, in der gleichen populären Erklärung, immer noch das Fitnessstudio. Diesmal ist kein Warteschlangenautomat an der Tür erforderlich, sondern es wird ein Schlüssel (nur einer) aufgehängt. Jeder, der eintreten möchte, muss diesen Schlüssel erhalten. Wer den Schlüssel erhält, kann eintreten, sei es zum Aufwärmen oder zum Trinken. Du kannst immer noch rennen, bis er herauskommt und den Schlüssel wieder an die Wand hängt, du kannst um den nächsten kämpfen und erst wenn du ihn hast, kannst du wieder hineingehen. Es klingt etwas unmenschlich, daher Pessimistische Sperren eignen sich besser für Szenarien mit starker Konsistenz, aber die Effizienz ist relativ gering, insbesondere ist die Leseparallelität gering. Optimistisches Sperren eignet sich für Szenarien mit mehr Lesevorgängen und weniger Schreibvorgängen sowie weniger Parallelitätskonflikten.

Hintergrund

Lassen Sie mich zunächst über den Entwicklungshintergrund dieses Artikels sprechen, damit jeder verstehen kann, warum er pessimistisch ist Welches Schloss verwendet wird und was im Artikel Detaillierter Entwurf des Schlosses steht.

Aufgabenverteilungssystem: Es gibt eine große Anzahl von Aufgaben (Artikeln) im Aufgabenpool (MySQL), die jetzt Benutzerunterstützung bei der Bearbeitung erfordern. Die grundlegenden Systemanforderungen sind wie folgt (vereinfachte Version):

1. Benutzer, die an Aufgaben in der Kategorie interessiert sind, werden an den Benutzereditor weitergeleitet.
2. Nachdem der Benutzer eine Aufgabe bearbeitet und übermittelt hat, wird nur eine Aufgabe gesendet wird dem Benutzer jeweils zugewiesen
4. Wenn der Benutzer eine Aufgabe länger als eine bestimmte Zeitspanne in Anspruch nimmt, wird die Aufgabe automatisch freigegeben und in den Aufgabenpool aufgenommen und wieder in Umlauf gebracht ;
Es gibt zwei Ziele:

1. Eine Aufgabe kann nur von einem Benutzer gleichzeitig gehalten werden.

2 von Benutzern Seit langem besessen und kann nicht freigegeben werden.

Ideen

Aufgrund der großen Systemparallelität und der häufigen Schreibvorgänge kann die Auswahl pessimistischer Sperren zur Steuerung jeder Aufgabe nur von einem empfangen werden Benutzer gleichzeitig. Die Hauptideen sind wie folgt:

1. Finden Sie einige zuweisbare Aufgaben in einer bestimmten Reihenfolge als Kandidaten-Push-Aufgabe Vergleichen Sie die Kandidaten. Senden Sie die zu sperrende Aufgabe an den Benutzer und ändern Sie den entsprechenden Aufgabenstatus.

5 wurde beansprucht, wiederholen Sie 2-5, bis der Push erfolgreich ist. Erreichen

Hier stellen wir nur den Sperrimplementierungsmechanismus vor und überspringen den Rest der Geschäftslogik. Da der Sperrvorgang nicht zerlegt werden sollte, was häufig als atomare Operation bezeichnet wird, wird die Setnx-Operation in Redis als Sperrmethode ausgewählt.

Die vereinfachte Version des Codes lautet wie folgt:

function lock($strMutex, $intTimeout) {
  $objRedis = new Redis();
  //使用setnx原子型操作加锁
  $intRet  = $objRedis->setnx($strMutex, 1);
  if ($intRet) {
    //设置过期时间，防止死任务的出现
    $objRedis->expire($strMutex, $intTimeout);
    return true;
  }
  return false;
}

Es gibt ein Problem mit diesem Code, das heißt, setnx ist erfolgreich, aber Ablauf schlägt fehl, was möglicherweise eine Dead-Mission-Situation darstellt. Eine übliche Möglichkeit, dieses Problem zu lösen, ist die Verwendung der incr-Methode anstelle von setnx wie folgt:

function lock($strMutex, $intTimeout, $intMaxTimes = 0) {
  $objRedis = new Redis();
  //使用incr原子型操作加锁
  $intRet  = $objRedis->incr($strMutex);
  if ($intRet === 1) {
    //设置过期时间，防止死任务的出现
    $objRedis->expire($strMutex, $intTimeout);
    return true;
  }
  if ($intMaxTimes > 0 && $intRet >= $intMaxTimes && $objRedis->ttl($strMutex) === -1) {
    //当设置了最大加锁次数时，如果尝试加锁次数大于最大加锁次数并且无过期时间则强制解锁
    $objRedis->del($strMutex);
  }
  return false;
}

Dieser Code übergibt $intMaxTimes Um sicherzustellen, dass die Entsperrung auch dann erzwungen werden kann, wenn der Ablauf nicht erfolgreich ist, wird sichergestellt, dass keine toten Aufgaben im System vorhanden sind.

Gibt es einen besseren Weg?

Tatsächlich ist die Set-Operation in Redis mit Setnx kompatibel und unterstützt das Festlegen der Ablaufzeit.

function lock($strMutex, $intTimeout) {
  $objRedis = new Redis();
  //使用setnx操作加锁，同时设置过期时间
  $strRet  = $objRedis->set($strMutex, 1, 'ex', $intTimeout, 'nx');
  if ($strRet === 'OK') {
    return true;
  }
  return false;
}

Ich denke, diese Methode ist derzeit die beste, aber warum haben Sie diese Methode nicht direkt eingeführt, anstatt zuerst die Incr-Methode vorzustellen? Tatsächlich können aufmerksame Schüler erkennen, dass der obige Aspekt zwei fettgedruckte Wörter „allgemein“ enthält. Der Grund, warum ich das sage, ist, dass die Set-Methode nur mehrere Parameter aus der Version redis2.6.12 unterstützt.

Das Niveau ist begrenzt, Korrekturen sind willkommen~

Das Obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, dass er für das Lernen aller hilfreich ist die chinesische PHP-Website!

Verwandte Empfehlungen:

Zusammenfassung der Verwendung variabler Funktionen in PHP

Nicht rekursive Methode zur Implementierung von PHP-Bäumen

So verwenden Sie PHP, um die echte IP des Benutzer-Clients zu erhalten

Das obige ist der detaillierte Inhalt vonAnalyse des von PHP und Redis implementierten pessimistischen Sperrmechanismus. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!