|
DISCARD |
Clear the commands | queue in the transaction and restore the connection state. If WATCH was called before, Release the Keys in Monitoringalways OK.
|
|
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);
RedisTransactionMULTI, EXEC, DISCARD and WATCH are the basis of Redis transaction. 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.
At the same time, redis uses AOF (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.
Usage Use the 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 .
As can be seen from the above command execution, 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.
Errors in Transactions
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:
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><pre class="brush:js;toolbar:false;">>MULTI
+OK
>SET a 3
+QUEUED
>LPOP a
+QUEUED
>EXEC
*2
+OK
-ERR Operation against a key holding the wrong kind of value</pre><blockquote><ul>
<li>
<code>EXEC返回一个包含两个元素的字符串数组，一个元素是OK，另一个是-ERR……。
能否将错误合理的反馈给用户这取决于客户端library(如：Spring-data-redis.redisTemplate)的自身实现。
需要注意的是，即使命令失败，队列中的所有其他命令也会被处理----Redis不会停止命令的处理。
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"
更多编程相关知识，请访问：编程视频！！
