Ursache der Nachfrage
In Geschäftsszenarien mit hoher Parallelität ist die Datenbank in den meisten Fällen das schwächste Glied für den gleichzeitigen Benutzerzugriff. Daher müssen Sie Redis verwenden, um einen Puffervorgang durchzuführen, damit die Anforderung zuerst auf Redis zugreifen kann, anstatt direkt auf Datenbanken wie MySQL zuzugreifen.
Dieses Geschäftsszenario löst hauptsächlich das Problem des Lesens von Daten aus dem Redis-Cache. Geschäftsvorgänge werden im Allgemeinen gemäß dem in der folgenden Abbildung dargestellten Prozess ausgeführt.
Das Lesen des Cache-Schritts stellt im Allgemeinen kein Problem dar, aber sobald es um Datenaktualisierungen geht: Datenbank- und Cache-Aktualisierungen, können Datenkonsistenzprobleme zwischen dem Cache (Redis) und der Datenbank (MySQL) auftreten.
Unabhängig davon, ob Sie zuerst in die MySQL-Datenbank schreiben und dann den Redis-Cache löschen oder zuerst den Cache löschen und dann in die Datenbank schreiben, kann es zu Dateninkonsistenzen kommen. Geben Sie ein Beispiel:
1. Wenn der Redis-Cache gelöscht wird und ein anderer Thread zum Lesen kommt, bevor er Zeit hat, in die Datenbank MySQL zu schreiben, und feststellt, dass der Cache leer ist, liest er die Daten aus der Datenbank und schreibt sie zu diesem Zeitpunkt in den Cache , der Cache enthält schmutzige Daten.
2. Wenn die Bibliothek zuerst geschrieben wird und der Thread, der die Bibliothek schreibt, abstürzt, bevor der Cache gelöscht wird, und der Cache nicht gelöscht wird, kommt es ebenfalls zu Dateninkonsistenzen.
Da Schreiben und Lesen gleichzeitig erfolgen und die Reihenfolge nicht garantiert werden kann, kommt es zu Dateninkonsistenzen zwischen Cache und Datenbank.
Tathagata löst es? Hier sind zwei Lösungen, zunächst einfach und dann schwierig, die auf der Grundlage geschäftlicher und technischer Kosten ausgewählt werden.
Caching- und Datenbankkonsistenzlösungen
1. Die erste Option: Strategie zur verzögerten doppelten Löschung übernehmen
Führen Sie den Vorgang redis.del (Schlüssel) vor und nach dem Schreiben der Bibliothek aus und legen Sie ein angemessenes Zeitlimit fest.
Der Pseudocode lautet wie folgt
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(500);
redis.delKey(key);
}
2. Die konkreten Schritte sind:
1) Zuerst den Cache löschen
2) Schreiben Sie die Datenbank erneut
3) 500 Millisekunden lang schlafen
4) Cache erneut löschen
Wie werden also diese 500 Millisekunden ermittelt und wie lange sollte sie schlafen?
Sie müssen die zeitaufwändige Geschäftslogik zum Lesen von Daten Ihres Projekts bewerten. Der Zweck besteht darin, sicherzustellen, dass die Leseanforderung endet und die Schreibanforderung die durch die Leseanforderung verursachten zwischengespeicherten schmutzigen Daten löschen kann.
Natürlich muss diese Strategie auch die zeitaufwändige Synchronisierung zwischen Redis und Datenbank-Master-Slave berücksichtigen. Die letzte Ruhezeit zum Schreiben von Daten: Fügen Sie der Zeit, die zum Lesen der Datengeschäftslogik benötigt wird, einige hundert Millisekunden hinzu. Beispiel: 1 Sekunde schlafen.
3.Legen Sie die Cache-Ablaufzeit fest
Theoretisch ist das Festlegen einer Ablaufzeit für den Cache eine Lösung, um letztendliche Konsistenz sicherzustellen. Alle Schreibvorgänge unterliegen der Datenbank, solange die Cache-Ablaufzeit erreicht ist. Nachfolgende Leseanforderungen lesen natürlich neue Werte aus der Datenbank und füllen den Cache auf.
4. Nachteile dieses Plans
Durch die Kombination der Doppellöschstrategie + Cache-Timeout-Einstellung besteht das schlimmste Szenario darin, dass die Daten innerhalb des Timeout-Zeitraums inkonsistent sind und sich auch die Zeit zum Schreiben von Anforderungen erhöht.
2. Die zweite Lösung: asynchroner Update-Cache (Synchronisationsmechanismus basierend auf dem Abonnieren von Binlog)
1. Technische Gesamtidee:
Inkrementeller Abonnementverbrauch von MySQL Binlog + Nachrichtenwarteschlange + inkrementelle Datenaktualisierung auf Redis
1) Lesen Sie Redis: Heiße Daten befinden sich grundsätzlich in Redis
2) MySQL schreiben: Hinzufügen, Löschen und Ändern sind alles Vorgänge in MySQL
3) Redis-Daten aktualisieren: MySQ-Datenoperations-Binlog zur Aktualisierung auf Redis
2.Redis-Update
1) Datenoperationen sind hauptsächlich in zwei Teile unterteilt:
Eine davon ist das volle Volumen (alle Daten auf einmal auf Redis schreiben)
Eine davon ist inkrementell (Echtzeitaktualisierung)
Hier geht es um Inkrementierung, die sich auf das Aktualisieren, Einfügen und Löschen von Änderungsdaten von MySQL bezieht.
2) Analysieren Sie das Binlog nach dem Lesen und verwenden Sie die Nachrichtenwarteschlange, um die Redis-Cache-Daten jeder Station zu übertragen und zu aktualisieren.
Auf diese Weise können Binlog-bezogene Nachrichten an Redis gesendet werden, sobald in MySQL neue Schreib-, Aktualisierungs-, Lösch- und andere Vorgänge ausgeführt werden, und Redis aktualisiert Redis basierend auf den Datensätzen im Binlog.
Tatsächlich ist dieser Mechanismus dem Master-Slave-Sicherungsmechanismus von MySQL sehr ähnlich, da die Master-Slave-Sicherung von MySQL auch Datenkonsistenz über Binlog erreicht.
Hier können Sie Canal (ein Open-Source-Framework von Alibaba) in Kombination verwenden, über das Sie MySQLs Binlog abonnieren können. Canal imitiert die Sicherungsanforderung der MySQL-Slave-Datenbank, sodass die Datenaktualisierung von Redis den gleichen Effekt erzielt.
Natürlich können Sie für das Nachrichten-Push-Tool hier auch andere Drittanbieter verwenden: Kafka, RabbitMQ usw., um Push-Updates für Redis zu implementieren.
Das obige ist der detaillierte Inhalt vonRedis-Cache und MySQL-Datenkonsistenzmethoden. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
