So verwenden Sie Redis zur Lösung hoher Parallelität

NoSQL

Abkürzung für Not Only SQL. NoSQL wurde vorgeschlagen, um die Unfähigkeit traditioneller RDBMS zu lösen, bestimmte Probleme zu bewältigen.

Das heißt, nicht relationale Datenbanken garantieren nicht die ACID-Eigenschaften relationaler Daten. Sie sind im Hinblick auf die Erweiterung im Allgemeinen nicht sehr einfach zu implementieren.

Redis

redis ist ein typischer Vertreter von NoSQL und eine unverzichtbare Technologie für aktuelle Internetunternehmen.

Redis verwendet hauptsächlich Hash-Tabellen, um die Speicherung von Schlüssel-Wert-Paaren zu implementieren. Meistens wird es direkt in Form eines Caches verwendet, sodass die Anforderung nicht direkt auf die Festplatte zugreift, sodass die Effizienz sehr gut ist und die Anforderungen kleiner und mittlerer Unternehmen vollständig erfüllt werden können.

Gemeinsame Datentypen

• String-String

• Hash

• Listenliste

• Sets-Sets

• Sortierset

Die Häufigkeit der Verwendung von Strings und Hashes wird höher sein. Jeder Typ verfügt über einen eigenen Betriebsbefehl. Dies ist nichts anderes als das Hinzufügen, Löschen, Ändern und Überprüfen. Ich werde die spezifischen Befehle später sortieren.

Pain Points

Wenn in Webanwendungen viele Anfragen gleichzeitig auftreten, kann es zu Fehlern beim Lesen und Speichern von Daten kommen, d. h. zu fehlerhaften Lesevorgängen und der Generierung fehlerhafter Daten.

Bei verteilten Projekten treten mehr Probleme auf.

Denken

Während der Parallelität besteht das Wesentliche darin, dass mehrere Anfragen gleichzeitig eingehen und nicht korrekt verarbeitet werden können.

Sie können alle Anfragen in eine Warteschlange stellen, sodass die Anfragen einzeln eingehen können, um die Geschäftslogik auszuführen. Die Verwendung von Nachrichtenwarteschlangen ist derzeit eine praktikable Lösung. Ich werde beim nächsten Mal einen Artikel zum Umgang mit Nachrichtenwarteschlangen mit hoher Parallelität verfassen. Eine andere Methode besteht darin, Parallelität direkt in Serialisierung umzuwandeln, aber diese Lösung ist Nicht geeignet an Orten mit strengen Effizienzanforderungen oder in verteilten Projekten. Dies führt dazu, dass Redis zur Implementierung verteilter Sperren verwendet wird, um Parallelitätsprobleme zu lösen.

Verteilte Sperre

In verteilten Projekten wird eine eindeutige, universelle und effiziente Kennung verwendet, um das Sperren und Entsperren darzustellen.

Redis ist sehr einfach zu implementieren. Das heißt, ob ein Schlüssel vorhanden ist oder nicht, zeigt an, ob er gesperrt oder entsperrt ist.

Nehmen Sie den String-Typ als Beispiel:

Integer stock = goodsMapper.getStock();
if (stock > 0) {
    stock =- 1;
    goodsMapper.updateStock(stock);
}

Das Obige ist der einfachste Pseudocode zum sofortigen Beenden. Wir versuchen, Redis zu verwenden, um verteilte Sperren zu implementieren.

// 这里是错误代码，只是一个思考过程，请耐心看完哦
String key = "REDIS_DISTRIBUTION_LOCKER"; // 分布式锁名称
String value = jedisUtils.get(key);
if (value != null) { // 未上锁
    // wingzingliu
    jedisUtils.set(key, 1); // 上锁
    Integer stock = goodsMapper.getStock();
    if (stock > 0) {
        stock =- 1;
        goodsMapper.updateStock(stock);
        jedisUtils.del(key); // 释放锁
    }
}

Möglicherweise liegt ein Problem mit dem obigen Code vor. Das heißt, wenn mehrere Anforderungen gleichzeitig eingehen und mehrere Anforderungen zu einem bestimmten Zeitpunkt alle den Wert leer erhalten, gibt Thread A das Wenn ein und geht zu // Wingzingliu, es ist noch nicht gesperrt, es kommen auch andere Anfragen herein, sodass schmutzige Daten angezeigt werden.

Das Codeproblem besteht hier darin, dass das Problem der Atomizität nicht berücksichtigt wird.

Wir müssen also einen setNx-Befehl von redis verwenden, der im Wesentlichen einen Wert festlegt, aber dies ist eine atomare Operation. Nach der Ausführung wird zurückgegeben, ob die Einstellung erfolgreich ist.

redis> SETNX job "programmer"    # job 设置成功
(integer) 1
 
redis> SETNX job "code-farmer"   # 尝试覆盖 job ，失败
(integer) 0
 
redis> GET job                   # 没有被覆盖
"programmer"

Konzentrieren Sie sich darauf, dass ein Wert fehlschlägt und 0 zurückgibt. Unser Code wird also wie folgt umgewandelt.

// 这里是错误代码，只是一个思考过程，请耐心看完哦
String key = "REDIS_DISTRIBUTION_LOCKER"; // 分布式锁名称
Long result = jedisUtils.setNx(key, 1);
if (result > 0) { // 上锁成功，进入逻辑
    // wingzingliu1
    Integer stock = goodsMapper.getStock();
    if (stock > 0) {
        stock =- 1;
        goodsMapper.updateStock(stock);
 
        System.out.println("购买成功!");
    } else {
        System.out.println("没有库存了!");
    }
    // wingzingliu2
    jedisUtils.del(key); // 释放锁
}

Mit dem oben Gesagten können wir die Atomizität sicherstellen und sie in der richtigen Reihenfolge verarbeiten.

Aber es gibt noch ein weiteres verstecktes Problem: Nachdem ein Thread die Sperre erfolgreich ausgeführt hat, löst das Programm eine Ausnahme zwischen Wingzingliu1 und Wingzingliu2 aus. Dann wird das Programm beendet und die Sperre kann nicht aufgehoben werden, und andere Threads können nicht eintreten.

Die Lösung besteht darin, einen Try-Catch-Finally-Block hinzuzufügen und die Sperre schließlich freizugeben.

Aber was ist, wenn es eine Ausfallzeit ist? Nachdem die Sperre gesperrt wurde, stürzt der Computer ab und der endgültige Inhalt wird immer noch nicht ausgeführt. Ohne manuelle Verarbeitung können keine weiteren Threads eingegeben werden.

Daher wird die Ablaufzeit von Redis eingeführt und zu einem bestimmten Zeitpunkt automatisch entsperrt.

// 这里是不够完善的代码，请耐心看完哦
try {
    String key = "REDIS_DISTRIBUTION_LOCKER"; // 分布式锁名称
    Long result = jedisUtils.setNx(key, 1, 30); // 假设处理逻辑需要20s左右，设置了30秒自动过期
    if (result > 0) { // 上锁成功，进入逻辑
        Integer stock = goodsMapper.getStock();
        if (stock > 0) {
            stock =- 1;
            goodsMapper.updateStock(stock);
 
            System.out.println("购买成功!");
        } else {
            System.out.println("没有库存了!");
        }
    }
} catch (Exception e) {
    
} finally {
    jedisUtils.del(key); // 释放锁
}

Das Obige ist eine relativ vollständige verteilte Sperre, aber es gibt immer noch einen kleinen Fehler. Es wird davon ausgegangen, dass die Verarbeitung einer bestimmten Anforderung A sehr langsam ist, aber es dauert 35 Sekunden, wenn die Sperre abläuft Weitere Anfragen werden natürlich eingehen.

Dies führt nicht nur zu einer gleichzeitigen Ausführung, sondern gibt die Sperre auch weiterhin frei, nachdem Anforderung A verarbeitet wurde, wodurch die Sperre tatsächlich an den nächsten Thread übergeben wird. Analog dazu wird die gesamte Parallelitätskontrolle durcheinander gebracht.

Theoretisch können Sie eine längere Schlüsselablaufzeit festlegen, aber das ist nicht die beste Lösung. Hier kommt ein Konzept: Leben einsperren.

Das Schloss verlängert die Lebensdauer

Wie der Name schon sagt, verlängert das Schloss die Lebensdauer. Die Implementierung besteht darin, die Sperrzeit zu verlängern, wenn die Sperre bald abläuft. Gehen Sie davon aus, dass eine 30-Sekunden-Sperre verwendet wird und alle 10 Sekunden überprüft wird, ob die Sperre noch besteht. Wenn die Sperre weiterhin besteht, behalten Sie die Sperre 30 Sekunden lang bei. Dadurch wird das oben beschriebene mögliche Problem vermieden.

Hier kommt eine geplante Aufgabe zum Einsatz, die periodisch aufgerufen werden kann.

Erweiterung

Der gerade für den Schlüssel festgelegte Wert ist 1. Tatsächlich kann die Anforderungs-ID zum Speichern verwendet werden, sodass Sie wissen, von welcher Anforderung die Sperre stammt, und das Entsperren der Sperre für andere Threads vermeiden können beim Entriegeln. Es kann vom Frontend übergeben oder vom Server basierend auf bestimmten Regeln generiert werden.

Das obige ist der detaillierte Inhalt vonSo verwenden Sie Redis zur Lösung hoher Parallelität. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!