Learn more about transactions in Redis

This article will give you a detailed understanding of transactions in Redis. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to everyone.

【Related recommendations: Redis video tutorial】

Related commands

Note:

------MULTI,EXEC,DISCARD is the explicit common command to open and control transactions, which can be compared to BEGAIN,COMMIT## in relational database #,ROLLBACK (In fact, the gap is huge);

------

WATCH command is used to solve transaction concurrency The resulting non-repeatable read and phantom read problems (simply understood as locking the Key);

are used to explicitly start and control a transaction. They allow a set of commands to be executed in one step . And provides two important guarantees:

All commands in the transaction will be serialized and executed in order. During the execution of a Redis transaction, no request issued by another client will occur. This ensures that the
• command queue is executed as a single atomic operation.
The commands in the queue are either all processed or ignored. The EXEC command triggers the execution of all commands in the transaction, so when the client loses connection to the server in the context of a transaction,
• if it occurs before the MULTI command is called, no
• commands are executed ;
If the EXEC command is called before this, all
• commands will be executed.

append-only file) to write transactions to disk using an additional write operation. If there is a downtime, process crash, etc., you can use the redis-check-aof tool to repair the append-only file, so that the service can start normally and resume some operations.

MULTI command to explicitly open the Redis transaction. This command always responds with OK. At this time the user can issue multiple commands, Redis will not execute these commands, but queue them . EXECAfter being called, all commands will be executed. Calling DISCARD can clear the commands queue in the transaction and exit the transaction .

The following example atomically increments the keys foo and bar.

• >MULTI
  OK
  >INCR foo
  QUEUED
  >INCR bar
  QUEUED
  >EXEC
  1）（整数）1
  2）（整数）1

  Copy after login

EXEC returns an array, where each element is a single command in the transaction The return results are in the same order as the order in which the commands are issued. When a Redis connection is in the context of a MULTI request, all commands will be replied with the string QUEUED ( sent as a status reply from the perspective of the Redis protocol ), And queued in Command Queue. Only when EXEC is called, the queued commands will be executed, and then there will be real return results.

During a transaction, you may encounter two command errors:

• In An error occurred before calling the EXEC command (COMMAND failed to queue).
For example, the command may have
• syntax errors (wrong number of parameters, wrong command name...);
or there may be
• some Key conditions , such as insufficient memory (if the server has memory limits using the maxmemory directive).

The client will detect the first error before calling EXEC. Reply by checking the status of the queued command (***Note: This refers to the status reply of the queued , not the execution result* **), if the command responds with QUEUED, it is queued correctly, otherwise Redis will return an error. If an error occurs while queuing a command, most clients will abort the transaction and clear the command queue . However:

Before
• Redis 2.6.5, in this case, after the EXEC command is called, the client will execute a subset of the command ( successfully queued commands) while ignoring previous errors.
Starting from
• Redis 2.6.5, the server will remember errors that occurred during the accumulation of commands, and will refuse to execute when the EXEC command is called transaction and return these errors while automatically clearing the command queue.
An example is as follows:

>MULTI
+OK
>INCR a b c
-ERR wrong number of arguments for 'incr' command

Copy after login

This is due to a syntax error in the

INCR command and will be detected before calling EXEC out, and terminate the transaction (version2.6.5).

• An error occurred after calling the EXEC command.
For example, performing an operation on a
• key using the wrong value (such as calling List# on a String value ##Operation)

EXECErrors that occur after command execution will not be treated specially:Even if some commands in the transaction are executed If it fails, other commands will still be executed normally. <ul><li>示例如下：</li></ul><div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:js;toolbar:false;">&gt;MULTI +OK &gt;SET a 3 +QUEUED &gt;LPOP a +QUEUED &gt;EXEC *2 +OK -ERR Operation against a key holding the wrong kind of value</pre><div class="contentsignin">Copy after login</div></div><blockquote><ul><li><code>EXEC返回一个包含两个元素的字符串数组，一个元素是OK，另一个是-ERR……。

Redis事务不支持Rollback（重点）

事实上Redis命令在事务执行时可能会失败，但仍会继续执行剩余命令而不是Rollback（事务回滚）。如果你使用过关系数据库，这种情况可能会让你感到很奇怪。然而针对这种情况具备很好的解释：

• Redis命令可能会执行失败，仅仅是由于错误的语法被调用（命令排队时检测不出来的错误），或者使用错误的数据类型操作某个Key： 这意味着，实际上失败的命令都是编程错误造成的，都是开发中能够被检测出来的，生产环境中不应该存在。（这番话，彻底甩锅，“都是你们自己编程错误，与我们无关”。）
• 由于不必支持Rollback,Redis内部简洁并且更加高效。

“如果错误就是发生了呢？”这是一个反对Redis观点的争论。然而应该指出的是，通常情况下，回滚并不能挽救编程错误。鉴于没有人能够挽救程序员的错误，并且Redis命令失败所需的错误类型不太可能进入生产环境，所以我们选择了不支持错误回滚（Rollback）这种更简单快捷的方法。

清除命令队列

DISCARD被用来中止事务。事务中的所有命令将不会被执行,连接将恢复正常状态。

> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"

更多编程相关知识，请访问：编程视频！！

The above is the detailed content of Learn more about transactions in Redis. For more information, please follow other related articles on the PHP Chinese website!