Unterstützen Redis-Transaktionen ACID? Im folgenden Artikel erfahren Sie mehr über Redis-Transaktionen, stellen vor, wie Redis-Transaktionen implementiert werden, und sprechen darüber, ob Redis-Transaktionen ACID unterstützen. Ich hoffe, er wird Ihnen hilfreich sein!
Tencent-Interviewer: „Kennen Sie die Transaktionen von Redis? Kann sein Transaktionsmechanismus ACID-Eigenschaften realisieren?“
Cheng Xuyuan: „Ich kratze mir am Kopf, das ... ich weiß, dass Lua-Skript Transaktionen realisieren kann.“ ...“
Tencent-Interviewer: „Okay, geh zurück und warte auf die Benachrichtigung.“
Bruder Ma, ich habe viele Angebote bekommen, aber ich hatte nicht erwartet, dass ich am Ende bei der Frage verloren habe „Wie implementiert Redis Transaktionen?“
Lassen Sie es uns Schritt für Schritt analysieren:
Was ist Transaktions-ACID?
Wie implementiert Redis Transaktionen?
Welche Eigenschaften können Redis-Transaktionen erreichen?
Lua-Skriptimplementierung.
Transaktion ist eine Einheit der Parallelitätskontrolle, die aus einer Abfolge von Vorgängen besteht, die entweder alle oder keine davon ausführen. [Verwandte Empfehlungen: Redis-Video-Tutorial
]„Es ist eine unteilbare Arbeitseinheit.“
Wenn eine Transaktion ausgeführt wird, bietet sie spezielle Attributgarantien: Atomizität: Mehrere Vorgänge einer Transaktion müssen abgeschlossen werden, oder keiner von ihnen darf abgeschlossen werden (ps: Wie erreicht MySQL Atomizität? Willkommen Kommentare im Nachrichtenbereich);Entitätsintegrität (z. B. der Primärschlüssel der Zeile ist vorhanden und eindeutig);
Wie Redis Transaktionen implementiert
EXEC, DISCARD und WATCH Befehle sind die Grundlage für Redis, um Transaktionen zu implementieren. Der Ausführungsprozess einer Redis-Transaktion besteht aus drei Schritten:
Öffnen Sie die Transaktion;, und nachfolgende Befehle werden in die Warteschlange gestellt und zwischengespeichert und nicht tatsächlich ausgeführt. Befehl in die Warteschlange stellen
MULTI
Es ist zu beachten, dass die Anweisungen zwar an den Server gesendet werden, die Redis-Instanz diese Reihe von Anweisungen jedoch nur vorübergehend in einer Befehlswarteschlange speichert und sie nicht sofort ausführt.
Transaktion ausführen oder verwerfen Der Client sendet einen Befehl zum Senden oder Verwerfen der Transaktion an den Server, sodass Redis die im zweiten Schritt gesendeten spezifischen Anweisungen ausführen oder den Warteschlangenbefehl löschen und die Ausführung aufgeben kann .Redis kann die Ausführung von Warteschlangenbefehlen einfach beim Aufruf von EXEC planen.
MitDISCARD
können Sie im zweiten Schritt auch die in der Warteschlange gespeicherten Befehle verwerfen. Redis-TransaktionsfallFühren Sie unseren Beispielcode über die Online-Debugging-Website aus: try.redis.io
Normale Ausführung
Führen Sie einen Transaktionsprozess über MULTI
und EXEC
aus: MULTI
和 EXEC
执行一个事务过程:
# 开启事务 > MULTI OK # 开始定义一些列指令 > SET “公众号:码哥字节” "粉丝 100 万" QUEUED > SET "order" "30" QUEUED > SET "文章数" 666 QUEUED > GET "文章数" QUEUED # 实际执行事务 > EXEC 1) OK 2) OK 3) OK 4) "666"
我们看到每个读写指令执行后的返回结果都是 QUEUED
,表示谢谢操作都被暂存到了命令队列,还没有实际执行。
当执行了 EXEC
命令,就可以看到具体每个指令的响应数据。
放弃事务
通过 MULTI
和 DISCARD
丢弃队列命令:
# 初始化订单数 > SET "order:mobile" 100 OK # 开启事务 > MULTI OK # 订单 - 1 > DECR "order:mobile" QUEUED # 丢弃丢列命令 > DISCARD OK # 数据没有被修改 > GET "order:mobile" "100"
码哥,Redis 的事务能保证 ACID 特性么?
这个问题问得好,我们一起来分析下。
Redis 事务可以一次执行多个命令, 并且带有以下三个重要的保证:
批量指令在执行 EXEC 命令之前会放入队列暂存;
收到 EXEC 命令后进入事务执行,事务中任意命令执行失败,其余的命令依然被执行;
事务执行过程中,其他客户端提交的命令不会插入到当前命令执行的序列中。
原子性
码哥,如果事务执行过程中发生错误了,原子性能保证么?
在事务期间,可能遇到两种命令错误:
EXEC
命令前,发送的指令本身就错误。如下:maxmemory
指令配置内存限制)。EXEC
命令后,命令可能会失败。例如,命令和操作的数据类型不匹配(对 String 类型 的 value 执行了 List 列表操作);EXEC
命令时。 Redis 实例发生了故障导致事务执行失败。EXEC 执行前报错
在命令入队时,Redis 就会报错并且记录下这个错误。
此时,我们还能继续提交命令操作。
等到执行了 EXEC
#开启事务 > MULTI OK #发送事务中的第一个操作,但是Redis不支持该命令,返回报错信息 127.0.0.1:6379> PUT order 6 (error) ERR unknown command `PUT`, with args beginning with: `order`, `6`, #发送事务中的第二个操作,这个操作是正确的命令,Redis把该命令入队 > DECR b:stock QUEUED #实际执行事务,但是之前命令有错误,所以Redis拒绝执行 > EXEC (error) EXECABORT Transaction discarded because of previous errors.Wir sehen, dass das Rückgabeergebnis nach der Ausführung jedes Lese- und Schreibbefehls
QUEUED
ist, was bedeutet, dass die Dankesoperation vorübergehend in der Befehlswarteschlange gespeichert und nicht tatsächlich ausgeführt wurde. Wenn der Befehl EXEC
ausgeführt wird, können Sie die spezifischen Antwortdaten jedes Befehls sehen. Transaktion abbrechen
Warteschlangenbefehl verwerfen durchMULTI
und DISCARD
: rrreeeBruder Ma, können Redis-Transaktionen ACID-Eigenschaften garantieren?
Das ist eine gute Frage, lassen Sie uns sie gemeinsam analysieren.Redis-Transaktionen können mehrere Befehle gleichzeitig ausführen und verfügen über die folgenden drei wichtigen Garantien:
Batch-Anweisungen werden währenddessen ausgeführt EXEC Der Befehl wird zur temporären Speicherung in die Warteschlange gestellt.
Nach Erhalt des EXEC-Befehls wird die Ausführung eines Befehls fehlgeschlagen Der Transaktionsausführungsprozess wird von anderen Clients übermittelt. Der Befehl wird nicht in die Reihenfolge der aktuellen Befehlsausführung eingefügt.
Atomizität
Brother Code: Ist die atomare Leistung garantiert, wenn während der Transaktionsausführung ein Fehler auftritt?Während der Transaktion können zwei Arten von Befehlsfehlern auftreten:
EXEC
ausgeführt wird, ist der Befehl selbst falsch. Wie folgt: maxmemory
zum Konfigurieren des Speicherlimit). Nach der Ausführung des Befehls EXEC
schlägt der Befehl möglicherweise fehl. Beispielsweise stimmen die Datentypen des Befehls und der Operation nicht überein (eine Listenlistenoperation wird für einen Wert vom Typ String ausgeführt).
EXEC
-Befehls einer Transaktion. In der Redis-Instanz ist ein Fehler aufgetreten, der dazu führte, dass die Transaktionsausführung fehlschlug.
EXEC meldet einen Fehler vor der Ausführung
Wenn der Befehl in die Warteschlange gestellt wird, meldet Redis einen Fehler und zeichnet den Fehler auf.
Zu diesem Zeitpunkt können wir weiterhin Befehlsoperationen einreichen.
Nach der Ausführung des Befehls EXEC
wird Redis
. Auf diese Weise werden
alle Befehle in der Transaktion nicht mehr ausgeführt, wodurch die Atomizität sichergestellt wird. 🎜Das Folgende ist ein Beispiel für einen Fehler, der auftritt, wenn ein Befehl in die Warteschlange gestellt wird und zu einem Transaktionsfehler führt: 🎜rrreee🎜🎜EXEC meldet einen Fehler nach der Ausführung🎜🎜🎜Wenn ein Transaktionsvorgang in die Warteschlange gestellt wird, werden die Datentypen des Befehls und Der Vorgang stimmt nicht überein, aber die Redis-Instanz erkennt den Fehler nicht. 🎜🎜Nach der Ausführung des EXEC-Befehls meldet Redis jedoch einen Fehler, wenn diese Anweisungen tatsächlich ausgeführt werden. 🎜🎜🎜Klopfen Sie an die Tafel: Obwohl Redis Fehler für falsche Anweisungen meldet, führt die Transaktion dennoch den richtigen Befehl aus. Zu diesem Zeitpunkt kann die Atomizität der Transaktion nicht garantiert werden! 🎜🎜🎜🎜Bruder Ma, warum unterstützt Redis kein Rollback? 🎜🎜🎜Tatsächlich bietet Redis keinen Rollback-Mechanismus. Obwohl Redis den DISCARD-Befehl bereitstellt. 🎜🎜Dieser Befehl kann jedoch nur verwendet werden, um die Transaktionsausführung aktiv abzubrechen und die temporäre Befehlswarteschlange zu löschen. Er hat keinen Rollback-Effekt. 🎜🎜🎜Bei der Ausführung von EXEC ist ein Fehler aufgetreten🎜🎜🎜Wenn Redis das AOF-Protokoll aktiviert, wird nur ein Teil der Transaktionsvorgänge im AOF-Protokoll aufgezeichnet. 🎜🎜Wir müssen das Redis-Check-Aof-Tool verwenden, um die AOF-Protokolldatei zu überprüfen. Dieses Tool kann nicht abgeschlossene Transaktionsvorgänge aus der AOF-Datei entfernen. 🎜🎜Auf diese Weise wird der Transaktionsvorgang nicht mehr ausgeführt, nachdem wir AOF zum Wiederherstellen der Instanz verwendet haben, wodurch die Atomizität sichergestellt wird. 🎜🎜🎜Einfache Zusammenfassung🎜: 🎜🎜🎜 Ein Fehler wird gemeldet, wenn der Befehl zur Warteschlange hinzugefügt wird, und die Transaktionsausführung wird abgebrochen, um die Atomizität sicherzustellen. 🎜🎜 Es wird kein Fehler gemeldet, wenn der Befehl zur Warteschlange hinzugefügt wird. Bei der tatsächlichen Ausführung wird jedoch ein Fehler gemeldet und die Atomizität ist nicht garantiert. 🎜🎜EXEC-Befehlsausführung Im Falle eines Instanzfehlers kann die Atomizität garantiert werden, wenn das AOF-Protokoll aktiviert ist. 🎜🎜🎜🎜🎜Konsistenz🎜🎜🎜🎜Die Konsistenz wird durch den Zeitpunkt falscher Befehle und Instanzfehler beeinflusst. Entsprechend dem Zeitpunkt der beiden Dimensionen Befehlsfehler und Instanzfehler kann sie in drei Situationen analysiert werden. 🎜🎜🎜EXEC Wenn vor der Ausführung ein Fehler gemeldet wird 🎜🎜🎜, wird die Transaktion abgebrochen, sodass die Konsistenz gewährleistet werden kann. 🎜🎜🎜Nachdem EXEC ausgeführt wurde, wird während der tatsächlichen Ausführung ein Fehler gemeldet. 🎜🎜🎜Fehler werden nicht normal ausgeführt und die Konsistenz kann gewährleistet werden. Wenn 🎜🎜🎜EXEC ausgeführt wird, wird der Instanzfehler 🎜🎜🎜 nach dem Instanzfehler neu gestartet. Dies hängt mit der Methode der Datenwiederherstellung zusammen. Wir werden dies basierend darauf besprechen, ob für die Instanz RDB oder AOF aktiviert ist. 🎜Wenn wir RDB oder AOF nicht aktivieren, sind die Daten nach dem Ausfall der Instanz und dem Neustart verloren und die Datenbank ist konsistent.
Wenn wir einen RDB-Snapshot verwenden, weil der RDB-Snapshot nicht ausgeführt wird, wenn die Transaktion ausgeführt wird.
Also Die Ergebnisse der Transaktionsbefehlsoperation werden nicht im RDB-Snapshot gespeichert Wenn der RDB-Snapshot für die Wiederherstellung verwendet wird, sind auch die Daten in der Datenbank konsistent.
Wenn wir das AOF-Protokoll verwenden und die Instanz fehlschlägt, bevor der Transaktionsvorgang im AOF-Protokoll aufgezeichnet wird, sind die mithilfe des AOF-Protokolls wiederhergestellten Datenbankdaten konsistent.
Wenn nur einige Vorgänge im AOF-Protokoll aufgezeichnet werden, können wir redis-check-aof verwenden, um die abgeschlossenen Vorgänge in der Transaktion zu löschen, und die Datenbank ist nach der Wiederherstellung konsistent.
Isolation
Die Transaktionsausführung kann in zwei Phasen unterteilt werden: Befehlsreihenfolge (bevor der EXEC-Befehl ausgeführt wird) und tatsächliche Befehlsausführung (nachdem der EXEC-Befehl ausgeführt wird).
Während der gleichzeitigen Ausführung analysieren wir diese beiden Phasen in zwei Situationen:
Gleichzeitige Vorgänge werden vor dem Befehl EXEC
ausgeführt, und die Isolierung muss den WATCH
-Mechanismus übergeben Garantie; EXEC
命令前执行,隔离性需要通过 WATCH
机制保证;
并发操作在 EXEC
命令之后,隔离性可以保证。
码哥,什么是 WATCH 机制?
我们重点来看第一种情况:一个事务的 EXEC 命令还没有执行时,事务的命令操作是暂存在命令队列中的。
此时,如果有其它的并发操作,同样的 key 被修改,需要看事务是否使用了 WATCH
EXEC
, Isolation kann garantiert werden.
Bruder Ma, was ist der WATCH-Mechanismus?Konzentrieren wir uns auf die erste Situation: Wenn der EXEC-Befehl einer Transaktion nicht ausgeführt wurde, wird die Befehlsoperation der Transaktion vorübergehend in der Befehlswarteschlange gespeichert.
Wenn es zu diesem Zeitpunkt andere gleichzeitige Vorgänge gibt und derselbe Schlüssel geändert wird, müssen Sie prüfen, ob die Transaktion den WATCH
-Mechanismus verwendet.
Die Funktion des WATCH-Mechanismus besteht darin, die Wertänderungen eines oder mehrerer Schlüssel zu überwachen, bevor eine Transaktion ausgeführt wird. Wenn die Transaktion den EXEC-Befehl zur Ausführung aufruft, prüft der WATCH-Mechanismus zunächst, ob die überwachten Schlüssel von anderen geändert wurden Kunden.
Bei Änderung wird die Transaktionsausführung abgebrochen, um zu verhindern, dass die Isolation der Transaktion zerstört wird.Gleichzeitig kann der Client die Transaktion erneut ausführen. Wenn zu diesem Zeitpunkt kein gleichzeitiger Vorgang zum Ändern der Transaktionsdaten erfolgt, kann die Transaktion normal ausgeführt werden und die Isolation ist ebenfalls gewährleistet.
Kein WATCH
Wenn kein WATCH-Mechanismus vorhanden ist, lesen und schreiben gleichzeitige Vorgänge Daten, bevor der EXEC-Befehl ausgeführt wird.
Wenn EXEC ausgeführt wird, haben sich die Daten geändert, die innerhalb der Transaktion verarbeitet werden sollen, und Redis erreicht keine Isolation zwischen Transaktionen.
Gleichzeitige Vorgänge werden nach EXEC empfangen und ausgeführt. Im zweiten Fall stellt Redis sicher, dass alle Befehle im Befehl ausgeführt werden, da Redis einen einzelnen Thread zum Ausführen von Befehlen verwendet Warteschlange werden zuerst ausgeführt. Führen Sie dann die folgenden Anweisungen aus.
In diesem Fall wird die Isolation der Transaktion durch gleichzeitige Vorgänge nicht aufgehoben.
PersistenzWenn Redis weder RDB noch AOF verwendet, sind die Persistenzeigenschaften der Transaktion sicherlich nicht garantiert.
Wenn Redis den RDB-Modus verwendet, können die durch die Transaktion geänderten Daten nach der Ausführung einer Transaktion, aber vor der Ausführung des nächsten RDB-Snapshots nicht garantiert werden, wenn ein Instanzabsturz auftritt und Daten verloren gehen. Wenn Redis den AOF-Modus übernimmt, kommt es aufgrund der drei Konfigurationsoptionen des AOF-Modus zu Datenverlust: Nein, jede Sekunde und immer.
Die Haltbarkeitseigenschaften von Transaktionen sind also immer noch nicht garantiert.Redis hat einen gewissen Grad an Atomizität, unterstützt jedoch kein Rollback.
Redis verfügt nicht über das Konzept der Konsistenz in ACID. (Oder vielleicht hat Redis dies beim Entwerfen ignoriert)
Redis ist isoliert. Redis übernimmt keine Garantie für die Haltbarkeit. Der Transaktionsmechanismus von
Der Transaktionsmechanismus von Redis kann Konsistenz und Isolation garantieren, aber er kann keine Haltbarkeit garantieren.
🎜🎜Da Redis selbst jedoch eine In-Memory-Datenbank ist, ist Persistenz kein notwendiges Attribut. Wir sind mehr auf die drei Attribute Atomizität, Konsistenz und Isolation bedacht. 🎜🎜Die Situation der Atomizität ist komplizierter. 🎜Wenn die in der Transaktion verwendete Befehlssyntax falsch ist, ist die Atomizität nicht garantiert. In anderen Fällen kann die Transaktion atomar ausgeführt werden. 🎜🎜Weitere Kenntnisse zum Thema Programmierung finden Sie unter: 🎜Einführung in die Programmierung🎜! ! 🎜Das obige ist der detaillierte Inhalt vonWas ist Transaktions-ACID? Können Redis-Transaktionen ACID implementieren?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!