Related command introduction:
(Learning video sharing: redis video tutorial)
Note:
------MULTI, EXEC, DISCARD are common commands to explicitly start and control transactions, which can be compared to BEGAIN, COMMIT, ROLLBACK in relational databases (in fact, the gap Very large);
------The use of the WATCH command is to solve the problem of non-repeatable reading and phantom reading caused by transaction concurrency (simply understood as locking the Key);
RedisTransaction
MULTI, EXEC, DISCARD and WATCH are the basis of Redis transaction. 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. Therefore, when the client loses the connection to the server in the transaction context, if it occurs before the MULTI command is called, no commands are executed; if the EXEC command is called before this, all commands are executed. All commands are 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 start the Redis transaction. This command always responds with OK. At this point the user can issue multiple commands, and Redis will not execute these commands, but queue them. After EXEC is 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
As can be seen from the above command execution, EXEC returns an array, in which each element is the return result of a single command in the transaction, and the order is the same as the order in which the command was 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 the command queue. Only when EXEC is called, the queued commands will be executed, and the real result will be returned at this time.
Errors in Transactions
During a transaction, two kinds of command errors may be encountered:
An error occurred before calling the EXEC command (COMMAND queuing failed). For example, the command may have syntax errors (wrong number of parameters, wrong command name...); or there may be certain critical 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. By checking the status reply of the queued command (***Note: this refers to the queued status reply, not the execution result***), if the command responds with QUEUED, it has been 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 was called, the client would execute a subset of the commands (the ones that were successfully queued) and ignore previous errors. Starting from Redis 2.6.5, the server will remember errors that occurred during the accumulation of commands. When the EXEC command is called, it will refuse to execute the 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
This is due to a syntax error in the INCR command, which will be detected before calling EXEC and terminate the transaction (version2.6.5).
An error occurred after calling the EXEC command. For example, using an incorrect value to perform an operation on a key (such as calling a List operation on a String value)
Errors that occur after the EXEC command is executed will not be treated specially: even if some commands in the transaction fail to execute , other commands will still be executed normally.
The example is as follows:
>MULTI +OK >SET a 3 +QUEUED >LPOP a +QUEUED >EXEC *2 +OK -ERR Operation against a key holding the wrong kind of value
EXEC returns a string array containing two elements, one element is OK, the other is -ERR…. Whether errors can be properly fed back to users depends on the implementation of the client library (such as Spring-data-redis.redisTemplate). It should be noted that even if the command fails, all other commands in the queue will be processed - Redis will not stop the processing of the command.
Redis transactions do not support Rollback (emphasis)
In fact, Redis commands may fail during transaction execution, but the remaining commands will continue to be executed instead of Rollback (transaction rollback). If you have used relational databases, this situation may seem strange to you. However, there is a good explanation for this situation:
Redis命令可能会执行失败，仅仅是由于错误的语法被调用（命令排队时检测不出来的错误），或者使用错误的数据类型操作某个Key： 这意味着，实际上失败的命令都是编程错误造成的，都是开发中能够被检测出来的，生产环境中不应该存在。（这番话，彻底甩锅，“都是你们自己编程错误，与我们无关”。）由于不必支持Rollback,Redis内部简洁并且更加高效。
“如果错误就是发生了呢？”这是一个反对Redis观点的争论。然而应该指出的是，通常情况下，回滚并不能挽救编程错误。鉴于没有人能够挽救程序员的错误，并且Redis命令失败所需的错误类型不太可能进入生产环境，所以我们选择了不支持错误回滚（Rollback）这种更简单快捷的方法。
清除命令队列
DISCARD被用来中止事务。事务中的所有命令将不会被执行,连接将恢复正常状态。
> SET foo 1 OK > MULTI OK > INCR foo QUEUED > DISCARD OK > GET foo "1"
相关推荐：redis数据库教程
The above is the detailed content of Redis Pit Prevention Guide - Transactions. For more information, please follow other related articles on the PHP Chinese website!