Heim >Datenbank >Redis >Ursachenanalyse: verzögertes doppeltes Löschen des Redis-Cache

Ursachenanalyse: verzögertes doppeltes Löschen des Redis-Cache

WBOY
WBOYnach vorne
2022-08-24 17:34:203239Durchsuche

Empfohlenes Lernen: Redis-Video-Tutorial

Warum wird der Cache gelöscht statt aktualisiert?

Wenn es sich um ein Update handelt und ein verteiltes Transaktionsproblem vorliegt, wird der Cache möglicherweise geändert und die Datenbankänderung schlägt möglicherweise fehl. Wenn Sie nur den Cache löschen, ruft die nächste Abfrage die Daten direkt aus der Datenbank ab, selbst wenn die Datenbankänderung fehlschlägt, und es werden keine fehlerhaften Daten angezeigt.

Was ist eine verzögerte doppelte Löschung?

Das heißt, beim Hinzufügen, Löschen oder Ändern einer Entitätsklasse muss der Cache der Entitätsklasse geleert werden. Die Löschposition liegt vor und nach der Datenbankbetriebsmethode.

Übernehmen Sie die Methode des Widerspruchsbeweises

Löschen Sie nur zuerst



Ursachenanalyse: verzögertes doppeltes Löschen des Redis-Cache

Löschen Sie erst später

Ursachenanalyse: verzögertes doppeltes Löschen des Redis-Cache

Fazit

Daher kann geschlossen werden, dass es bei beiden Vorlöschungen Probleme gibt und Nachlöschung. Daher wird die Strategie des verzögerten doppelten Löschens übernommen

Denkpunkt 2: Warum verzögert es sich?Es ist immer noch ein Beweis durch Widerspruch. Die Situation in der folgenden Abbildung zeigt die Situation, in der der alte Cache nach dem doppelten Löschen noch vorhanden ist. Die Verzögerung dient dazu, sicherzustellen, dass die Cache-Änderungsvorgänge anderer Transaktionen abgeschlossen wurden, bevor die Datenbank geändert wird -> Cache leeren.

Ursachenanalyse: verzögertes doppeltes Löschen des Redis-Cache

Ergänzung: Warum sollten wir das doppelte Löschen verzögern, um die Cache-Konsistenz sicherzustellen: Dies soll sicherstellen, dass dies während des Intervalls zwischen der Änderung der Datenbankdaten und dem Löschen der Redis-Daten gewährleistet ist Daten sind in Redis nicht vorhanden. Wenn die Datenbankdaten ohne diese Löschung geändert wurden, können alte Daten weiterhin von Redis gelesen werden, was zu Dateninkonsistenzen führt.

Der zweite Löschvorgang erfolgt nach der Änderung der Datenbankdaten. Diesmal müssen die Daten zwischen der ersten Redis-Löschung und der Änderung der Datenbankdaten erneut gelöscht werden ist eine Anfrage, dann werden die alten Daten erneut in Redis zwischengespeichert, aber die Daten in der Datenbank werden als nächstes geändert. Wenn sie dieses Mal nicht gelöscht werden, bleiben die alten Daten in der Datenbank bestehen redis. Warum müssen Sie also das Löschen von Redis um einen bestimmten Zeitraum verzögern, nachdem die Datenbank das zweite Mal geändert wurde?

Um auf das vorherige Lesen der Datenbank zu warten, warten Sie, bis die Daten in den Cache geschrieben wurden, und löschen Sie schließlich die schmutzigen Daten, sodass die Zeit gekommen ist, die Daten von der Datenbank an den Server zu senden + Cache-Schreiben

  • Aber beim verzögerten Doppellöschen ist die Verzögerungszeit sehr schwer zu bestimmen, daher wird das verzögerte Doppellöschen nicht empfohlen
  • Nach umfassenden Überlegungen gibt es nach dem Löschen des Caches auch dann, wenn die Datenbank zuerst geändert wird Es wird einen bestimmten Zeitraum geben, in dem die alten Daten gelesen werden, was normalerweise tolerierbar ist.
  • Solange der Cache rechtzeitig gelöscht wird, können andere Threads den neuesten Wert lesen.
  • Um sicherzustellen, dass der Cache gelöscht wird, können Sie gleichzeitig mit mq sicherstellen, dass der Cache gelöscht wird.

Wenn die Nachricht nicht wiederholt in mq verbraucht wird, wird sie an andere übergeben Verbraucher zum Verzehr (der Cache wird gelöscht) Ursachenanalyse: verzögertes doppeltes Löschen des Redis-Cache

Empfohlenes Lernen:

Redis-Video-Tutorial

Das obige ist der detaillierte Inhalt vonUrsachenanalyse: verzögertes doppeltes Löschen des Redis-Cache. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:jb51.net. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen