Ein Artikel wird Ihnen helfen, die Redis-Angelegenheiten gründlich zu verstehen

Dieser Artikel vermittelt Ihnen relevantes Wissen über Redis, das hauptsächlich die relevanten Inhalte zu Transaktionen vorstellt. Es handelt sich im Wesentlichen um eine Sammlung von Befehlen, die die Ausführung mehrerer Befehle gleichzeitig unterstützen Schauen wir es uns nacheinander in der Warteschlange an. Ich hoffe, es wird für alle hilfreich sein.

Empfohlenes Lernen: Redis-Video-Tutorial

Einführung in Redis-Transaktionen

Redis bietet nur einfache Transaktionsfunktionen. Sein Kern besteht aus einer Reihe von Befehlen, die die gleichzeitige Ausführung einer Transaktion unterstützen. Die von anderen Clients übermittelten Befehle werden nicht nacheinander ausgeführt Befehlssequenz dieser Transaktion. Der Ausführungsprozess von Befehlen wird sequentiell ausgeführt, die Atomizität ist jedoch nicht garantiert. Es gibt keine Isolationsstufe wie bei MySQL, und Sie können Daten und andere erweiterte Vorgänge zurücksetzen, nachdem ein Problem auftritt. Dies wird später im Detail analysiert.

Redis grundlegende Transaktionsanweisungen

Redis bietet die folgenden grundlegenden Anweisungen für Transaktionen.

MULTI öffnet eine Transaktion, Redis fügt der Warteschlange nachfolgende Befehle hinzu, ohne sie tatsächlich auszuführen, bis EXEC anschließend verwendet wird, um diese Befehle atomar und sequentiell EXEC auszuführen Führen Sie alle Befehle im Transaktionsblock aus.DISCARDBrechen Sie die Transaktion ab und geben Sie die Ausführung aller Befehle im Transaktionsblock auf.WATCHÜberwachen Sie einen oder mehrere Schlüssel, wenn die Transaktion vorliegt Wenn diese Schlüssel vor der Ausführung durch andere Befehle geändert werden, wird die Transaktion beendet und es werden keine Befehle in der Transaktion ausgeführt. UNWATCH bricht die Überwachung aller Schlüssel durch den WATCHab > Befehl. MULTI开启事务，Redis 会将后续命令加到队列中，而不真正执行它们，直到后续使用EXEC来原子化的顺序执行这些命令 EXEC执行所有事务块内的命令 DISCARD取消事务，放弃执行事务块内所有的命令 WATCH监视一个或多个 key，若事务在执行前，这些 key 被其他命令修改，则事务被终端，不会执行事务中的任何命令 UNWATCH取消 WATCH命令对所有 keys 的监视

一般情况下，一个简单的 Redis 事务主要分为如下几个部分：

执行命令MULTI开启一个事务。 开启事务之后，执行命令的多个命令会依次被放入一个队列，放入成功则会返回QUEUED消息。 执行命令EXEC提交事务，Redis 会依次执行队列中的命令，并依次返回所有命令的结果。（若想放弃提交事务，则执行DISCARD）。

下图简单介绍了下 Redis 事务执行的过程：

实例分析

下面我们来通过一些实际具体例子，来体会下 Redis 中的事务。前面我们也说到 Redis 的事务不是正真的事务，是无法完全满足标准事务的ACID

Allgemeine Situation Nachfolgend ist eine einfache Redis-Transaktion hauptsächlich in die folgenden Teile unterteilt:

Führen Sie den Befehl MULTI aus, um eine Transaktion zu starten. Nachdem die Transaktion gestartet wurde, werden mehrere Befehle zur Ausführung des Befehls nacheinander in eine Warteschlange gestellt. Wenn die Platzierung erfolgreich ist, wird eine QUEUED-Meldung zurückgegeben. Führen Sie den Befehl EXEC aus, um die Transaktion zu übermitteln. Redis führt die Befehle in der Warteschlange nacheinander aus und gibt die Ergebnisse aller Befehle nacheinander zurück. (Wenn Sie auf das Festschreiben der Transaktion verzichten möchten, führen Sie DISCARD aus.)

Die folgende Abbildung stellt kurz den Prozess der Redis-Transaktionsausführung vor:

Beispielanalyse

Lassen Sie uns die Transaktionen in Redis anhand einiger praktischer Beispiele erleben. Wir haben bereits erwähnt, dass Redis-Transaktionen keine echten Transaktionen sind und die ACID-Merkmale von Standardtransaktionen nicht vollständig erfüllen können. Schauen wir uns anhand des folgenden Beispiels an, welche Probleme bei der „Bankrottversion“-Transaktion von Redis auftreten.

[A] Nach normaler Ausführung der Übermittlung

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b 2
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"2"

Nach dem Öffnen der Transaktion werden die übermittelten Befehle zur Warteschlange hinzugefügt (QUEUED). Nach der Ausführung von EXEC werden die Befehle Schritt für Schritt ausgeführt und die Ergebnisse zurückgegeben. Sieht dies den Transaktionsoperationen ähnlich, die wir normalerweise in MySQL verwenden, z. B. „Transaktion starten“ und „Festschreiben“?

[B] Brechen Sie die Transaktion normal ab

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b 2
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> 
127.0.0.1:6379> GET a
(nil)
127.0.0.1:6379> GET b
(nil)

Wenn Sie die Transaktion nach dem Öffnen nicht fortsetzen möchten, verwenden Sie DISCARD zum Abbrechen. Der zuvor übermittelte Befehl wird nicht tatsächlich ausgeführt und der zugehörige Schlüsselwert bleibt unverändert . Dies ähnelt auch MySQL-Transaktionen, ähnlich wie Starttransaktion und Rollback.

[C]Beobachten Sie den Überwachungsschlüssel

-- 线程 1 中执行
127.0.0.1:6379> del a
(integer) 1
127.0.0.1:6379> get a
(nil)
127.0.0.1:6379> SET a 0
OK
127.0.0.1:6379> WATCH a
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
----------------------------------------- 线程 2 中执行
----------------------------------------- 127.0.0.1:6379> SET a 2
----------------------------------------- OK
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> GET a
"2"

Beobachten Sie den Wert von a, bevor Sie die Transaktion starten, und starten Sie dann die Transaktion. Der Wert von a wird in einem anderen Thread festgelegt (SET a 2) und dann wird EXEC ausgeführt, um die Transaktion auszuführen. Das Ergebnis ist Null, was bedeutet, dass die Transaktion nicht ausgeführt wurde. Da sich der Wert von a nach WATCH geändert hat, wurde die Transaktion abgebrochen.

🎜Es ist zu beachten, dass dies nichts mit dem Zeitpunkt zu tun hat, zu dem die Transaktion gestartet wird, und auch nichts mit der Reihenfolge, in der MULTI und ein anderer Thread den Wert von a festlegen. Solange es sich nach WATCH ändert. Unabhängig davon, ob die Transaktion gestartet wurde, wird sie beim Ausführen der Transaktion (EXEC) abgebrochen. 🎜Unter normalen Umständen wird bei der Ausführung von EXEC- und DISCARD-Befehlen standardmäßig UNWATCH ausgeführt. 🎜🎜[D] Syntaxfehler🎜

127.0.0.1:6379> SET a 1
OK
127.0.0.1:6379> SET b 2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 11
QUEUED
127.0.0.1:6379> SETS b 22
(error) ERR unknown command 'SETS'
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"2"

🎜Wenn Redis eine Transaktion startet und ein Syntaxfehler im hinzugefügten Befehl vorliegt, schlägt die Transaktionsübermittlung fehl. In diesem Fall wird keiner der Befehle in der Transaktionswarteschlange ausgeführt. Wie im obigen Beispiel sind die Werte von a und b beide Originalwerte. 🎜Diese Art von Fehlern, die vor EXEC auftreten, wie z. B. Befehlsnamenfehler, Befehlsparameterfehler usw., werden vor der Ausführung von EXEC erkannt. Wenn diese Fehler auftreten, wird daher die Transaktion abgebrochen und alle Befehle in der Transaktion werden abgebrochen nicht umgesetzt werden. (Sieht diese Situation ein bisschen wie ein Rollback aus) 🎜🎜[E] Laufzeitfehler🎜

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET a 1
QUEUED
127.0.0.1:6379> SET b hello
QUEUED
127.0.0.1:6379> INCR b
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
127.0.0.1:6379> GET a
"1"
127.0.0.1:6379> GET b
"hello"

当 Redis 开启一个事务后，添加的命令没有出现前面说的语法错误，但是在运行时检测到了类型错误，导致事务最提交失败（说未完全成功可能更准确点）。此时事务并不会回滚，而是跳过错误命令继续执行。
如上面的例子，未报错的命令值已经修改，a 被设置成了 1，b 被设置为了 hello，但是报错的值未被修改，即 INCR b 类型错误，并未执行，b 的值也没有被再更新。

Redis 事务与 ACID

通过上面的例子，我们已经知道 Redis 的事务和我们通常接触的 MySQL 等关系数据库的事务还有有一定差异的。它不保证原子性。同时 Redis 事务也没有事务隔离级别的概念。下面我们来具体看下 Redis 在 ACID 四个特性中，那些是满足的，那些是不满足的。
事务执行可以分为命令入队（EXEC 执行前）和命令实际执行（EXEC 执行之后）两个阶段。下面我们在分析的时候，很多时候都会分这两种情况来分析。

原子性（A）

上面的实例分析中，[A]，[B]，[C]三种正常的情况，我们可以很明显的看出，是保证了原子性的。
但是一些异常情况下，是不满足原子性的。

如 [D] 所示的情况，客户端发送的命令有语法错误，在命令入队列时 Redis 就判断出来了。等到执行 EXEC 命令时，Redis 就会拒绝执行所有提交的命令，返回事务失败的结果。此种情况下，事务中的所有命令都不会被执行了，是保证了原子性的。 如 [E] 所示的情况，事务操作入队时，命令和操作类型不匹配，此时 Redis 没有检查出错误（这类错误是运行时错误）。等到执行 EXEC 命令后，Redis 实际执行这些命令操作时，就会报错。需要注意的是，虽然 Redis 会对错误的命令报错不执行，但是其余正确的命令会依次执行完。此种情况下，是无法保证原子性的。 在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。此时，如果开启了 AOF 日志，那么只会有部分事务操作被记录到 AOF 日志中。使用redis-check-aof工具检测 AOF 日志文件，可以把未完成的事务操作从 AOF 文件中去除。这样一来，使用 AOF 文件恢复实例后，事务操作不会被再执行，从而保证了原子性。若使用的 RDB 模式，最新的 RDB 快照是在 EXEC 执行之前生成的，使用快照恢复之后，事务中的命令也都没有执行，从而保证了原子性。若 Redis 没有开启持久化，则重启后内存中的数据全部丢失，也就谈不上原子性了。 一致性（C）

一致性指的是事务执行前后，数据符合数据库的定义和要求。这点在 Redis 事务中是满足的，不论是发生语法错误还是运行时错误，错误的命令均不会被执行。

EXEC 执行之前，入队报错（实例分析中的语法错误）

事务会放弃执行，故可以保证一致性。

EXEC 执行之后，实际执行时报错（实例分析中的运行时错误）

错误的命令不会被执行，正确的命令被执行，一致性可以保证。

EXEC 执行时，实例宕机

若 Redis 没有开启持久化，实例宕机重启后，数据都没有了，数据是一致的。
若配置了 RDB 方式，RDB 快照不会在事务执行时执行。所以，若事务执行到一半，实例发生了故障，此时上一次 RDB 快照中不会包含事务所做的修改，而下一次 RDB 快照还没有执行，实例重启后，事务修改的数据会丢失，数据是一致的。若事务已经完成，但新一次的 RDB 快照还没有生成，那事务修改的数据也会丢失，数据也是一致的。
若配置了 AOF 方式。当事务操作还没被记录到 AOF 日志时，实例就发生故障了，使用 AOF 日志恢复后数据是一致的。若事务中的只有部分操作被记录到 AOF 日志，可以使用 redis-check-aof清除事务中已经完成的操作，数据库恢复后数据也是一致的。

隔离性（I） 并发操作在 EXEC 执行前，隔离性需要通过 WATCH 机制来保证 并发操作在 EXEC 命令之后，隔离性可以保证

情况 a 可以参考前面的实例分析 WATCH 命令的使用。
情况 b，由于 Redis 是单线程执行命令，EXEC 命令执行后，Redis 会保证先把事务队列中的所有命令执行完之后再执行之后的命令。

持久性（D）

Wenn Redis die Persistenz nicht aktiviert, werden alle Daten im Speicher gespeichert. Nach dem Neustart gehen die Daten verloren, sodass die Haltbarkeit der Transaktion zu diesem Zeitpunkt nicht garantiert werden kann.
Wenn Redis die Persistenz aktiviert hat, können beim Absturz und Neustart der Instanz dennoch Daten verloren gehen, sodass die Haltbarkeit nicht vollständig garantiert werden kann.
Daher können wir sagen, dass Redis-Transaktionen die Haltbarkeit nicht unbedingt garantieren können und nur in besonderen Fällen eine Haltbarkeit garantiert werden kann.

Warum Redis nach dem Einschalten der Persistenz immer noch Daten verliert, wird der Autor in einem separaten Artikel zu Redis-Persistenz und Master-Slave vorstellen. Hier ist eine kurze Einführung.
Wenn der RDB-Modus konfiguriert ist, stürzt die Redis-Instanz ab, nachdem eine Transaktion ausgeführt wurde, aber bevor der nächste RDB-Snapshot ausgeführt wird, und die Daten gehen verloren.
Wenn der AOF-Modus konfiguriert ist und die drei Konfigurationsoptionen des AOF-Modus Nein sind , everysec, Always kann ebenfalls zu Datenverlust führen.

Zusammenfassend lässt sich sagen, dass die Redis-Transaktion ACID unterstützt:

hat einen gewissen Grad an Atomizität, unterstützt jedoch kein Rollback. Es erfüllt die Konsistenz und Isolation und kann keine Haltbarkeit garantieren. Schauen Sie sich die offizielle Website an Beschreibung:

Was ist mit Rollbacks?

Redis unterstützt keine Rollbacks von Transaktionen, da die Unterstützung von Rollbacks erhebliche Auswirkungen auf die Einfachheit und Leistung von Redis hätte.

Die meisten Situationen, die ein Transaktions-Rollback erfordern, werden durch Programmfehler verursacht. Diese Situation tritt im Allgemeinen in der Entwicklungsumgebung auf und dieser Fehler sollte in der Produktionsumgebung nicht auftreten.

Bei logischen Fehlern sollte beispielsweise 1 addiert werden, das Ergebnis wird jedoch als Addition von 2 geschrieben. Diese Situation kann nicht durch Zurücksetzen gelöst werden.

Redis strebt nach Einfachheit und Effizienz, die Implementierung traditioneller Transaktionen ist jedoch relativ komplex, was der Designidee von Redis widerspricht. Wenn wir die Geschwindigkeit von Redis genießen, können wir nicht mehr davon verlangen.

Empfohlenes Lernen:

Redis-Video-Tutorial

Das obige ist der detaillierte Inhalt vonEin Artikel wird Ihnen helfen, die Redis-Angelegenheiten gründlich zu verstehen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!