Does Redis support transactions? Before demonstrating transactions, it’s important to look at these commands. Multi Open transaction exec execute transaction discard Cancel transaction watch key The following illustrates a transaction with a transfer example.

127.0.0.1:6379> multi OK 127.0.0.1:6379> set money QUEUED 127.0.0.1:6379> get money QUEUED 127.0.0.1:6379> exec 1) OK 2) "100"Copy the code

This is a normal transaction problem, where you start a transaction, there’s a set of data in the transaction, and then you execute, and each instruction here is put in a queue, and when it’s executed, it’s executed one by one. The following demonstrates a cancellation transaction

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set money 100
QUEUED
127.0.0.1:6379> get money
QUEUED
127.0.0.1:6379> discard
OK
Copy the code

This is normally cancelled if we get a syntax error while executing a transaction, then the entire transaction will not be executed

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set money 100
QUEUED
127.0.0.1:6379> sett age 20
(error) ERR unknown command `sett`, with args beginning with: `age`, `20`, 
127.0.0.1:6379> get money
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
Copy the code

As you can see, when there is a syntax error, the entire transaction is not executed, and there is another kind of error, not a syntax error, but a runtime error.

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name "hzy"
QUEUED
127.0.0.1:6379> incr name
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) "hzy"
Copy the code

We let a string increment and got an error, but the rest of the transaction executed. Another situation is that when we are executing a transaction, the exec has not yet been executed, and then some other client interferes.

127.0.0.1:6379> multi OK 127.0.0.1:6379> set money QUEUED 127.0.0.1:6379> incr money QUEUED 127.0.0.1:6379> exec 1) OK 2) (integer) 101Copy the code

If, prior to exec, another client does the following

127.0.0.1:6379> set money 500
OK
Copy the code

Then client 1 performs exec, and we get

127.0.0.1:6379 > get money "101"Copy the code

As you can see, this is the result of the completion of the transaction, and the 500 did not succeed. To solve this problem, a lock appears, which is monitored with watch, which is our optimistic lock.

127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set money 100
QUEUED
127.0.0.1:6379> incr money
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get money
"500"
Copy the code

Here we monitor money and perform the following on client 2 before executing exec

127.0.0.1:6379> set money 500
OK
Copy the code

Then exec returns nil because money is watched. When we get money again, it will be 500 and the transaction will not be executed. Note that monitoring is automatically unmonitored when we execute exec, discard, or unwatch.