Was ist die Aktualisierungsstrategie für die Konsistenz von MySQL-Datenbank und Redis-Cache?

1. Update-Strategie

1 Wenn Daten in Redis vorhanden sind, müssen diese mit dem Wert in der Datenbank übereinstimmen.

2. Wenn in Redis keine Daten vorhanden sind, muss Redis synchron mit dem neuesten Wert in der Datenbank aktualisiert werden.

2. Lese- und Schreibcache

Beim Schreiben in die Datenbank ist es notwendig, dass der Cache und die Daten in der Datenbank synchron sind Um sicherzustellen, dass der Cache und die Daten in der Datenbank konsistent sind, muss die synchrone Direktschreibstrategie sichergestellt werden.

2. Asynchrone langsame Schreibstrategie

In einigen Geschäftsvorgängen dürfen Redis-Daten nach der Aktualisierung von MySQL-Daten nach einem bestimmten Zeitraum synchronisiert werden, z. B. in Logistiksystemen.

Wenn eine ungewöhnliche Situation auftritt, muss die fehlgeschlagene Aktion repariert und mit Rabbitmq oder Kafka neu geschrieben werden.

3. Überprüfen Sie die Sperrstrategie noch einmal.

Wenn mehrere Threads diese Daten gleichzeitig in der Datenbank abfragen, können wir bei der ersten Anforderung eine Mutex-Sperre verwenden, um die Daten abzufragen und zu sperren.

Andere Threads können warten, bis sie die Sperre zu diesem Zeitpunkt nicht mehr erhalten können, darauf warten, dass der erste Thread die Daten abfragt, und sie dann zwischenspeichern.

Der nachfolgende Thread kommt herein und stellt fest, dass bereits ein Cache vorhanden ist, also geht er direkt zum Cache.

public String get(String key){
    // 从Redis缓存中读取
    String value = redisTemplate.get(key);

    if(value != null){
        return value;
    }

    synchronized (RedisTest.class){
        // 重新尝试从Redis缓存中读取
        value = redisTemplate.get(key);
        if(value != null){
            return value;
        }

        // 从MySQL数据库中查询
        value = studentDao.get(key);
        // 写入Redis缓存
        redisTemplate.setnx(key,value,time);
        return value;
    }
}

4. Update-Strategie für Datenbank- und Cache-Konsistenz

1. Aktualisieren Sie zuerst die Datenbank und dann Redis. Nach dem gesunden Menschenverstand sollte dies der Fall sein, oder? Was ist also das Problem in diesem Fall?

Was passiert, wenn vor der Aktualisierung von Redis nach erfolgreicher Aktualisierung der Datenbank eine Ausnahme auftritt?

Die Datenbank stimmt nicht mit den zwischengespeicherten Daten in Redis überein.

2. Aktualisieren Sie zuerst den Cache und dann die Datenbank.

In Multithread-Situationen treten Probleme auf.

Zum Beispiel

Thread 1 aktualisiert Redis = 200;

• Thread 2 aktualisiert Redis = 100;

• Thread 1 aktualisiert MySQL = 200;

• Das Ergebnis ist: Redis=100, MySQL=200; ich werde es löschen!

3. Löschen Sie zuerst den Cache und aktualisieren Sie dann die Datenbank.

• Thread 1 löscht die Redis-Cache-Daten und aktualisiert dann die MySQL-Datenbank.

  Bevor das MySQL-Update abgeschlossen ist, liest Thread 2 jedoch die Cache-Daten , Dies Zu diesem Zeitpunkt wurde die MySQL-Datenbank nicht aktualisiert, und Thread 2 hat den alten Wert auch als Datencache in Redis geschrieben.
Nachdem Thread 1 die MySQL-Daten aktualisiert hatte, wurde er gefunden dass es bereits Daten in Redis gab, diese wurden bereits gelöscht, daher werde ich sie nicht aktualisieren.

Es ist vorbei. .

Verzögertes doppeltes Löschen

Verzögertes doppeltes Löschen kann das oben genannte Problem lösen, solange die Ruhezeit länger ist als die Zeit, die Thread 2 zum Lesen der Daten und zum anschließenden Schreiben in den Cache benötigt, d. h. für den zweiten Cache-Löschvorgang von Thread 1 muss sein Nachdem Thread 2 in den Cache geschrieben hat, kann dadurch sichergestellt werden, dass die Daten im Redis-Cache aktuell sind.

/**
 * 延时双删
 * @autor 哪吒编程
 */
public void deleteRedisData(Student stu){
    // 删除Redis中的缓存数据
    jedis.del(stu);

    // 更新MySQL数据库数据
    studentDao.update(stu);

    // 休息两秒
    try {
        TimeUnit.SECONDS.sleep(2);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    // 删除Redis中的缓存数据
    jedis.del(stu);
}

Das größte Problem bei der verzögerten doppelten Löschung ist der Schlaf. Heutzutage, wenn Effizienz an erster Stelle steht, ist es besser, den Schlaf nicht zu nutzen.

Ich glaube, du bist langsam, auch wenn du nicht schläfst, aber du schläfst trotzdem ein...

4. Zuerst die Datenbank aktualisieren, dann den Cache löschen

Thread 1 zuerst die Datenbank aktualisieren, dann löschen der Redis-Cache;

Thread 2 Eine Anfrage wurde initiiert, bevor Thread 1 den Redis-Cache löschte, und der nicht gelöschte Redis-Cache wurde zu diesem Zeitpunkt nur gelöscht

1. Das Problem besteht immer noch und es geht endlos weiter.
   Wie kann man diese Situation lösen?
2. Führen Sie die Nachrichten-Middleware ein, um den Kampf zu lösen, und überprüfen Sie ihn noch einmal im Detail.

3. Aktualisieren Sie die Datenbank.

Die Datenbank schreibt die Vorgangsinformationen in das Binlog-Protokoll.

Der Abonnent extrahiert den Schlüssel und die Daten fehlgeschlagen;

1. Diese Dateninformationen werden an die Nachrichten-Middleware gesendet.

2. 5 Zuerst die Datenbank und dann den Cache löschen.
   Die Mängel von Methode ① und Methode ② sind zu offensichtlich, um berücksichtigt zu werden;
Methode ③ bereitet immer Kopfzerbrechen;
3. Methode ④ ist eine umfassendere Lösung, erhöht jedoch die Lern- und Wartungskosten, da sie die Nachricht erhöht Middleware.
   5. Funktionsprinzip der MySQL-Master-Slave-Replikation
1 Wenn sich die Daten auf dem Master-Server ändern, werden die Änderungen in die binäre Ereignisprotokolldatei geschrieben

5. 2 das Binärprotokoll auf dem Master-Server innerhalb des Zeitintervalls, um zu erkennen, ob es sich geändert hat. Wenn festgestellt wird, dass sich das binäre Ereignisprotokoll des Master-Servers geändert hat, starten Sie einen E/A-Thread, um das Master-Binärereignisprotokoll anzufordern

3. Gleichzeitig startet der Master-Server einen Dump-Thread für jeden E/A-Thread, um binäre Ereignisprotokolle an ihn zu senden.

6. 4 Der Slave-Server speichert das empfangene binäre Ereignisprotokoll in seinem eigenen lokalen Relay Datei;

   5. Der Salve-Slave-Server startet den SQL-Thread, um das Binärprotokoll aus dem Relay-Protokoll zu lesen und es lokal wiederzugeben, um seine Daten mit dem Hauptserver in Einklang zu bringen. O-Thread und SQL-Thread gehen in den Ruhezustand und warten auf das nächste Mal, wenn sie aktiviert werden.

Das obige ist der detaillierte Inhalt vonWas ist die Aktualisierungsstrategie für die Konsistenz von MySQL-Datenbank und Redis-Cache?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!