Shulou(Shulou.com)06/01 Report--

This article will explain in detail the introduction and use of transaction commands in redis. The content of the article is of high quality, so I share it for your reference. I hope you can get something after reading this article.

I. Overview:

The essence of a Redis transaction is a collection of commands. Transactions support the execution of multiple commands at a time, and all commands in a transaction are serialized. During transaction execution, commands in the queue are serialized sequentially, and command requests submitted by other clients are not inserted into the transaction execution command sequence.

To sum up: a redis transaction is an one-time, sequential, exclusive execution of a series of commands in a queue.

2. List of related commands:

Command prototype time complexity command description return value

M

U

L

T

I

Used to mark the beginning of a transaction, subsequent commands are stored in the command queue and will not be executed by the atom until the EXEC is executed. Always return OK

E

X

E

C

Executes all commands in the command queue within a transaction while restoring the current connection state to the normal state, that is, the non-transactional state. If the WATCH command is executed in a transaction, the EXEC command can execute all commands in the transaction queue only if the Keys monitored by WATCH has not been modified, otherwise EXEC will discard all commands in the current transaction. Atomically returns the results of each command in a transaction. If WATCH is used in a transaction, EXEC returns an NULL-multi-bulk reply once the transaction is abandoned.

D

I

S

C

A

R

D

Rolls back all commands in the transaction queue while restoring the current connection state to the normal state, that is, the non-transactional state. If the WATCH command is used, it will UNWATCH all Keys. Always return OK.

W

A

T

C

H

K

E

Y

[key...]

O (1) before the MULTI command is executed, the Keys to be monitored can be specified, but before the EXEC is executed, if the monitored Keys is modified, EXEC will abandon the execution of all commands in the transaction queue. Always return OK.

U

N

W

A

T

C

H

O (1) cancels the Keys specified for monitoring in the current transaction, and if the EXEC or DISCARD command is executed, there is no need to execute the command manually, because after that, all monitored Keys in the transaction will be automatically cancelled. Always return OK.

3. Examples of commands:

1. The transaction is executed normally:

# client tools that execute Redis under the Shell command line.

/ > redis-cli

# start a new transaction on the current connection.

Redis 127.0.0.1 6379 > multiOK

# execute the first command in the transaction. From the return result of the command, you can see that the command is not executed immediately, but is stored in the command queue of the transaction.

Redis 127.0.0.1 6379 > incr t1QUEUED

# execute a new command, which can be seen from the result that it is also stored in the command queue of the transaction.

Redis 127.0.0.1 6379 > incr t2QUEUED

# execute all the commands in the transaction command queue, and you can see from the results that the results of the commands in the queue are returned.

Redis 127.0.0.1 redis 6379 > exec1) (integer) 12) (integer) 1

2. There are failed commands in the transaction:

# start a new transaction.

Redis 127.0.0.1 6379 > multiOK

# set the value of key a to 3 of type string.

Redis 127.0.0.1 3QUEUED 6379 > set a 3QUEUED

# pops the element from the header of the value associated with key a. Because the value is of type string and the lpop command can only be used for type List, the command will fail when executing the exec command.

Redis 127.0.0.1 6379 > lpop aQUEUED

# set the value of key a to string 4 again.

Redis 127.0.0.1 4QUEUED 6379 > set a 4QUEUED

# gets the value of key a to confirm whether the value was set successfully by the second set command in the transaction.

Redis 127.0.0.1 6379 > get aQUEUED

# as can be seen from the results, the second command in the transaction, lpop, failed, while the subsequent set and get commands were executed successfully, which is the most important difference between transactions in Redis and transactions in relational databases.

Redis 127.0.0.1 6379 > exec

1) OK

2) (error) ERR Operation against a key holding the wrong kind of value

3) OK

4) "4"

3. Roll back the transaction:

# set a pre-transaction value for key T2.

Redis 127.0.0.1 ttOK 6379 > set T2 ttOK

# start a transaction.

Redis 127.0.0.1 6379 > multiOK

# set a new value for the key within the transaction.

Redis 127.0.0.1 ttnewQUEUED 6379 > set T2 ttnewQUEUED

# abandon the transaction.

Redis 127.0.0.1 6379 > discardOK

# looking at the value of the key T2, you can see from the result that the value of the key is still the value before the start of the transaction.

Redis 127.0.0.1 tt 6379 > get T2 "tt"

4. WATCH commands and optimistic locks based on CAS:

In Redis transactions, the WATCH command can be used to provide CAS (check-and-set) functionality. Suppose we monitor multiple Keys before the transaction executes through the WATCH command, and if any Key value changes after the WATCH, the transaction executed by the EXEC command will be abandoned and a Null multi-bulk reply will be returned to notify the caller that the transaction execution failed.

For example, we assume again that the incr command is not provided in Redis to accomplish the atomic increment of key values, and if we want to achieve this function, we have to write our own code. The pseudo code is as follows:

Val = GET mykey val = val + 1 SET mykey $val

The above code can only ensure that the execution result is correct in the case of a single connection, because if multiple clients are executing the code at the same time, there will be an error scenario that often occurs in multithreaded programs-race condition.

For example, clients An and B both read the original value of mykey at the same time, assuming that the value is 10, and then both clients add this value and set it back to the Redis server, which results in a mykey result of 11 instead of 12. To solve a similar problem, we need the help of the WATCH command, as shown in the following code:

WATCH mykey val = GET mykey val = val + 1 MULTI SET mykey $val EXEC

Different from the previous code, the new code monitors the key through the WATCH command before getting the value of mykey, and then surrounds the set command in the transaction, which effectively ensures that each connection before executing EXEC, if the mykey value obtained by the current connection is modified by the client of another connection, then the EXEC command of the current connection will fail. In this way, after judging the return value, the caller can know whether the val has been reset successfully.

The above is the introduction and use of transaction commands in redis. Have you gained anything after reading it? If you want to know more about it, you are welcome to follow the industry information. Thank you for reading.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.